Talking Through Code

Narrating your code as you write it is how the interviewer reads your reasoning: a coding interview is graded on your thinking and problem-solving, and silence hides almost all of it. Gayle Laakmann McDowell’s advice in Cracking the Coding Interview is blunt — “talk out loud as you solve the problem… if you remain quiet, it’s harder to ascertain” how you think (per the 6th-edition guidance, summarized at Dice). But narration is not, on its own, the dominant scored axis: interviewing.io’s analysis of 100,000+ technical interviews found that the Communicate score has by far the smallest marginal effect on outcome — dropping a point on Code or Solve spikes the rejection rate ~6×, while dropping a point on Communicate barely moves it (interviewing.io 2020). The honest reading: narration matters because it is the channel through which problem-solving signal reaches the grader and through which the interviewer can give you hints — not because Communication is independently weighted highest. There are two failure modes: silent typing (the interviewer can’t tell if you’re stuck, thinking, or shipping nonsense, and can’t help) and droning monologue (every keystroke narrated, no actionable signal among the noise). The middle path — announce decisions at the moment they’re made, checkpoint at function boundaries, surface uncertainty deliberately, and ask before committing to non-obvious approaches — is what experienced interviewers describe as “thinking like a senior engineer.” This note is the catalog of phrases that demonstrate seniority, the phrases that signal juniority, the failure modes, and the meta-skill of staying narrating without becoming exhausting.

1. Why This Matters

Every major SWE coding-interview rubric (Google, Meta, Amazon, Microsoft, Stripe, etc.) has a Communication axis. Some bake it into a “general impression” line; all of them score it. And the Communication score is generated largely from what the candidate says out loud — code typed in 20 minutes of silence gives the grader almost nothing to put on that line. The interviewer is not telepathic; they cannot grade reasoning they cannot hear.

But it would be wrong to claim Communication is the highest-weighted axis, and the best available data says the opposite. interviewing.io graded 100,000+ technical interviews on a three-axis 1–4 scale — Code, Solve (problem-solving), Communicate — and measured how each axis moved the advancement rate. Their finding: dropping one point on Code or Solve made the rejection rate “skyrocket 6×” in a third of interviews, while the negative impact of dropping one Communicate point was “by far the smallest.” A candidate scoring 4-4-2 (perfect code and problem-solving, weak communication) advanced 96% of the time — and was ~3× less likely to be rejected than a 3-3-4 candidate (weak code/solve, perfect communication). Their blunt summary: “When in doubt, trade Communicate for Solve or Code. Period.” (interviewing.io 2020).

That sounds like it deflates this whole note, but it does not — for two reasons the same study makes explicit:

1. There is a floor. The only minimum-passing score (“2”) that shows up among the top predictive factors for advancement is the Communicate score. The interpretation: you need a floor of communication competency to pass at all; above that floor, more communication doesn’t move junior outcomes much. interviewing.io’s own advice for L3–L4 candidates is “ignore the communication score entirely as long as you are consistently scoring 2+ on it.” This note is, in large part, a manual for clearing that floor reliably — silent typing routinely scores below it.
2. It flips with seniority. The interviewing.io guidance is explicit that the finding is for junior coding interviews; for L5+ (senior/staff), communication becomes far more important, and the rounds where it dominates are system design and behavioral, not the coding round (per the same analysis; see Levels and Calibration). So the higher the level you’re interviewing at, the more this note’s content is load-bearing rather than floor-clearing.

The deeper reason narration matters at all is the one McDowell gives: the interviewer “wants to know how you think and problem solve,” and narration is the only channel that carries that — it also lets the interviewer “correct you if you go awry,” i.e. give hints (Dice summary of CtCI). In real engineering the same logic holds: a senior engineer who can articulate their reasoning while debugging is teaching the team; one who silently produces a fix no one understands is a single point of failure. The interview is filtering for the former. The narration is the channel for the signal — not, by itself, the highest-weighted line on the rubric.

The cost of getting narration wrong is concrete. Three failure modes are common:

