Two candidates produce the same working solution to the same problem in the same time. One is a strong hire and one is a no-hire. This happens constantly, and it is not arbitrary — they were being scored on things the code does not capture.
What the rubric usually contains
- →Problem solving — how you got to the approach, not just which approach.
- →Coding — whether the implementation matches the plan you described.
- →Verification — whether you found your own bugs before being told.
- →Communication — whether the interviewer could follow you without asking.
Only the second is about the algorithm. A silent candidate who writes perfect code scores well on one dimension out of four.
Say the brute force out loud
Candidates skip it, thinking it makes them look slow. It does the opposite. Stating the brute force establishes that you understand the problem, gives a correctness baseline to improve on, and makes the optimisation legible as a decision rather than a memory.
'The obvious approach is every pair, which is quadratic. That is too slow for n up to a hundred thousand, so I need to either sort or trade space. The array is unsorted and I only need existence, so a hash map — linear time, linear space.' Thirty seconds, and it demonstrates more than the code will.
Interviewers are trying to predict what you are like on a problem nobody has solved yet. Reciting a memorised solution predicts almost nothing. Reasoning from constraints to a choice predicts a lot.
Ask about the input before you write
Can it be empty? Are values unique? Sorted? Do they fit in a 32-bit integer? Can there be negatives? Are we optimising time or memory? Two or three of these, asked before coding, are worth more than catching them afterwards — and catching them afterwards is still much better than not catching them.
Test before you are asked
The strongest signal available for cheap: when the code is written, pick a small input and walk it, out loud, line by line. Candidates who do this find their own off-by-one about a third of the time. Finding your own bug scores better than never having one, because it demonstrates a habit that survives contact with production.
Narrate decisions, not keystrokes
'Now I set i to zero' tells the interviewer nothing they cannot see. 'I am using two pointers because the array is sorted, so I can discard from whichever end fails' tells them how you think. Silence is the worst option; describing your typing is the second worst.
When you are stuck
Being stuck is expected and is not itself a negative. How you are stuck is what is scored.
- →Good: 'I am trying to avoid recomputing the maximum for every window. I want a structure that gives me a maximum and supports removal from one end — that suggests a deque or a heap. Let me think about which.'
- →Bad: silence, or repeatedly rewriting the same loop.
- →Also good: 'I think I need a hint on the data structure — can I describe what property I need?'
State the complexity without being asked
Both time and space, with the reason. 'Linear time, one pass; linear space for the map. If memory were tight I could sort and use two pointers instead — n log n time, constant extra space.' Naming the trade-off you did not take is what separates someone who chose from someone who recalled.
The uncomfortable part
All of this is practisable, and almost nobody practises it, because it is only exercised under observation. Solving alone builds one dimension of four. That is the entire argument for mock rounds — not the problems, which you can get anywhere, but rehearsing the other three dimensions with someone watching.
Reading about a pattern is not the same as producing it under time pressure. The problems that drill this are in the curriculum, in order.