Live coding interview: what to say while you code

The task looks familiar. But the interviewer is watching, the cursor is blinking, and your head is empty. You type something, delete it, type again. After five minutes of silence you hear a polite "so, how's it going?", and it only gets worse.

In a live coding round, silence often hurts more than a bug. The interviewer sees your screen but has no idea what's going on in your head. And that's exactly what they're evaluating: how you work through a problem, how you take hints, and what it would be like to work with you on the same team.

The Sobes question bank has about 2,500 live coding tasks from real interviews, and many of them aren't about algorithms at all: "what will this code print", "find the bugs", "rewrite this component". In tasks like these, your explanation is the answer.

The first two minutes: restate the task

Before you write anything, restate the problem in your own words. It takes half a minute and saves a lot of mistakes: if you misunderstood something, the interviewer will correct you right away, not twenty minutes later.

Just to check: the input is a list, the output is only the unique values, and we keep the original order?

Ask two or three questions that actually affect the solution. What should it return if there's no data? How large is the input? Do we need error handling? And clarify the rules: can you google, run the code, use the language you're most comfortable with?

You don't need a long list of questions. The interviewer just wants to see that you don't start coding blind.

Say your plan before you code

First I'll write a simple version that definitely works. Then I'll see what can be sped up.

One sentence like this does two things. The interviewer knows where you're heading and can stop you if it's the wrong direction. And you get something to lean on: even if things go badly later, a working version is already on the screen.

If you see several approaches, name them and say which one you're picking and why. Interviewers find discussing options more interesting than watching you type.

While coding, talk about decisions, not lines

You don't need to narrate every line. "Okay, writing a loop, i from zero" tells the interviewer nothing and only throws you off. Speak up where you make a decision:

I'll add a check for an empty list here, otherwise it crashes on the first element.

We could sort it, but then we'd lose the original order, and we need it.

Staying quiet is fine too, as long as you say so:

Give me a minute to finish this part, then I'll walk you through it.

A minute of silence after that sounds normal. Five minutes of silence without it looks like you're stuck.

When you're stuck

Almost everyone gets stuck, and interviewers know it. What they care about is how you get out. A few phrases that help:

I know what needs to happen, but I don't see how yet. Let me think out loud.

Let me try a small example, it's easier to spot the pattern.

I'm torn between two options. Could you point me in the right direction?

Asking for a hint is fine if you're specific. "I don't know what to do" sounds like giving up. "I'm thinking of storing the elements I've already seen, am I on the right track?" sounds like working together. Interviewers are happy to help candidates who show exactly where they're stuck.

When the interviewer gives a hint or pushes back

It doesn't always mean you're wrong. Sometimes the interviewer just wants to see how you handle disagreement.

Hear them out first. Then restate the hint in your own words and say what it changes:

So if I store the elements I've already seen, I don't need the second loop. Then I'll rework this part.

If you disagree, say so calmly and explain why:

I see why you'd do it that way. I went the other way because it's easier to read. But if speed matters more, I'll change it.

Don't dig in and defend your solution at any cost. Don't silently agree with everything either: the interviewer wants your opinion, otherwise they wouldn't ask.

When you find your own bug

I see a bug: this will crash on an empty list. I'll fix it and run that case again.

That's it. Long apologies only waste time and nerves. A bug you found and calmly fixed yourself doesn't bother the interviewer. What bothers them is a candidate who doesn't notice it, or keeps explaining on top of broken code.

When you're running out of time

Five minutes before the end, say what's left:

I won't have time to finish error handling. Here's how I'd do it: check the server response and retry the request a couple of times.

An unfinished solution with a clear plan looks much better than a silent race to the last second.

If Copilot has your back

Sobes Copilot will suggest a solution from a screenshot of the task. But you're the one explaining it to the interviewer, and every "why did you do it this way?" will be addressed to you. So everything above still applies with a hint: read the solution, put it in your own words, and only then start typing.

How to practice

Pick a couple of live coding tasks for your stack in the question bank, for example Python, Go, or frontend. Start a screen recording with sound and solve them out loud as if an interviewer were sitting next to you. Then watch the recording. You'll immediately see where you went silent for three minutes, where you mumbled to yourself, and where you started coding before you understood the task.

Even better, ask a friend to play the interviewer: let them interrupt, ask questions, and sometimes argue with your solution. After a couple of rounds, talking while you code becomes a habit, and in a real interview it no longer drains your energy.