1. Silent coding. Candidate types for 15 minutes; interviewer has no idea whether they’re stuck, deep in flow, or producing wrong code. Communication score: at or below the passing floor — and, just as damaging, the interviewer has no window into the candidate’s problem-solving, so the Solve score suffers too. They also get no early warning that a bug is forming, so they can’t intervene helpfully.

2. Droning monologue. Candidate narrates every keystroke (“now I’m typing ‘def’, now an open-paren, now I’m typing ‘arr’, now a comma…”). The interviewer cannot extract decisions from the noise. Communication score: low — there’s volume, but no signal.

3. Filler narration. Candidate says “let me think” / “hmm” / “OK so” / “yeah” frequently, but never substantively names a decision. Reads as nervous; the interviewer downgrades on Communication and may also downgrade on Confidence-related dimensions.

The middle path — narrate decisions, checkpoint at boundaries, surface uncertainty, ask before non-obvious commitments — is what scores. This note catalogs that path concretely: which phrases signal seniority, which signal juniority, when to narrate vs when to think silently, and how to keep the narration sustainable across a 25-minute coding phase.

2. The Three Modes of Narration

Within a coding interview’s Phase 4 (see Problem Decomposition in Interviews §2.4), the candidate alternates among three narration modes:

2.1 Decision-Announcement Narration

What it sounds like: stating a choice and the reason in one sentence.

“I’m using a dict here for O(1) lookup — trading space for time.” “I’ll handle the empty case at the top so I don’t have to check inside the loop.” “I’ll use a tuple for the queue elements so I can hash them later.”

This is the highest-value narration because it directly populates the Problem Solving and Communication axes. Each decision-announcement is one data point the interviewer logs as evidence.

The structure is “I’m doing X because Y” (and optionally “rather than Z because W”). The “because Y” is mandatory — the announcement of what you’re doing without why is half-information. Senior candidates default to including the reason; junior candidates often state the action and assume the reason is obvious.

Frequency: roughly one decision-announcement every 90–120 seconds during active coding. Less than that and you’re under-narrating; more than that and you’re announcing trivia.

2.2 Checkpoint Narration

What it sounds like: marking a transition between sub-tasks or stating where you are in the plan.

“OK, the helper function is done; now I’ll wire it into the main loop.” “That’s the happy-path implementation. Let me handle the edge cases now.” “I think the algorithm is in place. Let me run through the example to confirm.”

Checkpoint narration serves a different function from decision-announcement: it tells the interviewer where you are in the process. It also gives them a natural intervention point — if you’ve just declared “the helper is done; now I’ll wire it in” and the interviewer wanted to push you on the helper before you move on, this is their cue to do so.

Checkpoints also help you: stating where you are forces you to confirm you’re on track. Many bugs surface at checkpoint moments because narrating “the helper is done” makes you look at it once more before moving on.

Frequency: at every meaningful sub-task boundary. In a 20-minute coding phase, this is typically 4–6 checkpoints.

2.3 Uncertainty-Surfacing Narration

What it sounds like: deliberately naming what you don’t yet know or what you’re unsure about.

“I’m not 100% sure whether the empty case should return [] or null. I’ll go with [] for now and confirm at the end.” “There’s a subtle case here with duplicate values; let me think about it for a second before I commit.” “I think this is O(n log n) but I want to double-check the inner loop’s bound after I’ve finished.”

Surfacing uncertainty deliberately — naming what you’re uncertain about and what you’ll do about it — is one of the most underused signals in the coding interview. Junior candidates hide uncertainty (or worse, mask it with confidence they don’t have); senior candidates surface it explicitly because they know it’s part of the work.

The pattern is “I’m uncertain about X; I’ll do Y for now and resolve it at Z.” The “I’ll do Y for now” is critical — surfacing uncertainty without a follow-up plan reads as flailing. Surfacing it with a plan reads as meta-cognition.

Frequency: 1–3 times per coding phase, depending on the problem’s complexity.

3. Worked Example — A Coding Phase With Strong Narration

Setting: Phase 4 of a “two-sum” coding interview (continuing from Problem Decomposition in Interviews §3). The candidate has just finished tracing on the small example and is starting to type. Their narration, interleaved with the code, runs roughly as follows.

(typing function signature) “I’ll set up the function with type hints. Input is a list of ints, target is an int, output is a list of ints.”

