A 4-Step Framework (for Podcasts and Interviews) To Answer Questions Like a Pro

A recent podcast interview was the perfect excuse to ask for feedback on my interviewing skills.

I’ve been putting more attention on my communication skills, but never asked for feedback. So I reached out to Ryan Alexander Wiens, a coach who helps engineers speak clearly and show impact, showing him one of my answers.

Here are two suggestions Ryan gave me. I’m sure he doesn’t mind I’m sharing them here:

#1. Slow down at key words and pause for emphasis. It’s hard to sound confident while answering well. Pauses give us time to think and create a sense of expectation for the listeners.

#2. Answer with PREP: Point/Reason/Example/Point. To answer questions confidently, I learned to start and end with the main point.

But to make our answers more impactful, add a “Why” or a reason after the main point. Then to end the answer, restate the question with the main point again. We tend to remember only the beginning and end, so win-win! We look more confident and help the listener remember our answer.

So let’s say we’re asked about the mistakes beginners make in terms of branding. Following the 4-step framework we could say:

(Point) I’d say one of my biggest mistakes has been not to start earlier.

(Reason) Building a brand has brought me great opportunities, like this interview… I wish I had started sooner.

(Example) If I had to start right from scratch again, I’d…

(Point) That was my mistake and the mistake most beginners make: waiting too long to start.

Now thanks to Ryan’s PREP framework, you’re PREPared for your next podcast or job interview. Pun intended.

Friday Links: Programming pearls, hating AI, and formatting

Hey there.

Before the usual 4 links, a quick update about my book.

This week, I finished another four chapters. But there’s still work to do.

I haven’t chosen a final book title, but what about 30 Ways to Get Better at Coding? What do you think? Does it sound interesting?

And… Here are 4 links I thought were worth sharing this week:

#1. Forty years ago, Programming Pearls was released, a collection of hard truths about coding. But are they still relevant? Here’s a breakdown of those pearls (20min).

#2. Here’s why the guy who stopped the largest cyberattack in history hates AI (30min).

#3. Want to understand the AI hype? It’s not a technology, but a subscription company (6min).

#4. Speaking of coding in the old days, here’s how ADA handled code formatting (4min).


And in case you missed it, this week I was invited to a firechat session with the LAX Africa community to discuss how to land a first job. Here’s a summary of the session (5min).


(Bzzz…Radio voice) This email was brought to you by… Check my Gumroad store to access free and premium books and courses to level up your coding skills and grow your software engineering career.

See you next time,

Cesar

Want to receive an email with curated links like these? Get 4 more delivered straight to your inbox every Friday. Don’t miss out on next week’s links. Subscribe to my Friday Links here.

15 Takeaways From "Breaking in the Mindset That Gets You Hired" With ALX

This week, I had the chance to share some of my career lessons with the ALX Africa community.

I joined Shehab Abdel-Salam, a Senior Software Engineer at Proofpoint, to share the mindset shifts needed to land a coding job for the first time.

Here’s the recording of the session—In case you want to watch it, there’s some back jokes:

And here are 15 takeaways from the session—In case you don’t want to watch the recording:

Career Growth

#1. Identify your gray zones vs growth zones.

A gray zone is doing comfortable work. And a growth zone is doing work that stretches your skills.

To grow your career, do the things that scare you. Comfort zones kill growth.

#2. Forget the corporate ladder.

Hard work alone doesn’t guarantee results.

Instead of chasing the corporate ladder, define your own success metrics and climb your own ladder.

#3. Stand out at work by doing the work nobody else wants to do.

And make sure you’re able to do it.

By the way, that’s only one way to stand out besides hard work. Here are another 9.

#4. Be aware of cultural expectations when working remotely.

Coming from LatAm, when I started working with American companies, I missed the chitchat and off-topic conversations before starting meetings. The American way is direct and to the point.

#5. As a junior coder, stand out by showing you’re able to learn new subjects and follow instructions.

As a senior coder, it’s the opposite. You stand out by showing you don’t need many instructions.

#6. Rely on your personal and professional network to look for your first job.

Shake hands online and offline and skip the hiring lines.

Over ten years ago, I didn’t apply through a job portal to land my first job. I knew someone who knew someone who made an introduction. Then when I left my first job (fired actually), my ex-boss arranged an interview for me. That’s the power of your network.

