Silence is the most common reason good engineers underperform in coding interviews. The interviewer cannot give credit for reasoning they cannot hear. Thinking out loud is a skill, and it can be practised with a simple structure.
Restate the problem and confirm constraints
Repeat the problem in your own words and ask about input size, value ranges, duplicates, empty inputs and expected output format. This catches misunderstandings early and shows you think about edge cases before writing code.
Say the brute-force solution first
Describe the simplest correct approach and its complexity, even if you know it is too slow. It proves you can solve the problem and gives you a baseline to improve on.
Then look for the bottleneck. Repeated work usually points to a hash map, sorting, two pointers or memoisation.
Narrate decisions, not keystrokes
You do not need to describe every line you type. Explain decisions: why this data structure, why this loop boundary, what this variable represents.
- “I will use a map from value to index so lookups are constant time.”
- “This loop stops one early because I compare pairs.”
- “This handles the empty-input case we discussed.”
Test like a reviewer
Walk through a small example by hand, then the edge cases you listed at the start. Finish by stating time and space complexity. If you spot a bug, saying so calmly and fixing it is a positive signal.