Live coding interviews test not only whether you know the syntax and can solve the problem, but also how you can handle uncertainty and how you behave when you get stuck.

This week's YouTube video walks through three real Python questions live. But today I want to talk about what is happening on the other side of the table — what interviewers notice, what kills good candidates, and what to do when your brain freezes.

Before we proceed - a small ad. Your clicks on the ads help to cover newsletter hosting fees and make me $1. Thank you!

AI will write 90% of code by the end of 2026, and only 10% of developers will stay relevant.

The engineers in that 10% aren't smarter. They just know how to use AI.

We put together the exact playbook Anthropic engineers use to make sure you're in the top 10%.

Sign up for The Code and get access to:

Join 250K+ engineers

Nobody expects you to be perfect

This is the thing most candidates do not believe until they have done enough interviews to see it themselves.

Interviewers are not waiting for you to write flawless code at speed (at least in most of the cases). They are watching how you think. If you get stuck, say "let me break this into smaller steps," then work through it methodically. This is more impressive than someone who types fast and produces something that gives the wrong answer.

I have held dozens of interviews. For me, the candidates that are honest about uncertainty, ask good questions, and show the reasoning as they go are those who stood out.

Ask before you assume

The first thing most people do when they see a question is start typing. Do not do this.

Before you write a single line of code, ask a clarifying question. Something like — should I modify the original data or return a new version? Should edge cases like empty inputs be handled? What is the business definition we are using?

This does two things. It shows you understand that real problems have context. And it buys you thinking time while looking like a professional.

If there is no human next to you and the interview is recorded, ask the question and answer it yourself. "I will assume we are returning a new list rather than modifying the original." That is completely fine and it demonstrates the same habit.

Think about it this way. If a colleague handed you a task at work, you would not silently disappear for two hours and return with an answer. You would ask what they actually need first. Interviews reward the same behaviour.

Say your plan out loud before you code

Once you understand the problem, say what you are going to do before you do it. Not in detail — just the steps.

"First I will separate the valid values. Then I will calculate from those. Then I will replace the missing ones."

Now type.

This matters for two reasons. First, the interviewer can follow your thinking even when you are not talking. Second, it forces you to actually have a plan before you start, which means fewer dead ends and less backtracking.

The candidates who go silent and stare at the screen for two minutes are not necessarily less capable. They just look less capable. The interviewer has no idea what is happening in your head. Give them something to work with.

When you get stuck — and you will

Getting stuck is not failure. Going silent when you are stuck is.

When your brain freezes, say that out loud too. "I am not sure how to handle this edge case. Let me think through it." Then actually think through it, out loud. Walk through what you know. Eliminate what you know will not work. Try a simpler version of the problem first.

This actually reminds me of something a friend told me about McKinsey interviews. He was asked to estimate the monthly revenue of a café. No data, just think out loud. There is no correct answer. The question exists entirely to see how someone reasons.

He said something like: "Let’s assume this café has 12 tables. Lunch occupancy is maybe 70%, a main is around $15, so lunch revenue is roughly..." and built up from there. That is the right approach. Not because the number is accurate — it probably is not — but because he showed his thinking at every step.

Live coding works in a similar way. The interviewer does not need you to produce a perfect solution. They need to see how your mind works when you hit a wall.

So if you cannot solve the whole problem, solve part of it and say so. "I can get the data into the right format, but I am not sure of the most efficient way to do the comparison — let me think about that." That is honest. It keeps the conversation going. And it is infinitely better than silence.

Test your code, always

After you write something, test it. What happens with an empty input? What happens with a single item? What if every value is missing?

Saying this out loud — "let me just check what happens if the list is empty" — is almost as good as getting the edge case right. It shows you know what can go wrong and you are thinking about it. Most interviewers will tell you the answer if you ask the right question.

The candidates who finish writing and immediately say "done" without testing anything are the ones I worry about. In real work, untested code is where the problems hide.

The pattern that applies to every question

Whatever the question is, this sequence works:

Clarify before you assume.

Say your plan before you type.

Build it in small steps rather than all at once.

Test the output and say what you are checking.

These four habits will carry you through questions you have never seen before. Because the interviewer is not just trying to find out if you know the answer to this specific question. They are trying to find out how you will behave on your first day when something breaks and nobody is there to help you.

This week's video

I solve three real Python questions live — easy, medium and hard — using exactly this approach. Including one question where I get stuck on purpose, to show what to do when that happens.

Watch it here → link

Keep pushing 💪,

Karina

Just starting with Python? Wondering if programming is for you?

Master key data analysis tasks like cleaning, filtering, pivot and grouping data using Pandas, and learn how to present your insights visually with Matplotlib with ‘Data Analysis with Python’ masterclass.

Already know the basics and want something more hands-on?

Take the Python Challenge.

You'll work through a real business problem, complete a portfolio-ready project, and practise the kind of analysis employers expect from junior analysts.

👉 Start with the Masterclass if you're a complete beginner.

👉 Choose the Python Challenge if you're comfortable with the fundamentals and want to apply them to a real project.

More from me: YouTube | TikTok | Instagram | Threads | LinkedIn | Substack