How to talk during a coding interview

An interviewer scores what you say. It is the only thing they can see.

Working code with ten minutes of silence scores worse than half a solution you narrated.

This surprises people. It is also the most fixable thing on the list.

What they are actually filling in

Most rubrics come down to four questions.

Did you understand the problem. Did you choose an approach for a reason. Can you write correct code. Did you check your own work.

Three of those four live in your head.

Unsaid means scored as absent. An interviewer who cannot follow your reasoning assumes there was none.

The four sentences

Say these, roughly in this order, every time.

"So the input is X and I return Y." Confirms the problem. Cheap insurance against twenty wasted minutes.

"The word that stands out is Z. That suggests a window." This is the sentence people skip.

That sentence is graded hardest. It shows recognition, not memory.

"The naive version is O(n squared). Let me say why before improving it." Naming the slow version first is a strength. It shows you know what you are trading away.

"Let me try the empty array." Checking your own work unprompted moves you a whole band.

The failure mode nobody warns you about

People narrate their typing. "Now a variable called left, set to zero. Now a while loop."

Narrating your typing is a screen reader. It carries no information the interviewer does not already have.

Narrate decisions instead. Why two pointers and not a hash map. Why left moves here and not there. What has to stay true on every iteration.

A decision has an alternative behind it. No alternative means it was not worth saying.

What to do when you are stuck

Say that you are stuck, then say what you have.

"I know it is not a plain window because of the negatives. I am trying to decide between sorting and a prefix sum. Sorting loses the order, and I think the order matters here."

Three sentences, two jobs. You stay scored while you think. The interviewer gets something to hint at.

Silence gives them nothing. So they wait. Then the clock does the rest.

How to practise it

Talking while solving is its own skill. At first it steals attention from the solving.

Researchers have used think-aloud protocols for decades for that reason.

Rehearse thinking out loud separately.

• Solve one problem a week out loud, recorded, alone. Put it in the timed slot.
• Listen back at double speed. Count how many sentences were decisions.
• Explain a solved problem to someone who does not code. This is rubber duck debugging pointed at your own understanding.

The recording is unpleasant. It is also the fastest feedback available.

Where this is built in

AlgoPath asks for the justification in writing first. Name the pattern. Say which signal pointed there. Then code.

Write it every time. Saying it out loud becomes a short step.

Where the spoken attempt sits: how to prepare.

What to say first comes out of reading the statement.

The first 33 steps are free.