Elegant

In the coding round, your narration is most of the score

The Elegant team 5 min readinterview
In the coding round, your narration is most of the score

Here is the thing candidates get wrong about the coding round: the interviewer is scoring your thinking, and they can only see the part you say out loud. Type in silence to a perfectly correct answer and you have shown them the destination but none of the journey — how you decomposed the problem, which trade-offs you weighed, how you caught your own bug. Most of the available signal is in that journey, and silence throws it away. Narrating your thinking is not a soft skill bolted onto the round; on a scorecard that asks “problem-solving,” “communication,” and “handles ambiguity,” it is the round. Talk.

Silent coding shows only the answer; narration exposes the whole scored process Left: a silent path from problem to answer, only the endpoints visible. Right: a narrated path showing clarify, approach, trade-off, test — all visible to the scorer. silent problem answer (nothing visible) narrated problem clarify approach trade-off test
Silent coding hands the scorer two dots. Narration draws the whole path — clarify, approach, trade-off, test — which is the part the rubric actually grades.

Narrate the four beats

You do not need a monologue — you need to voice four beats. Clarify the problem before coding; state your approach before typing; flag trade-offs as you make them; and test out loud at the end. Even a terse version of each turns invisible thinking into scored signal:

// "First, edge cases: what if wait is 0? what if it's called after cancel?"  ← clarify
// "I'll close over a timer id and reset it each call — that's debounce."       ← approach
function debounce(fn, wait) {
  let t;
  return (...args) => {
    clearTimeout(t);                              // "each call cancels the pending one" ← narrate
    t = setTimeout(() => fn(...args), wait);
  };
}
// "Let me trace: called 3x fast → only the last fires after `wait`. Correct."  ← test out loud

The comments above are what you say, not what you type — but voicing them is what fills the scorecard.

Ambiguity is a prompt to talk, not a trap

When a problem is under-specified — and interviewers under-specify on purpose — the worst move is to silently pick an interpretation and code. The scored behaviour is to surface the ambiguity and decide with the interviewer:

You: "Should the search be case-sensitive? And do I debounce the input or search on submit?"
Interviewer: "Case-insensitive, and debounce it."
You: "Got it — I'll debounce at 300ms and lowercase both sides before comparing."

You just demonstrated requirements-gathering, a trade-off decision, and communication — three rubric lines — before writing a line of logic.

Talk yourself through the stuck moment, too

The narration matters most exactly when it feels hardest: when you are stuck. Silent flailing looks like panic; narrated debugging looks like competence. “This is returning undefined — let me check whether the closure is capturing the right variable” shows a process the interviewer can follow and reward, and it often prompts a small hint you would never have gotten in silence. The habit to build is constant, low-key commentary — approach, trade-off, self-correction — so that by the end the interviewer has seen not just that you can code, but how you think, which is the thing they were sent to measure. Practise it by solving the debounce-utility, event-emitter, and deep-clone exercises out loud, alone, until narrating is automatic under pressure.