Why does narrating matter if the code is correct either way?

Because interviewers cannot grade a process they cannot observe. A silent candidate who reaches a correct answer gives the interviewer nothing to evaluate except the final code — no evidence of how you would behave on an ambiguous real problem where the "correct answer" is not known in advance. Two identical solutions, one narrated and one silent, are not scored identically.

Is it bad to go quiet while actually writing code?

A brief quiet stretch while typing a well-understood section is fine and expected — nobody narrates every keystroke. The costly silence is at decision points: choosing a data structure, hitting an edge case, or realizing an approach is wrong. Those are exactly the moments to speak, even briefly.

What if I get stuck and have nothing useful to say?

Say what you know, even if it is incomplete: "I know this needs to track something as I go, I am not sure yet whether that is a count or a set." An honest, specific statement of where you are stuck gives the interviewer something to respond to and often prompts a nudge — silence gives them nothing to work with, which usually means no hint arrives.

Thinking out loud

Interviewers cannot grade a process they cannot observe. A correct solution reached in silence and the same solution reached while narrating every decision are not scored the same — and the difference is entirely within your control.

Why silence costs points even when the code is right

A coding interview is not graded purely on the final program — it is graded on evidence of how you think, because that is what predicts how you will behave on a real, ambiguous problem at work where nobody has already confirmed the approach is correct. A candidate who reaches a correct solution in complete silence gives the interviewer nothing but the final artifact. A candidate who narrates the same journey gives the interviewer a transcript of judgment calls: what they considered, what they ruled out, and why. Only one of those two candidates has demonstrated the actual skill the interview claims to measure.

What to say at each stage

While reading the problem: repeat the requirements back in your own words, and ask one or two clarifying questions even when you think you already know the answer — "can the input array be empty," "should this be case-sensitive." This shows you treat requirements as something to confirm, not assume.

While planning: name the pattern you recognize and why, before writing code — "this needs a contiguous range with a sum constraint, so sliding window." If you are not sure yet, say what you are ruling in or out: "I don't think this is two pointers because the array is not sorted."

While coding: a brief quiet stretch on well-understood lines is fine. Speak up specifically at decision points — choosing a data structure, handling an edge case you just noticed, or changing direction mid-solution.

After coding: trace through at least one example by hand out loud, including one edge case, before declaring the solution done. State complexity unprompted — see Time & Space Complexity for exactly how.

What to say when you are stuck

The instinct under pressure is to go silent while searching for the answer internally. That is precisely the wrong move: an interviewer watching silence has no way to distinguish "about to have an insight" from "completely lost," and by default reads prolonged silence as the latter. Say what you know, even partially: "I know I need to track something as I iterate — I'm not yet sure if that's a running count or the actual values." A specific, honest statement of the gap is far more likely to prompt a useful nudge than silence ever will, and it demonstrates the exact debugging instinct the interview is trying to assess.

Narrating too much is also a mistake

The failure mode in the other direction is a nonstop stream of low-value narration — reading the code back line by line as you type it ("now I'm setting left equal to zero"), which adds noise without adding a decision the interviewer can evaluate. The useful unit of narration is a decision or a judgment call, not a transcription of syntax. If what you are about to say would be obvious from watching you type, it usually does not need to be said.

Frequently asked questions

Why does narrating matter if the code is correct either way?: Because interviewers cannot grade a process they cannot observe. A silent candidate who reaches a correct answer gives the interviewer nothing to evaluate except the final code — no evidence of how you would behave on an ambiguous real problem where the "correct answer" is not known in advance. Two identical solutions, one narrated and one silent, are not scored identically.
Is it bad to go quiet while actually writing code?: A brief quiet stretch while typing a well-understood section is fine and expected — nobody narrates every keystroke. The costly silence is at decision points: choosing a data structure, hitting an edge case, or realizing an approach is wrong. Those are exactly the moments to speak, even briefly.
What if I get stuck and have nothing useful to say?: Say what you know, even if it is incomplete: "I know this needs to track something as I go, I am not sure yet whether that is a count or a set." An honest, specific statement of where you are stuck gives the interviewer something to respond to and often prompts a nudge — silence gives them nothing to work with, which usually means no hint arrives.

Practice narrating, not just solving

Free account. Career Memory carries your prep as more of the product ships.