def two_sum(nums: list[int], target: int) -> list[int]:

(decision-announcement) “I’ll add a docstring to remind myself of the contract: distinct indices, exactly one solution per spec.”

    """Return the indices of two distinct elements that sum to target."""

(decision-announcement) “I’m using a dict for the seen-values map. Key is the value, value is the index. That gives me O(1) lookup of the complement, and storing the index lets me return both indices at the end.”

    seen: dict[int, int] = {}

(decision-announcement) “I’ll iterate with enumerate so I get the index naturally — this is more idiomatic than tracking i manually.”

    for i, v in enumerate(nums):

(decision-announcement) “Order matters here. I’ll check the complement before I insert — that way I can’t match an element with itself, which respects the distinct-indices constraint without needing extra logic.”

        complement = target - v
        if complement in seen:
            return [seen[complement], i]
        seen[v] = i

(uncertainty-surfacing) “Per spec, exactly one solution exists, so this last line is unreachable. But I want a default return for type-checker happiness. I’ll add a sentinel.”

    return []

(checkpoint) “OK, that’s the implementation. Let me run through the example to make sure I didn’t make a typo.”

The candidate then walks through the example out loud, confirming each line, and moves to Phase 5 (testing).

What this narration sounds like in aggregate: the candidate articulated five decision-announcements (use dict, use enumerate, complement-before-insert, sentinel return, and the trade-off framing on the dict), one uncertainty surfaced (sentinel for type-checker), and one checkpoint (“OK, that’s the implementation”). All in roughly 4 minutes of typing. The interviewer has, by this point, more than enough material to populate the Communication axis. Compare to a silent typing run where the same code emerges in 4 minutes with the only narration being “done.”

4. Worked Example — A Coding Phase With Weak Narration

Same problem, weak narration:

(silently typing)

def two_sum(nums, target):
    seen = {}
    for i, v in enumerate(nums):
        if target - v in seen:
            return [seen[target - v], i]
        seen[v] = i

(only spoken sentence in the entire phase): “OK, done.”

The code is functionally identical. The Communication score is meaningfully lower because nothing was said. The Problem Solving score is also lower because the interviewer has no evidence of reasoning — only of the result. Many graders would dock the candidate further on Coding because the type hints are absent (the senior version had them) and there’s no docstring. The aggregate impression is “this candidate solved the problem but didn’t show their work” — a phrase that appears on weak-hire debriefs constantly.

The two solutions are the same code. The score is not the same. The narration is the difference.

5. Phrases That Signal Seniority

Catalog of specific phrases. Borrow them. They are not “magic words”; they are concise English that names what you’re doing in a way that tracks how senior engineers actually talk.

5.1 Decision-Naming Phrases

• “I’m going to use X here because Y.”
• “The trade-off is…”
• “I considered Z but rejected it because…”
• “I’ll prioritize correctness here and optimize later if we have time.”
• “There’s a cleaner way to write this if we accept O(n) extra memory; I’ll go with that.”
• “I’d normally factor this out, but for the interview I’ll inline it for simplicity.”

5.2 Tradeoff-Vocabulary Phrases

These directly invoke the trade-off frame:

• “Trading space for time…”
• “Trading constant time for adversarial worst case…”
• “Slightly more complex, but avoids the auxiliary array…”
• “Simpler but O(n²); the input size determines whether it’s acceptable…”
• “This is O(log n) instead of O(1) but doesn’t allocate.”

5.3 Constraint-Awareness Phrases

These explicitly tie code decisions back to constraints established in Phase 1:

• “Given the input size of 10⁵, this O(n²) approach would be too slow, so I’ll skip it.”
• “Per the spec, the array is sorted, so I can use binary search.”
• “Since duplicates aren’t allowed, I don’t need to worry about the case where…”
• “The spec said exactly one solution exists, so I won’t add a ‘no solution found’ branch.”

5.4 Uncertainty-Surfacing Phrases

• “I’m not 100% sure about X. Let me handle the main case first, then revisit.”
• “There’s a subtle case with [thing] — let me think about it for a second.”
• “I want to double-check this complexity claim after I’m done coding.”
• “I think this is right but I want to trace through to be sure.”

