I've watched strong engineers fail interviews they should have passed. They wrote correct code. They still got a no.
The problem wasn't the code. It was that nobody in the room knew what they were thinking until the screen filled up. The interviewer couldn't follow them, couldn't help them, and couldn't score the parts they got right.
Talking through your code is a separate skill from solving the problem. The good news is it's learnable, and it's the thing that turns a borderline round into a pass.
Why silence loses
An interviewer isn't grading the final answer alone. They're grading how you think, and they can only grade what they can see and hear.
If you go quiet for ten minutes and then produce a working solution, you've given them almost nothing to score. They don't know if you reasoned it out or pattern-matched something you memorized. They can't tell if you'd handle a variation. So they fall back on the safe call, which is usually a weak yes or a no.
Silence also kills your lifeline. When you say your plan out loud, a good interviewer will nudge you before you waste fifteen minutes on a dead end. They can't do that if they don't know where you're headed.
Talk in three layers
The mistake people make is narrating keystrokes. "Now I'm writing a for loop." That's noise. Nobody needs it.
Useful narration happens at three levels, and you move between them on purpose.
The plan. Before you write anything, say what you're going to do and why. "I'm going to use a hash map so I can check membership in constant time, which gets the whole thing to one pass."
The decision. When you hit a fork, say it out loud and pick. "I could sort first, but that's n log n. I think a counter is cheaper here, so I'll go with that."
The check. After a chunk of code, say what you expect it to do and confirm it. "This should handle duplicates because I'm counting, not just marking seen. Let me trace it with two of the same value."
You don't narrate the loop. You narrate the choices.
Start before you code
The most valuable talking happens before you type a single character.
Restate the problem in your own words. Confirm the inputs, the output, and the edge cases. Ask about empty input, huge input, negatives, duplicates. This is fast and it shows judgment.
Then say your approach in plain English and get a nod before you commit to it. If your approach is wrong, you want to know now, not after you've built half of it. Two minutes of talking here saves you the worst outcome in an interview, which is finishing the wrong thing.
When you get stuck, narrate the stuck
People go silent exactly when they should talk the most. You hit a wall, you freeze, and the room goes quiet while you panic internally.
Do the opposite. Say where you are. "I know I need to track the previous node here, but I'm not sure how to handle the first one cleanly. Let me think about a dummy head."
Now two things happen. You often unstick yourself just by saying the problem out loud. And if you don't, the interviewer has a clear place to help you, because they can see exactly where you are.
A specific stuck point is recoverable. A blank stare is not.
Keep it tight
Talking through code doesn't mean talking constantly. There's a version of this that's worse than silence, which is the candidate who narrates every thought and never commits to anything.
Talk at the decision points. Go quiet while you write the obvious parts. Come back up to check your work. The rhythm is plan, build, verify, repeat, with your voice on the plan and the verify.
If you catch yourself rambling, stop and write code. Momentum matters too.
Trace your own code at the end
When you think you're done, don't ask "does this look right?" Run it yourself, out loud, with a real example.
Pick a small input and walk through it line by line, saying what each variable holds. This catches off-by-one errors, missed edge cases, and the bug you'd otherwise find only when the interviewer points it out. Finding your own bug reads as senior. Having it found for you reads as junior.
How to actually get good at this
You can't learn to talk through code by reading about it. It feels awkward the first few times, and the only fix is reps.
Solve problems out loud, alone, with nobody watching. Talk to the wall. It sounds ridiculous and it works, because the awkwardness is the thing you're burning off.
Record yourself once and listen back. You'll hear the dead air and the rambling immediately.
Then do mock interviews where someone is actually listening, because a real listener changes how you talk in a way the wall can't. That pressure is the part you want to practice before it counts.
The code is half the round. The other half is whether the person across from you could follow how you got there. Practice both.