Two candidates write identical code. One narrates their thinking; one works in total silence and only speaks to announce the answer. The narrator gets the offer, even if their code was slightly worse. Coding interviews aren't a typing test — they're a “show me how you think” test, and you can't show thinking you keep to yourself.
Why silence costs you
- The interviewer can't follow you. Go quiet for four minutes and emerge with code, and they've no idea whether you reasoned or guessed.
- They can't help you. Interviewers nudge candidates who are on the right track — but only if they can hear where you are. Silence forfeits the hints.
- Partial credit vanishes. If you don't finish, your reasoning is the only thing left to score. No narration, nothing to score.
What to actually say, stage by stage
- Restate and clarify. “So we need the longest substring without repeats — can I assume ASCII input?” Confirms understanding and buys thinking time.
- Talk through approaches before coding. “Brute force is O(n²); I think a sliding window with a seen-set gets it to O(n) — let me go that way.”
- Narrate as you code, lightly. Flag what each part does and why. The decisions, not every keystroke.
- Say when you're stuck, and how. “I'm worried about the empty-string edge case” invites a hint and shows rigour.
- Test out loud. Walk one example through your code, say what you expect, confirm it matches.
What thinking out loud actually sounds like
People say “narrate” and it stays abstract. Here's a full narration for a real problem — “find two numbers in an array that sum to a target” — start to finish, the way you'd actually say it:
“Okay, two-sum. Let me restate: given an array and a target, return the indices of two numbers that add to it. Can I assume exactly one solution exists? … Great. Can the same element be used twice? … No, distinct indices, good.
Brute force is check every pair — that's O(n²). I think I can do better. If I'm at a number x, I need to know whether target minus x already appeared. That's a lookup, which says hash map to me. So one pass: for each number, compute the complement, check if it's in the map; if it is, I've got my answer; if not, store this number's index and move on. That's O(n) time, O(n) space.
Let me code it. Map from value to index. Loop with index i… complement is target minus nums[i]… if complement's in the map, return its index and i… otherwise map[nums[i]] = i. Let me trace [2,7,11] target 9: i=0, complement 7, not in map, store 2→0. i=1, complement 2, that's in the map at 0 — return [0,1]. Matches. Edge case: what if the array's empty? Loop just doesn't run, returns nothing, which is fine given the problem guarantees a solution.”
Notice the shape: restate, clarify, name the naive approach and its cost, spot the improvement out loud, code while flagging decisions, then trace an example and check edge cases. That rhythm is the whole skill. It's the same narration muscle a system design round leans on, just at smaller scale.
Narrating while typing on a shared editor
Remote coding rounds add a wrinkle: you're typing in a shared editor or on a screen-share while talking, and typing quietly is the default trap. A few habits help:
- Front-load the plan. Say the approach fully before you start typing, so the silent stretch while you type isn't a mystery.
- Narrate at the seams, not every line. “Now I'll set up the map… now the main loop.” Enough to keep them oriented without a running commentary.
- Say when you're just typing. “Give me a sec to get the boilerplate down” buys you a legitimate quiet moment instead of an awkward one.
- Read errors aloud. If something breaks, talk through the fix — debugging calmly out loud is a strong signal, not a weakness.
What changes by level
The bar for narration shifts with seniority.
Junior
Just don't go silent. Restating, planning before coding, and testing your own example already put you ahead. Being coachable — taking a hint well — counts for a lot.
Intermediate
They expect you to weigh approaches, not just pick one — “I could sort first, but that's O(n log n); the hash approach is O(n) at the cost of space, and I'll take that here.” Justify the trade-off unprompted.
Senior or staff
Narration becomes about judgment and communication. You're expected to discuss readability, testing, how this scales, and where it'd break in production — and to explain it clearly enough that a junior in the room could follow. Clarity of communication is the seniority signal.
Silent
[four minutes of typing] “Okay, done. It works.”
Narrated
“Brute force is O(n²); I'll use a hash map for O(n). Setting up the map now… main loop checks the complement… let me trace one example to be sure.”
Over-narrating every keystroke until you can't think. The goal is decisions and direction, not a transcript. If narration is crowding out the actual problem-solving, you've overcorrected — flag the decision, then let yourself type in a brief, announced silence.
The trick is splitting your brain
Thinking and talking at once feels unnatural and gets harder under nerves — most people default to silence the moment pressure rises. It's a coordination skill, and like any coordination skill it only becomes automatic with reps. If nerves are the thing that shuts your mouth, the fix for going blank and this are the same fix: rehearse the performance, not just the material.
- Do you restate and clarify before touching code?
- Do you name the naive approach and its complexity out loud?
- Do you flag decisions as you type, not narrate every line?
- Do you trace an example and check edge cases aloud?
- Have you practised on a shared editor while talking?
Take a problem you can already solve. Solve it again out loud to literally no one — restate, plan, narrate, trace an example. Record it. If you catch yourself going silent for more than ten seconds, that's the exact moment that stretches into a minute on the day. Do it until narrating feels like the default, not a second task.
By interview day, thinking out loud should feel like breathing — automatic, so it frees up the brain you actually need for the problem. Fit it into the wider loop with the realistic technical prep plan, where narration is a quarter of the schedule for a reason.
Practise narrating out loud
Run a realistic voice mock coding interview, narrate your approach, and get a scored report on your reasoning and communication. Free to start — no card.
Start freeFrequently asked questions
Why is thinking out loud important in coding interviews?
Because interviewers score your reasoning, not just your final code. Narrating lets them follow you, give hints when you're close, and award partial credit if you don't finish. Silence forfeits all three.
How do I get better at talking while coding?
Practise solving problems out loud, alone, until narrating feels automatic — restate, plan, narrate decisions, trace an example. Thinking and talking at once is a coordination skill that breaks under nerves unless you've rehearsed it.
How do I narrate while typing in a remote coding interview?
Front-load the plan before you type, narrate at the seams rather than every line, and say when you just need a quiet moment for boilerplate. Read errors aloud and debug calmly — it's a strong signal, not a weakness.