"Talk through your thinking" is the most common advice for coding interviews, and the hardest to follow. Most engineers think silently at work. Being asked to narrate while you solve a problem, type, and keep track of the time is a genuinely new skill, and it doesn't come naturally to anyone at first.
This post is a companion to our pillar guide on how to prepare for a live coding interview. That guide covers the whole round; this one goes deep on the part people find hardest: what to actually say.
Why it matters so much
In a coding interview, the interviewer is assessing how you solve problems, not just whether you do. They can only assess what they can see and hear. If you work silently for ten minutes and produce a correct solution, they've seen the output but not the reasoning, and the reasoning is most of what they're there to judge.
Thinking aloud also helps you directly:
- The interviewer can help. If they can hear you heading the wrong way, they can nudge you. They can't nudge silence.
- You catch your own errors. Explaining a step often reveals that it doesn't quite work.
- Hints become useful. A hint only lands if the interviewer knows where you're stuck.
The same applies to pair programming interviews, where the format is explicitly collaborative, and to whiteboard coding, where you can't run the code and your explanation is the only evidence it works.
What to say at each stage
You don't need a running commentary of every keystroke. What helps is saying the decisions and the reasons.
While clarifying
Say what you're checking and why it matters:
"Before I start, can the input be empty? And can there be duplicates? If there are duplicates, I need to decide whether to return all pairs or just one."
While choosing an approach
This is where narration matters most. Say the options and the reason for your choice:
"The simplest approach is to check every pair, which is quadratic. That works, but I think we can do better: for each number, I know exactly what complement I'm looking for, so if I keep the numbers I've seen in a hash map, I can check in constant time. That's one pass, linear time, at the cost of linear extra space. Does that sound reasonable before I start?"
That last question is worth asking. It gives the interviewer a natural point to redirect you before you've written any code.
While coding
Narrate at the level of intent, not syntax. Not "for i equals zero, i less than n", but:
"I'll loop through once. For each number, compute the complement, check the map, and if it's not there, store the current number and its index."
Then it's fine to go a bit quieter while you type, with short markers as you go: "Now the edge case for an empty list." "This helper finds the index; I'll write it after the main loop."
While testing
Trace out loud, saying what each variable holds:
"With 2, 7, 11, 15 and a target of 9: first number is 2, complement 7, not in the map, store 2. Next is 7, complement 2, which is in the map at index 0, so return 0 and 1. Good. Now an empty list: the loop doesn't run, and we return... nothing. I should return an empty result explicitly."
Finding a bug while tracing out loud is one of the best things that can happen in a coding interview. It shows exactly the habit the interviewer is looking for.
What to leave out
Thinking aloud isn't the same as saying everything. A few things don't help:
- Reading code aloud character by character. The interviewer can see the editor.
- Long apologies. "Sorry, I'm usually better at this" uses time and doesn't change anything. A brief "let me fix that" is enough.
- Narrating panic. "I have no idea, this is going badly" isn't useful information. "I'm stuck on how to avoid re-scanning the array; let me try a smaller example" is.
Handling silence
Sometimes you need to think without talking, and that's fine. The trick is to say so:
"Give me thirty seconds to think about how to handle the overlapping case."
Then think. When you have something, even a partial idea, share it: "I think sorting first might help, because then overlapping intervals would be next to each other." A half-formed idea said out loud is more useful to everyone than a fully formed one that took five silent minutes.
If you notice you've gone quiet without meaning to, just pick up where you are: "Sorry, I went quiet. Where I've got to is..."
When you get stuck
Being stuck is when narration matters most, and when people stop doing it. A simple pattern:
- Say what you have. "I've got a working brute force."
- Say what's wrong with it. "It's quadratic because of the inner loop."
- Say what you're trying. "I'm wondering if I can precompute something to avoid the inner loop."
That gives the interviewer everything they need to give you a good hint, and it shows structured thinking even without a solution. When a hint comes, say how you're using it: "So if I keep a running sum, then the inner loop becomes a lookup. Let me try that."
How to practise thinking aloud
It's a habit, so it needs repetition, and it needs to be out loud. Thinking it isn't enough.
- Narrate every practice problem. Even alone, even when it feels odd. It feels odd for the first few sessions and then much less.
- Record yourself on your own device and listen back. You'll notice long silences, explanations that didn't make sense, and moments where you said "um, so" instead of a reason. It's uncomfortable, and very effective.
- Explain to someone who'll interrupt. A friend who asks "why a hash map?" halfway through is better practice than an uninterrupted solo run, because the interview won't be uninterrupted either.
- Use the same habit in other rounds. Saying the reason for each decision is just as important in a system design interview (see our 45-minute system design framework), and in a take-home review call, where you're explaining your own code (see how to approach a take-home coding challenge).
Hardmode's live coding round is coming soon, with an interviewer that can see your editor and hear your reasoning. Until then, a timer, a plain editor, and the habit of saying your reasons out loud will take you a long way.