5.5 Confirming-Direction Phrases

• “Does that match what you have in mind?”
• “Should I optimize for memory or for speed here? They have different solutions.”
• “I’m going to go with X. Sound good?”
• “I notice you said earlier that [constraint]; does that mean [implication]?”

These phrases are particularly senior because they treat the interviewer as a collaborator rather than a judge. The senior engineer collaborating on a real design problem checks in periodically; the junior candidate either silently powers ahead or asks for permission.

Uncertain

Verify: the claim that “asking for permission reads as low-confidence while asking for direction reads as senior.” Reason: this is interview-coaching folk wisdom (it recurs across prep blogs and matches the collaborator-vs-judge framing McDowell endorses), not a measured finding — no controlled study ties specific phrasings to scores. The directional distinction is widely agreed; the strength of the effect is not established. To resolve: per-phrasing scoring data from a mock-interview platform (e.g. interviewing.io) would settle it. The defensible synthesis: asking for direction on under-specified design choices signals seniority; asking for permission to start coding signals juniority. “Sound good?” after stating a plan is fine; “is it OK if I use a hash map?” sounds tentative. uncertain

5.6 Checkpoint Phrases

• “OK, that’s the [sub-task] done. Now I’ll [next sub-task].”
• “Let me pause here and run through the example.”
• “Algorithm is in place; let me think about edge cases.”
• “I think we’re good on the implementation. Moving to testing.”

5.7 Recovery Phrases (When You Catch a Bug Mid-Code)

• “Wait, I missed a case — let me back up.”
• “Actually, this won’t work for [case]. Let me adjust.”
• “I see a problem with my approach: [name it]. Let me fix it.”

These are positive signals, not negative. Catching your own bugs and fixing them mid-flow is the engineering skill that interviewers want to see. Hiding the catch (“oh um actually wait…”) signals embarrassment; naming it explicitly (“I see a problem — let me fix it”) signals confidence in error-recovery.

6. Phrases That Signal Juniority

These phrases reliably downgrade the candidate’s perceived seniority. Avoid them.

6.1 Filler Phrases

• “Let me think.”
• “Hmm.”
• “OK so.”
• “Yeah.”
• “Right.”
• “Like…”

These are the verbal equivalent of clearing your throat — they fill silence without adding information. Used sparingly they’re fine (and natural), but used constantly they read as nervous.

The replacement strategy is deliberate silence. It is fine to be silent for 15 seconds while you think. The instinct is to fill the silence with “let me think”; the senior move is to actually be silent and let the thinking happen, and then narrate the output of the thinking. (“OK, here’s what I’m going to do…” — informational, not filler.)

6.2 Tentative Phrases

• “I think maybe…”
• “Could it be that…”
• “Sort of…”
• “Kind of…”
• “I might be wrong, but…”
• “This is probably wrong but…”

Tentative phrasing makes accurate observations sound uncertain. The right replacement: state the claim with normal confidence; if you’re actually uncertain, surface the uncertainty explicitly (§5.4) rather than weaseling.

Compare:

• Tentative: “I think maybe a hash map could work here, sort of.”
• Confident: “A hash map works here for O(1) lookups.”
• Confident with deliberate uncertainty: “I think a hash map is right, but I want to verify on the example before committing.”

6.3 Apology Phrases

• “Sorry, I’m being slow.”
• “Sorry, I’m thinking.”
• “Apologies, I lost my train of thought.”

Apologies for taking time read as low-confidence. Thinking in an interview is not something to apologize for. The replacement: silence (let the thinking happen), or a checkpoint (“let me work through this for a moment”).

The exception: a genuine apology for a specific error you made (typing the wrong variable name, mis-citing a complexity) is fine. General apologies for using time are not.

6.4 Self-Disqualifying Phrases

• “I’m not really good at dynamic programming.”
• “I always struggle with recursion.”
• “I haven’t done this kind of problem in a while.”
• “I’d probably need to look this up in real life.”

These read as anxious self-deprecation. They give the interviewer a reason to lower the bar before the candidate has even tried. The replacement: be specific about your approach and let the work speak.

