The silent failure
The most common failure in a technical interview is not a wrong answer. It is reading the prompt, saying "okay, I think I know how to do this," and then going quiet for 20 minutes while you type.
Working code delivered in silence still costs you the interview. The interviewer is not only checking your output. They are watching how you think, and silence gives them nothing to evaluate. If you cannot narrate a decision, they have to guess whether you understood the problem or got lucky.
A framework for narrating your thinking
Use the same sequence every time so it becomes automatic under pressure.
- Clarify first. Repeat the question in your own words and ask about constraints: can the array be empty, can numbers be negative, is the input sorted.
- Say the brute force out loud. Describe the naive approach, even at O(n^2), before you touch the optimal one. It proves you understood the problem and buys you time to think.
- Propose the optimization, then check in. "I think a hash map gets this to O(n). Does that sound right to you?" Wait for a response before you start typing.
- Narrate as you type. "This loop builds the frequency count, this one checks it." A few words per line is enough. Total silence is the only wrong amount.
Practicing this before it counts
Solving problems alone does not train this, because nothing you say gets evaluated. You need something that reacts to what you say and follows up when you skip a step.
CodeSparring's AI interviewer follows your code as you write it and asks about the choices you make, in voice or text. Sessions are scored on communication alongside problem solving and code quality, so going quiet costs you even when the code ends up correct. See what a scored session looks like in the sample sessions.