Talk While You Code: The Habit That Passes Coding Interviews

I've been on the interviewer side of a lot of coding loops, and the hardest writeup to do is for the candidate who clearly knew their stuff but spent 40 minutes in near silence. You can tell they're smart. You just have almost nothing to grade.

That's the uncomfortable mechanic most candidates never internalize: interviewers can't grade what they can't hear. Nearly every rubric I've worked from had communication, collaboration, and reasoning under uncertainty on it somewhere, and all of those are invisible if you don't talk. A perfect solution reached silently can easily score worse than a good solution reached out loud, because silence leaves those boxes blank no matter how clean the code is.

To make it concrete, here's the same solution to "find the longest substring without repeating characters," narrated two ways. These are composites of interviews I've actually sat through, with details changed.

The silent solver

"Okay, let me think." [4 minutes of typing and silence] "Hmm. Wait." [2 more minutes of silence, deletes a block of code] "Okay, I think this works. Should I run through an example?"

What tends to end up in the notes afterward: "Unclear how candidate arrived at approach. Could not evaluate problem-solving process. Possibly a memorized solution." That last one is the killer, and I've had to write a version of it myself. From the other side of the table, silence followed by a clean answer looks a lot like memorization, even when it isn't, and you really don't want to leave that ambiguity hanging over your debrief.

The narrator (same solution, same speed)

"So I need the longest substring with no repeats. Brute force is checking every substring, and there are O(n²) of those before I even validate them, so let me see if there's a linear approach. Repeating characters make me think of tracking what I've seen, so a set or a map. And 'contiguous substring with a condition' smells like sliding window. So: two pointers. The right pointer expands, and when I hit a character already in my window, I move the left pointer up. If I use a hashmap of char to last index instead of a set, I can jump the left pointer directly instead of shrinking one step at a time. I just have to take the max with where left already is, so the window never moves backward. Edge cases before I finish: empty string, all identical characters, no repeats at all. Let me trace 'abba', because that's exactly the case that punishes you if you skip that max..."

Same solution, same time on the clock, and a completely different writeup. The second candidate showed me pattern recognition, complexity analysis, edge case thinking, and even caught the classic bug in this problem out loud, before I ever asked a follow-up.

How to actually build the habit

It feels unnatural for almost everyone at first, so don't be too hard on yourself if you recognized yourself in the first transcript.

1. Narrate your triggers. "X makes me think of Y" might be the highest value sentence you can say in a coding interview, because it shows how you recognize patterns rather than just that you've seen this exact problem before.
2. Say the brute force out loud even when you'd never write it. It banks partial credit right away and buys you time to think.
3. Announce your plan before you start typing. I spend a good amount of time backpacking in the backcountry, and the rule when navigating with a partner is that you talk through route decisions out loud, because a quiet wrong turn compounds for miles before anyone catches it. Interviews work the same way. When a candidate told me a flawed plan before coding, I could usually nudge them back on course within a minute; the ones who coded it silently found out 10 minutes later, with no time left to recover.
4. Announced silence is fine, by the way. "Give me a minute to sketch this out" buys you real thinking time without leaving the interviewer in the dark. It's the unannounced kind that hurts you.
5. Practice it for real. Record yourself, set up a peer mock, or use an AI mock. Honestly, a phone recording and one brutally honest friend cover a lot of this for free; the only thing that doesn't work is skipping the out-loud reps.

Narrating your thinking is a skill, and like any skill it comes from reps, not from reading about it. If you want to practice it out loud with something that responds and pushes back, that's exactly what we built Preppable to do. And if you'd rather do it with a phone recording and a patient friend, that works too. Just do the reps out loud before the round that counts.