The “I’d need to look this up” caveat is acceptable in limited form: it’s true that engineers look things up in real work, and acknowledging that you’d verify the algorithm against a reference is mature. The bad version is using it as a preemptive excuse for not solving the problem.

6.5 Pause-Asking-Permission

• “Can I think about this for a minute?”
• “Is it OK if I take a moment?”
• “Mind if I write some scratch notes?”

You don’t need permission. The right form is to announce what you’re doing, not ask permission for it. “Let me take a moment to think about this.” / “Let me sketch out the data structure on paper first.” Both are fine.

6.6 The Apologetic Restart

• “Sorry, let me restart.”
• “Sorry, let me throw this away.”

Restarting is sometimes the right call. Apologizing for it is the wrong call. The replacement: name the problem, declare the restart. “This approach has a fundamental issue — the recursion will revisit the same states. Let me back up and switch to memoization.” This is a senior move, not an apologetic one.

7. The Filler-Reduction Drill

A specific drill for candidates who use filler heavily:

1. Record yourself doing a 15-minute mock coding interview (use a friend, an online platform like Pramp/interviewing.io, or solo with a recorded problem).
2. Listen to the playback. Count instances of: “let me think,” “hmm,” “OK so,” “yeah,” “like.”
3. Most candidates count 30–80 fillers in 15 minutes. Target: under 10.
4. Re-record. The first re-record will feel awkward — silences will feel longer than they are. That’s normal.
5. After 4–6 re-records, the filler count drops to 5–15 and feels natural. The silences feel comfortable.

This drill is the single highest-leverage intervention for candidates whose technical skills are strong but whose interview scores are inconsistent. It addresses Communication directly without changing the technical content. It also generally improves Confidence-axis ratings as a side effect, because the absence of filler reads as composed and deliberate.

8. The Sustainable-Narration Problem

A practical problem: narrating for 20 straight minutes is exhausting. Candidates often start strong and fade. By minute 15, they’re typing in silence; by minute 20, the interviewer has lost the thread.

The fix is to vary narration density across the phase. Not all moments require equal narration:

• High narration density: at decision points, at checkpoints, when surfacing uncertainty.
• Medium narration density: during routine implementation of an already-explained sub-step.
• Low narration density (silence is fine): during pure mechanical typing of a structure that was already announced.

The pattern is narrate the design; under-narrate the typing. After you’ve announced “I’m going to use a dict for the seen-values map,” the actual typing of seen: dict[int, int] = {} doesn’t need additional narration — you’ve already explained it. The next narration moment is the next decision, which might be 90 seconds later.

This pattern also makes narration sustainable: you’re not talking constantly, you’re talking at the right moments.

9. Pre-Committing to Non-Obvious Choices

A specific narration discipline that signals seniority: when you’re about to make a choice that isn’t obvious from the problem statement, announce it before committing, with the reasoning, and ask whether the interviewer wants you to proceed.

Examples of choices that warrant pre-announcement:

• Data structure choices that change the API or the complexity. (“I’m going to use a heap here for O(log n) extracts; that means the order of insertions doesn’t matter but the order of extractions is fixed. Sound good?”)
• Modifying the input. (“I can do this in-place by mutating the array; that’s O(1) extra space but the caller sees their array changed. Want me to go that direction or preserve the input?”)
• Recursion depth assumptions. (“I’m going recursive — for the constraints you mentioned, recursion depth is fine; but if there’s a strict stack-depth requirement, I can convert to iterative.”)
• External library use. (“I’d reach for bisect.bisect_left here in real Python code — fine to use that, or do you want me to implement the binary search by hand?”)

The pattern is “I’m doing X; here’s the implication; want me to proceed?” The interviewer’s answer is information you didn’t have before — sometimes they say “go ahead,” sometimes they say “actually, let’s do the other approach.” Pre-committing avoids the worst-case scenario where you implement 10 minutes of an approach the interviewer specifically didn’t want.

The trap: asking for pre-commit confirmation on every trivial choice (“can I use a for loop?”). Reserve it for choices that materially change the solution. Trivial choices (variable names, formatting) don’t need confirmation.

10. Diagram — The Narration Density Curve

