Think out loud: the coding-round habit that changes outcomes

I've watched candidates solve the problem perfectly and still get a "no hire". The feedback is almost always the same: we couldn't tell how they got there.

A coding interview is not a test of whether you can produce the answer. It's a test of whether someone would enjoy debugging production with you at 2 a.m. That means your reasoning has to be audible.

The four-beat narration pattern

You don't need to talk constantly. You need to talk at four moments:

1. Restate — "So I'm given a string and need the longest substring with no repeated characters."
2. Plan — "Brute force is O(n²). I think a sliding window gets us to O(n)."
3. Checkpoint — "The window is valid here, so I'll update the best length."
4. Verify — "Let me walk through abcabcbb to check the left pointer moves correctly."

Between those beats, it's fine to type quietly.

Ask the clarifying questions out loud

Even when you know the answer, ask. It signals that you don't jump to code in real work either.

• What's the input size? Can it be empty?
• Are characters limited to ASCII?
• Do you want the length or the substring itself?

Narrate the trade-off, not just the solution

The strongest signal you can give is a trade-off said aloud:

def length_of_longest(s: str) -> int:
    seen, left, best = {}, 0, 0
    for i, ch in enumerate(s):
        if ch in seen and seen[ch] >= left:
            left = seen[ch] + 1
        seen[ch] = i
        best = max(best, i - left + 1)
    return best

"I'm using a dict instead of a set so the left pointer can jump directly instead of shrinking one step at a time. Same O(n), fewer operations, at the cost of O(k) memory for the alphabet."

When you get stuck, say so — precisely

"I'm stuck" invites a rescue. "I'm stuck on how to handle a repeat that's outside the current window" invites a conversation, and interviewers love giving hints to people who can pinpoint the problem.

Test like a reviewer would

Before saying "done", run through three cases out loud: a normal case, an edge case (empty string), and a tricky case (abba). Catching your own bug is worth more than never writing one.

Practise the talking, not just the problems

Most people grind problems silently, then wonder why the real interview feels different. Next time you practise, record yourself. If the recording would make sense to someone who can't see your screen, you're ready.