Same class, different evidence
Picture a common machine coding task, a bounded blocking queue: put waits while the buffer is full, take waits while it is empty. Two candidates write the same thirty lines, with one intrinsic lock, a while loop around wait(), and notifyAll() after every change.
Candidate A says nothing and starts typing. Candidate B says this first:
"I will use a single monitor with synchronized and notifyAll. Two conditions on a ReentrantLock would let me wake only the side that can proceed, which is cheaper under contention, but one monitor is simpler to get right in the time. The cost is that every change wakes every waiter. I am assuming you want me to build it rather than wrap ArrayBlockingQueue. Is that right?"
That is about ten seconds of speech. The code that follows is the same. The scorecards from this coding interview are not.
What the interviewer can and cannot see in code
In a coding interview, code shows what you chose. It does not show whether you knew there was a choice. When candidate A writes notifyAll, the interviewer cannot tell whether they know why notify would be dangerous here, or just remember that notifyAll is the safe default. The same goes for the while loop: correct, but it might be understanding or might be habit.
So the interviewer has to find out afterwards, by asking. Each answer is now a recovery from a question rather than a decision offered unprompted, and recovered evidence is weaker. Candidate B gave the same facts up front, so the follow-ups become confirmation rather than interrogation.
For a senior candidate this is often the whole difference. At senior level the reasoning behind a choice is part of the deliverable, not a courtesy. Writing correct code silently is mid-level evidence, however clean the code is.
The four things the ten seconds contains
This is not the general advice to think aloud, which the interviewer psychology guide already treats, including when narration becomes noise. It is one short beat at one moment, between deciding and typing, and it has a fixed shape.
- The approach, in one clause.
- The rejected alternative, by name, with the reason it lost.
- The cost of what you chose: the case it handles badly.
- The open fork you need settled before typing, if there is one.
The fourth matters most in a machine coding round because of one recurring fork: build it yourself or use the library. A candidate who silently wraps ArrayBlockingQueue may be told to start again at minute twenty. A candidate who silently builds it may have spent twenty minutes the interviewer would happily have given back. One question settles it.
The class itself, with the announced decisions visible
The comments mark the lines the announcement already justified, which is the point: nothing here should surprise an interviewer who heard the ten seconds.
Narration is not the same as announcing
The failing version of this advice is a candidate who narrates every keystroke. "Now I am adding a field for the head. Now a constructor." That is not an announcement, because it carries no decision, and it makes the decisions that do exist harder to hear. The beat is ten seconds before typing. After that you type, and you speak again only when something changes: a bug, a better idea, a requirement you misread.
The other failure is announcing and then writing something else. If you said single monitor and wrote two conditions, the interviewer now has evidence that your stated plan does not predict your code. Changing your mind is fine. Say so as it happens, in one sentence.
Why the silent candidate loses even when the code is better
The mistaken belief is that correct code speaks for itself. It speaks for the result, not for the judgement behind it, and machine coding at senior level grades the judgement. A silent candidate with slightly better code can lose to a candidate whose ten seconds showed they knew the trade-off, because the interviewer must write down something the candidate did. "Wrote correct code" is a thinner line than "chose a single monitor over two conditions for simplicity, named the wake-all cost, and confirmed build versus library before starting."
There is a practical gain too, and it matters more in machine coding than in a whiteboard coding interview, because the clock is spent on real code. The announcement invites a correction while it is cheap. An interviewer who wanted to see two conditions will tell you at second ten, not minute twenty-five.
Before the first keystroke, say what you are building, what you are not building instead, and what your choice costs. Then type, and let the code prove the sentence.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).