flowchart LR
    P1["Phase 1: Clarify<br/>HIGH<br/>(active dialogue)"] --> P2["Phase 2: Approaches<br/>HIGH<br/>(propose + justify)"]
    P2 --> P3["Phase 3: Trace<br/>MEDIUM<br/>(narrate steps)"]
    P3 --> P4a["Phase 4 (early): Code<br/>HIGH<br/>(announce design)"]
    P4a --> P4b["Phase 4 (mid): Code<br/>LOW-MEDIUM<br/>(typing, checkpoints)"]
    P4b --> P4c["Phase 4 (late): Code<br/>MEDIUM<br/>(closing decisions, edge cases)"]
    P4c --> P5["Phase 5: Test<br/>HIGH<br/>(narrate each test case)"]
    P5 --> P6["Phase 6: Complexity<br/>HIGH<br/>(walk through analysis)"]

What this diagram shows. Narration density is not constant across the coding interview; it varies by phase and by sub-phase. The clarify and approach phases are high-density because they are inherently dialogues. The trace phase is medium because narration walks through the example. Phase 4 (coding) starts high (you announce design decisions as you set up), drops to low-medium during routine implementation (mechanical typing), and rises back up at the end as you handle edge cases and close out. Phase 5 (testing) is high again because each test case warrants a brief narration. Phase 6 (complexity) is high because the analysis is the value. The takeaway: pacing narration to this curve is what makes 25 minutes of coding sustainable. Constant-density narration is exhausting and noisy; phase-aware narration is sustainable and signal-rich.

11. Common Failure Modes

11.1 Silent Coding

Symptom: 5+ minutes of typing with no narration. The interviewer has nothing to score for that interval.

Cause: candidate’s natural mode is silent thinking; they don’t realize the interviewer needs verbal output.

Fix: set a personal alarm (mentally) every 90 seconds during coding. When it fires, say something substantive. Decision, checkpoint, or surfaced uncertainty. Practice this with timed mocks. After 20 mocks, the cadence becomes natural and the mental alarm isn’t needed.

11.2 Stream-of-Consciousness Narration

Symptom: every keystroke and every micro-thought is verbalized. The interviewer hears 1000 words but extracts no decisions.

Cause: over-correction from “you should narrate.”

Fix: narrate at the abstraction level of decisions, not at the level of typing. The unit of narration is “I’m going to do X because Y,” not “now I’m typing ‘def’.“

11.3 Silent on Hard Parts

Symptom: candidate narrates well during easy implementation, falls silent precisely when stuck on the hard part.

Cause: they’re stuck and embarrassed about being stuck.

Fix: when stuck, narrate the stuck-ness. “I’m thinking through whether the recursion needs to handle [case]; let me work through it on paper.” This converts a silent dead-zone into a Communication-positive signal. The interviewer knows you’re stuck either way; explicit acknowledgment + a plan to resolve scores higher than mute pondering.

11.4 Asking Excessive Permission

Symptom: candidate asks “is this OK?” / “should I…” every other line.

Cause: hedging against making a wrong call.

Fix: pre-commit on substantive choices (§9), but proceed without asking on trivia. Excessive permission-seeking reads as low-confidence and slows the round.

11.5 Narrating in the Past Tense

Symptom: candidate completes a sub-step, then narrates what they did. “I just used a dict to look up the complement.”

Cause: narration is reactive instead of concurrent.

Fix: narrate as the decision is made, not after. “I’m going to use a dict” (then implement). The forward-looking narration tells the interviewer where you’re heading; the past-looking narration only confirms what they already saw on screen.

11.6 Different Voice for Different Audiences

Symptom: candidate sounds confident when narrating something they’re sure about, then sounds tentative when narrating something they’re unsure about — but doesn’t explicitly surface the uncertainty.

Cause: the uncertainty is leaking through tone instead of being articulated.

Fix: when you feel uncertainty, say so (§5.4). The articulated uncertainty is a positive signal; the leaked-through-tone uncertainty is a negative signal. Same content; framing matters.

11.7 Forgetting to Announce a Decision

Symptom: candidate makes a non-obvious choice silently. The interviewer can’t tell whether it was deliberate or accidental.

