Talking Through Code While Typing: The Underrated Interview Skill

The most common cause of “the candidate solved it but I’m not sure they understood it” feedback is silent typing. Strong candidates narrate their thinking continuously; the interviewer follows along, sees their reasoning, and scores the process as well as the result. Silent candidates leave the interviewer guessing. This guide covers what to say while coding, what not to say, when to pause, and how to develop the skill.

Why Verbal Narration Matters

Coding interviews score multiple signals:

Did you solve the problem?
Did you understand it correctly?
How did you approach it?
How did you handle edge cases?
How would you test it?
How did you communicate while working?

If you only say “the answer is X” at the end, the interviewer can’t score the process signals. Two candidates with identical correct solutions can score very differently if one narrated thoughtfully and the other was silent.

Beyond scoring: narration helps you. Verbalizing your reasoning catches bugs, surfaces edge cases you’d otherwise miss, and prevents you from going down dead-end paths because the interviewer can intervene with hints when they hear you stuck.

The Standard Interview Flow with Narration

1. Restate the problem (30 seconds)

“Just to make sure I understand: I’m given an array of integers and need to find two indices that sum to the target. I can assume exactly one solution exists. Is that right?” Confirms understanding; gives interviewer a chance to clarify.

2. Walk through examples (1 minute)

“For [2, 7, 11, 15] and target 9, the answer is [0, 1] because 2 + 7 = 9. For [3, 3] and target 6, the answer is [0, 1] — even with duplicates.”

Examples surface edge cases (duplicates, negative numbers, single-element, empty array) and confirm you understand the problem.

3. Discuss approach options (2 minutes)

“Naive approach: nested loops, O(n²) time, O(1) space. Better approach: hash map, single pass, O(n) time and space — for each element, check if its complement is in the map. I’ll go with the hash map approach.”

Shows you considered multiple approaches and chose deliberately. Strong candidates briefly mention naive approach even if not implementing it.

4. Code while narrating (15–25 minutes)

“I’ll initialize the hash map … For each element with index i and value num … I’ll compute the complement … If the complement is in the seen map, return both indices … Otherwise, add this number to the map and continue …”

Narrate at the pace of typing. Don’t rush ahead; don’t lag behind.

5. Walk through with example (2 minutes)

“Let me trace through [2, 7, 11, 15] with target 9. i=0, num=2, complement=7, not in map, add {2: 0}. i=1, num=7, complement=2, in map at index 0, return [0, 1]. Looks correct.”

6. Discuss complexity (1 minute)

“O(n) time, O(n) space. The hash map can have up to n entries in the worst case.”

7. Discuss edge cases and improvements (2 minutes)

“Edge cases: empty array (return empty), no valid pair (return empty), duplicates (handled correctly because we check before inserting). For follow-ups: 3Sum is the natural extension; would use a different approach with sorted array and two pointers.”

What to Say Specifically

Verbalize each significant decision

“I’m using a hash map because it gives O(1) lookups.”

“I’m checking the complement before adding to the map to avoid the duplicate-with-itself case.”

“I’m returning early on the first match because the problem guarantees exactly one solution.”

Voice your hypotheses

“This problem feels like a hash map problem. Let me think about whether sorting would also work. Sorting would be O(n log n); hash map is O(n). Hash map wins unless we need sorted output.”

Mention edge cases as you encounter them

“I should handle empty array. Let me add that check.”

Discuss complexity as you choose data structures

“Set lookups are O(1) average; that gives me overall O(n).”

What Not to Say

Filler that doesn’t communicate

“Um, OK, so… let me see… I think… maybe…” Wastes air time without conveying signal.

Apologetic narration

“Sorry, this is taking me a while… I’m sorry I’m not faster…” Apologies signal anxiety; interviewers don’t expect machine-speed coding.

Out-loud reading of your code

“For i in range len nums…” Reading code character-by-character isn’t narration; it’s distraction.

Premature commitments

“This will definitely work” — before you’ve verified. Stronger: “I think this works; let me trace through to verify.”

Whining about the problem

“This is harder than I expected” — even if true. Stay positive in narration; complaints land poorly.

When to Pause (and Why)

Continuous narration without pauses is exhausting and often shallow. Strong candidates pause to:

Think

“Hmm, let me think about this for a moment.” — and then 30 seconds of silence is fine. The interviewer knows you’re thinking; explicit signaling makes the silence productive rather than awkward.

Read carefully

When the problem statement has ambiguity or the input has edge cases, “let me re-read the problem to make sure I have this right” justifies a pause.

Trace through code

“Let me trace through with this example…” Then verbal walking through the code with intermittent silences as you mentally execute.

Recover from a stuck moment

“I went down the wrong path. Let me back up and try a different approach.” Acknowledging the dead-end is better than silently continuing.

How to Develop the Skill

Practice while solving solo

When working through LeetCode alone, talk out loud as if you’re being interviewed. Awkward at first; develops the habit.

Record yourself

Record a 30-minute solo coding session. Listen back: too much filler, too little explanation, awkward silences? Iterate.

Mock interviews

Mocks are the highest-leverage practice. The pressure of an actual partner forces you to narrate; the feedback identifies what to improve.

Watch interview videos

Neetcode and others have public coding interview recordings. Note their narration style: when they talk, when they pause, what they say.

Specific Phrases That Work

“Let me make sure I understand the problem first…”
“Let me think about edge cases. Empty input, single element, duplicates, negative numbers…”
“My initial thought is X, but let me consider whether Y would work better…”
“I’ll go with X because of [specific reason].”
“Let me trace through this with an example to verify…”
“The complexity is O(n) time and O(n) space because…”
“For follow-ups, the natural extension would be…”
“I noticed an issue with my approach; let me back up…”

These phrases sound natural in interviews and signal mature engineering thinking.

Common Mistakes

Silent typing. Single biggest mistake. The interviewer can’t score what they can’t see.
Reading code aloud. Different from explaining; doesn’t help.
Excessive filler. Eroded confidence; sounds unprepared.
Apologetic narration. Don’t apologize for thinking time.
Lecturing the interviewer. Narration should be conversational, not a monologue. Pause for engagement.
Solving in head and announcing the answer. Even if you’ve solved it mentally in 30 seconds, narrate the reasoning. The process is what’s scored.

Frequently Asked Questions

What if I think faster than I can talk?

Slow down to talking pace. Even if you’ve solved the problem mentally, narrate at speech-speed while you implement. The interviewer is calibrating to your verbal narration; faster mental work without verbalization doesn’t show up in the score.

What if my narration takes longer than the silent solution?

That’s fine. Interviews have time budgets but not strict optimal times. A solution with strong narration in 25 minutes beats a silent solution in 15 minutes. Communication is part of what’s scored.

What if the interviewer is silent and not engaging?

Common; some interviewers are quiet. Don’t take it personally. Continue narrating; ask occasional verification questions (“does that approach make sense?”) to invite engagement. If they don’t engage, your narration still scores; their behavior isn’t a signal about you.

Is it OK to ask the interviewer if I’m on the right track?

Yes, sparingly. “Is this approach reasonable, or do you want me to consider alternatives?” early in the problem. Don’t ask repeatedly; signals lack of confidence. Strong candidates use the question once or twice as direction-setting, then commit.

How do I narrate when I’m stuck?

Be honest: “I’m stuck on [specific aspect]. Let me think about [different angle]…” or “I’ve been on this for a few minutes; let me back up and consider whether my approach is right.” Strong candidates make their stuck-state visible and self-correct. Silent stuckness is the worst signal.