It sounds like a cliche, but your network is your net worth.

#7. Listen to feedback, say thanks, and act on it.

Avoid the temptation of explaining and justifying your behavior.

Writing

#8. Writing online is one of the most rewarding skills for your career.

It improves your research and communication skills.

For example, my blog has opened many career opportunities. Thanks to a link to my blog on my CV, I turned a failed interview into a content collaboration… And I made some lunch money.

#9. Your writing and online presence can replace your portfolio.

Every time you finish a project (or move to another job or achieve a milestone), write about the lessons you learned and what you would have done differently. And showcase those posts in your LinkedIn profile or CV.

#10. If you’re completely new to writing, start with a worklog.

If you have only written README files for your GitHub repos, you don’t need to write deep dives.

Start with “Today I Learned” posts. That’s exactly how I started writing. My very first post ever was a word vomit pretending to be a coding tutorial about Aspect-Oriented Programming in C#. (I’m so embarrassed by that post, but I still keep unedited to remind me how I started).

Document what you’re learning and the resources you’re using. That’s the easiest way to start writing.

Technical Skills

#11. Build simple apps and projects to practice.

Or even clone existing apps and some of their features.

#12. Understand you don’t need many programming languages to be a good coder.

You can make your way with HTML/CSS/Javascript, one backend language (JavaScript counts here), and SQL.

#13. Read engineering blogs:

#14. Embrace the struggle.

It’s part of the learning process.

When you’re stuck with a coding problem, don’t rush to AI for a quick answer. Try solving it yourself and don’t hesitate to ask for help.

#15. Don’t be scared of AI.

Use it wisely. Otherwise, your coding muscles could atrophy.

If you’re starting out, keep learning and having fun. This is the best time to learn coding. Always be a beginner.

Starting out or already on the coding journey? Join my free 7-day email course to refactor your software engineering career now–I distill 10+ years of career lessons into 7 short emails.

This Simple Word Change to Reveal What AI Really Means

AI is the new buzzword of the day.

Add “AI” to a company or product name to join the hype. It’s all over the news. AI is the new contender for coders. Yes, we coders are always the ones being replaced.

But Ibrahim Diallo made a good point in his post AI is Not a Technology, It’s a Subscription Company:

Swap “AI” for “subscription company.” And all AI those headlines make more sense. “%X of code at $BigTech is generated by a $SubscriptionCompany” has a new meaning.

AI isn’t a product we own. It’s subscription companies profiting off our data. And that isn’t innovative or disruptive at all.

4 Tips to Avoid Rushing to Code (and Building the Wrong Thing)

You spent days on your JIRA ticket… only to be told to redo it after your team lead reviewed your code?

A few years ago, I was working on a hotel management tool. My team lead asked me to redo an apparently trivial task. I had to store emails before sending them. It wasn’t a full rework, but I had to change my approach. We had completely different expectations from the same task. Two days of work almost wasted.

If I had only asked one single question before starting… “Hey, I’m doing it like this, are we on the same page?”

If you’re like me, eager to jump into the code, confident in your solution, hold your horses and follow these four tips:

#1. Always ask why. Don’t start coding if you don’t understand what needs to be done. Ask: Why this task? What’s the real problem? Why solve it now?

#2. Read the existing code before starting. Your changes might be simple, unless you have to refactor some legacy code first. If you rush to code without knowing that, you’ll give the wrong impression you’re taking too long on a simple task. Yes, estimates are hard.

#3. Outline your solution with comments. Start by sketching your plan in comments. That’s your blueprint. Of course, once you’re done, don’t forget to delete them.

#4. Write a one-page spec. Draft a summary of the changes you need to implement, just for yourself. It’s for you to think clearly before writing a single line of code.

A simple question would have saved me from wasting two days of work. Make sure everyone agrees on your solution before you start. It could save you from building the wrong thing.

It’s better to annoy people by asking too many questions than by making mistakes for not asking any questions at all. Strive for context before coding. Always.

I cover 30 lessons like the one in this post in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the roadmap I wish I had on my journey from junior to senior.

Grab your copy of Street-Smart Coding here—Because typing isn’t the hardest part of coding, but knowing what to type.