Cause: the choice felt obvious to the candidate, who didn’t realize it was non-obvious to the observer.

Fix: when in doubt, narrate. Especially for choices about data structure, recursion vs iteration, mutation vs immutability, error-handling style.

11.8 Not Leaving Pauses for Interviewer Input

Symptom: candidate narrates continuously; interviewer can’t get a word in. Even when the interviewer has a hint or a redirect, they have no opening.

Cause: the candidate is using narration as a defense against silence — talking constantly so the interviewer can’t surprise them.

Fix: leave 2–3 second pauses at natural break points (after a decision, after a checkpoint, after a sub-task). These pauses are explicit invitations for the interviewer to chime in. Most won’t; some will; the ones who do are giving you a hint you should welcome.

11.9 Stale Reasoning

Symptom: candidate cites a complexity or constraint that’s no longer accurate after they pivoted.

Cause: narration didn’t update when the plan did.

Fix: when you change the approach, explicitly re-announce. “I was planning to do X but actually that won’t handle [case], so I’m switching to Y. The complexity is now [Y’s complexity].” The pivot is a signal of meta-cognition; hiding it is a signal of confusion.

11.10 Reciting Memorized Phrases

Symptom: candidate uses interview-prep phrases (“trade-off space for time”) in contexts where they don’t quite fit.

Cause: borrowed phrases without internalizing them.

Fix: only use a phrase if you can defend it if challenged. If the interviewer pushes back (“but is it really a space-for-time trade-off here?”), you should be able to engage with the question, not just stumble. The phrases in §5 are tools, not magic; use them when they accurately describe what you’re doing.

12. Decision Diagram — When to Speak vs When to Be Silent

flowchart TD
    Moment["Current moment in coding"] --> Type{"What's happening?"}
    Type -->|"Making a non-obvious choice"| Speak1["SPEAK: Decision-announce<br/>(§5.1)"]
    Type -->|"Crossing a sub-task boundary"| Speak2["SPEAK: Checkpoint<br/>(§5.6)"]
    Type -->|"Discovering uncertainty"| Speak3["SPEAK: Surface uncertainty<br/>(§5.4)"]
    Type -->|"Catching a bug"| Speak4["SPEAK: Recovery<br/>(§5.7)"]
    Type -->|"About to commit to non-obvious approach"| Speak5["SPEAK: Pre-commit<br/>(§9)"]
    Type -->|"Routine typing of already-announced design"| Silent1["SILENCE OK<br/>(don't narrate keystrokes)"]
    Type -->|"Brief thinking pause (<15 sec)"| Silent2["SILENCE OK<br/>(don't fill with 'um')"]
    Type -->|"Long thinking pause (>15 sec)"| Speak6["SPEAK: Acknowledge<br/>('Let me work through this')"]
    Speak1 --> Done["Continue"]
    Speak2 --> Done
    Speak3 --> Done
    Speak4 --> Done
    Speak5 --> Done
    Speak6 --> Done
    Silent1 --> Done
    Silent2 --> Done

What this diagram shows. The decision flow for whether to speak in a given moment. The “speak” branches enumerate the high-value narration types from §5; the “silence OK” branches name the moments where silence is appropriate. The 15-second threshold for thinking pauses is approximate but useful: under 15 seconds, silence reads as concentration; over 15 seconds, it reads as stuck. The fix when crossing the threshold is not to fill with “um” but to explicitly acknowledge what you’re doing (“let me work through this for a moment”). The diagram’s overall shape: most moments warrant speaking, but routine typing and brief thinking pauses are the legitimate silent moments.

13. Pitfalls

13.1 Letting Filler Crowd Out Substance

Even after the filler-reduction drill, watch for backsliding under stress. The “let me think” replacement isn’t more talking; it’s deliberate silence followed by substantive narration.

13.2 Narrating What’s Visible

Don’t narrate what the interviewer can already see on the screen. “I’m typing the function signature” is wasted breath; the interviewer is watching you type the function signature. “I’m structuring this with a helper because the main loop is going to be cleaner” is value-add — that’s the reasoning behind the visible action.

13.3 Silence as Aggression

