What should I say out loud in a coding interview?
Restate the problem, ask clarifying questions, state a brute-force approach with its complexity, propose an improvement, then code. Narrate what you are doing as you type.
#1. Restate it
"So I get an array of integers and a target, and I need to return the indices of the two numbers that sum to it — not the numbers themselves. Is that right?"
Ten seconds, and it catches misunderstandings before you have written anything.
#2. Ask
- Can the input be empty? Can it contain duplicates? Negatives?
- Is it sorted? Can I sort it?
- Is there exactly one answer, or could there be several?
- How large can the input get?
- Should I return a value or modify in place?
These are not stalling. Real requirements are ambiguous, and probing them is the job.
#3. Brute force, with its cost
"The obvious approach is a nested loop, which is O(n²). Let me see if I can do better."
Never skip this. It proves you have a correct baseline and it gives the interviewer a chance to say "that is fine, code it" if that is what they wanted.
#4. The improvement, before you type
"Instead of scanning for the partner, I could store what I have seen in a hash map, so the lookup is O(1). That makes the whole thing one pass, O(n) time and O(n) space."
Get agreement here. Ten seconds of confirmation beats fifteen minutes coding the wrong thing.
#5. Narrate while coding
"I'll keep a dict from value to index... checking before inserting so an element can't pair with itself..."
#6. Test it by hand
Walk through a small example out loud, then the edge cases: empty, one element, duplicates, no answer.
#7. Close with complexity
"O(n) time, O(n) space. If the array were sorted I could use two pointers and drop to O(1) extra space."
#What actually fails candidates
Rarely the algorithm. It is silence, jumping straight to code, not handling edge cases, and being unable to explain their own solution. All four are fixable by talking.