Coding interview communication

Two engineers solve the same medium-difficulty problem in a Google phone screen. Both produce correct, optimal code in time. One gets a strong hire recommendation. The other gets a "lean no." What separated them wasn't ability. It was coding interview communication. One engineer narrated their reasoning while the other typed in silence.

What coding interview communication actually is

Coding interview communication is the practice of narrating your reasoning out loud as you solve a problem. It covers four stages: restating the problem in your own words, explaining what you'll try, narrating implementation decisions as you code, and verifying correctness by tracing through examples. The skill is trainable and worth practicing separately from algorithmic knowledge.

Most candidates treat communication as optional. They think the code speaks for itself. But interviewers at Google, Amazon, Meta, and other top companies explicitly score your reasoning process as a separate dimension from correctness. An engineer who says "I'm choosing a sliding window here because the problem asks for an optimal contiguous subarray under a constraint" scores higher than one who silently writes the same correct solution. For a deeper look at what Google evaluates beyond correctness, see what Google looks for in coding interview candidates.

You don't need to be extroverted or naturally articulate to do this well. The structure is learnable. Engineers who've never narrated their thinking during practice find it disorienting at first. But the process is mechanical enough that anyone can pick it up.

There's a common belief that interview communication is a "soft skill" you either have or you don't. That framing is wrong. It's closer to a protocol you learn the way you'd learn a pattern. You learn the stages, practice them, and they become automatic.

The four stages of interview narration

Every coding interview problem moves through the same four phases. Your narration should match each one.

Stage 1: Restate the problem

Before touching code, restate the problem in your own words. This confirms you understood the question correctly, because the interviewer will correct you if you didn't. It also forces you to identify the constraints that matter. "So the input is a string, and I need to find the length of the longest substring where no character repeats. The output is an integer."

Stage 2: Explain your approach

This is where most candidates go silent. They jump straight from reading the problem to writing code. Instead, state which method you're considering and why. "The 'longest contiguous range' phrasing combined with the character uniqueness constraint points me toward a variable sliding window. I'll expand the right boundary to include new characters and contract the left boundary when I see a repeat." If you're weighing multiple options, say that too. "My first instinct is brute force with nested loops, but that's O(n²). The sliding window gets this to O(n) because each character enters and leaves the window at most once."

Stage 3: Narrate as you implement

You don't need to explain every line. But at each decision point, say what you're doing and why. "I'm using a hash map to track the last index of each character so I can jump the left pointer forward when I hit a duplicate." If you catch a potential issue while coding, say it out loud. "Wait, I need to make sure the left pointer only moves forward, never backward."

Stage 4: Verify correctness

After writing your solution, trace through an example out loud. Don't just say "looks right." Walk through a concrete input. "For the string 'abcabcbb', my window starts empty. I add 'a', 'b', 'c', and the window is now [a,b,c] with length 3. When I hit the second 'a', I move left past the first 'a'." This catches bugs before you click submit and shows the interviewer a proof of correctness that most candidates skip entirely.

What this sounds like on a real problem

Take Longest substring without repeating characters. Here's the full narration from start to finish.

Stage 1: Restate the problem

"I'm given a string and need to find the length of the longest substring with no repeating characters. The input is one string, output is an integer. No constraints on character set mentioned, so I'll assume standard ASCII."

Stage 2: Explain your approach

"This asks for the longest contiguous range satisfying a condition on uniqueness. That's a classic variable sliding window. I'll maintain a window [left, right] and expand right until I see a duplicate. When I do, I'll shrink from the left until the duplicate is gone. I'll track character positions with a hash map so I can jump left forward efficiently. Time is O(n), space is O(min(n, alphabet size))."

Stage 3: Narrate as you implement

"I'm iterating right across the string. For each character, I check if it's already in my hash map and if its stored index is within the current window. That second condition matters. If I've seen 'a' before but it's to the left of my current window, it doesn't count as a duplicate. When I do find a real duplicate, I move left past the previous occurrence. Then I update the hash map and track the maximum window length."

Stage 4: Verify correctness

"Let me trace 'abcabcbb'. At index 0, 'a' isn't in the map, so the window is [a] with max=1. Index 1 adds 'b', window becomes [a,b], max=2. Then 'c' at index 2 grows it to [a,b,c], max=3. At index 3, 'a' is in the map at position 0, which is >= left(0), so left moves to 1. Window is [b,c,a], max stays 3. Index 4 finds 'b' in the map at position 1, which is >= left(1), so left moves to 2. Window is [c,a,b], max stays 3. Continuing through the rest, the window never exceeds length 3. The result is 3, which is correct."

That's roughly 90 seconds of narration total. The interviewer heard your constraint identification, your pattern selection, your implementation reasoning, and your verification. Even if you'd made a small bug, the verification step would've caught it before submission.

The mistakes that quietly cost you points

These don't feel like mistakes while you're making them. That's what makes them expensive.

How to practice coding interview communication

Knowing the four stages and actually using them under pressure are different things. The kind of practice matters.

Start with problems you've already solved. Pick any medium-difficulty problem where you know the solution, and solve it again while narrating out loud. Recording yourself helps even more. The first time, you'll notice how often you go silent during implementation. That awareness is the starting point.

Then move to unseen problems with a timer. Give yourself 25 minutes to solve and narrate simultaneously. The timer creates the pressure that makes narration hard, and that's exactly the condition you need to train under. Practicing with different problem types, timed constraints, and with or without a listener builds a stronger habit than repeating the same comfortable routine. The research on retrieval practice supports this: verbalizing your reasoning strengthens the understanding it's built on.

If you can practice with another person, do it. A study partner or gives you the social pressure of someone listening to your reasoning in real time. That's the piece you can't replicate alone, and it's what makes real interviews feel familiar instead of foreign.

On Codeintuition, Interview Mode recreates this pressure. The problem name is hidden, the timer is running, and you get limited execution attempts. You can't trial-and-error your way to a solution. That forces you to reason first and code second, which is the exact habit that strong coding interview communication depends on. The identification lesson for variable sliding windows trains the "explain what you'll try" stage specifically by teaching the structural triggers that tell you when the pattern applies, before you see any problem.

For the complete interview preparation playbook, including how communication fits alongside pattern training and time management, see our FAANG interview preparation playbook. If you want to practice the narration habit with real sliding window problems, the Arrays course covers the full variable sliding window sequence and it's free. Full access to all 16 courses is $6.67/month billed annually.

Before your next interview, solve one problem you've never seen with a 25-minute timer and your voice recorder on. Then compare that recording to solving the same problem silently. The difference in how much reasoning you actually articulate versus how much you think you articulate is usually surprising. That gap is what practice closes.