Thinking out loud in a live-coding round
You are not being marked on whether the code runs. You are being marked on what the interviewer learns about you while you write it.
A live-coding round is a strange format: you write worse code than you would at your desk, in front of someone, with no documentation and a clock. Everyone knows this, including the interviewer. What they are actually sampling is narrower than it looks — can you take an underspecified problem, ask the right clarifying questions, choose a reasonable approach, and make progress without freezing.
Spend the first three minutes not coding
The most common failure is starting to type immediately. Restate the problem in your own words, ask about the inputs, and name at least one case that the statement does not cover. "Can the input be empty? Can it contain duplicates? Are these sorted, or should I assume arbitrary order?" Every one of those questions is scored, and the candidate who asks none of them looks like someone who will build the wrong thing confidently.
Say the naive solution out loud before you improve it
State the obvious approach and its cost — "the brute force here is checking every pair, so quadratic; let me see whether I can trade memory for that" — then improve. This does two things: it guarantees you have something to fall back on, and it shows you can reason about cost, which is often the actual thing being tested.
Keep narrating, but keep it useful
- Narrate decisions, not keystrokes. "I'm using a map here so lookup stays constant" is useful; "now I'm writing a for loop" is noise.
- When you are stuck, say what you are stuck on. Silence looks identical from the outside whether you are thinking hard or lost, and the interviewer cannot help with the first kind.
- Name trade-offs as you make them. "This mutates the input, which I'd avoid in production, but it keeps this simple — shall I leave it?" turns a shortcut into a visible decision.
- If you spot a bug in code you already wrote, say so and fix it. Catching your own mistake scores better than code that happened to be right.
Test before they ask
When the implementation is done, walk through it with a small input out loud, then say what edge cases you would add. Candidates who declare "done" and sit back lose points that candidates who find their own off-by-one error keep. If you have time, actually run it.
If you do not finish
Plenty of hires do not finish. What distinguishes them is that they can say precisely where they are: "the core loop works, the ordering is right, what's missing is the case where the list is empty and I'd handle it here." That sentence is worth more than twenty more lines typed in a panic in the last minute.
The interviewer is not reading your code. They are listening to you think, and using the code as evidence.