Some candidates use silence as a power play, especially in a take-home or async setting. In a live coding round, silence past 30 seconds reads as stuck or disengaged regardless of intent. Don’t use silence strategically; use it functionally.

13.4 Performance Voice

Symptom: candidate’s natural speech is normal; their interview narration is theatrical or over-articulated.

Cause: they’re consciously “performing” being a senior engineer.

Fix: borrow phrases (§5), but use them in your normal voice. The phrases are linguistic tools; the delivery should be conversational. Performative narration reads as inauthentic.

13.5 Not Treating the Interviewer as a Collaborator

Some candidates frame the interviewer as a judge — distant, evaluative, to-be-impressed. The senior framing is collaborator — you’re solving a problem together, with you driving and them advising. The collaborator framing produces better narration because you’re naturally including them in the work.

13.6 Forgetting to Listen

Symptom: candidate narrates well but doesn’t pause for interviewer input; misses hints.

Cause: focused entirely on output.

Fix: explicit pauses (see §11.8). Also: when the interviewer asks a question, stop coding and address the question fully before resuming. Half-listening while continuing to type is worse than no narration.

13.7 Different Languages Need Different Narration

A candidate fluent in Python but interviewing in Java may narrate in Python idioms (“I’d use a list comprehension here”) that don’t apply. The narration should match the language being used. Practice in your interview language, not just your favorite language.

13.8 Over-Specifying Trade-offs That Aren’t Real

Symptom: candidate cites a trade-off that doesn’t actually exist. “This is O(n) instead of O(log n) but it’s simpler.” — except the O(log n) version doesn’t exist for this problem.

Cause: borrowed phrasing applied where it doesn’t fit.

Fix: only cite a trade-off if you can name both sides of it. If you can’t articulate the alternative, don’t claim it exists.

13.9 Narration as Coverage Strategy

Symptom: candidate narrates extensively to mask that they don’t know the answer.

Cause: hoping volume substitutes for insight.

Fix: it doesn’t. Verbose-but-vacuous narration is worse than silent thinking — interviewers identify it quickly. Narration is signal-rich only when the underlying thinking is solid. Solve the problem first; narrate the solution.

13.10 Volume Mismatch in Remote Interviews

Symptom: candidate’s narration is appropriate in volume but their microphone is too quiet, so the interviewer hears half of what they say.

Cause: technical setup issue.

Fix: pre-interview audio check. Ask “can you hear me clearly?” at the start. Worth the 30 seconds.

14. Open Questions

• How does narration scoring vary across remote vs in-person interviews? Anecdotally, remote rounds penalize silence more (the interviewer has fewer non-verbal cues); in-person allows more silent thinking because body language partially compensates. Not directly addressed by the interviewing.io communication study, which pooled remote interviews.
• Resolved (partially). Is the Communicate score the dominant axis? No — interviewing.io’s 100K-interview analysis found it has the smallest marginal effect at junior level, with a floor effect (you must clear a “2”) and an inversion at senior level where it matters more (interviewing.io 2020). The note’s §1 now reflects this. Still open: a within-Communicate comparison of “say everything” vs “say only substantive things” — the study scores the axis but does not break out narration style.
• How does narration interact with non-native English fluency? Specifically: candidates often suppress narration because they’re worried about grammar; but the rubric scores Communication on substance, not on grammatical perfection. Verify with diversity-and-inclusion interview research.

15. See Also

• Problem Decomposition in Interviews — the six-phase rhythm; this note details Phase 4’s narration
• Time Management in Interviews — how narration density interacts with pacing
• STAR Framework — analogous narration for behavioral round
• CAR Framework — lighter behavioral framework
• Picking Stories — Coverage Matrix — preparing the behavioral content that narrates well
• Edge Cases Checklist — what to narrate during testing (planned)
• Debugging Under Pressure — narration when bugs appear (planned)
• FAANG Interview Loops — what the Communication axis looks like across companies
• Levels and Calibration — how seniority shifts narration expectations
• How to Practice — Spaced Repetition for Algorithms — incorporating narration into practice
• System Design Interview Framework — analogous narration for system design (planned)
• SWE Interview Preparation MOC