Stuck in a Coding Interview: A Recovery Playbook
What to do in the 90 seconds after you freeze in a coding interview: name the kind of stuck, narrate, shrink the problem, and take hints without losing points.
- blanking in an interview
- taking hints interview
- coding interview mistakes
- interview recovery script
Short answer: when you get stuck in a coding interview, keep talking. Restate what you know, solve a tiny example by hand, and tell the interviewer the specific thing you are missing. Being stuck rarely costs much on its own. Going silent while stuck does.
Everyone stalls at some point. The candidates who do well are the ones whose stall lasts forty seconds instead of eight minutes, and who talk their way out of it.
First, work out which kind of stuck you are
Each kind needs a different move, so diagnose before you start thrashing:
| Kind | Symptom | The move |
|---|---|---|
| No approach | You have read the problem three times and have nothing | Solve a smaller version by hand |
| Approach will not scale | You have a brute force and no idea how to improve it | Look for repeated work |
| Bug you cannot find | The logic looks right, the output is wrong | Trace one input, out loud, step by step |
| Wrong turn | Ten minutes into an approach that is falling apart | Say so, and say what backing out costs |
The ninety-second protocol
When your mind goes blank, do this instead of freezing:
- Say "let me think about this out loud for a second." The silence that follows now reads as deliberate.
- Restate what you know. Inputs, constraints, the output shape, and what you have already ruled out. Surprisingly often the missing idea falls out of this step.
- Shrink the problem. Solve n = 2 or n = 3 by hand. A concrete example breaks a mental block faster than staring at the general case.
- Say what would unblock you. "I think I need a way to look up the complement in constant time" invites a hint that costs you very little, because you supplied the direction.
That last step does most of the work. An interviewer who hears a specific blocker can give a specific nudge. An interviewer watching silence has to guess whether you are thinking or lost, and most will guess lost.
Finding the repeated work
When the brute force is obvious but the optimisation is not, ask: what am I computing more than once?
- Repeated lookups: use a hash map or set (Two Sum)
- Repeated range sums: use prefix sums
- Repeated min or max over a sliding window: use a monotonic deque or a heap (Sliding Window Maximum)
- Repeated subproblems: memoise (Coin Change)
- Rescanning after every insert: keep the data sorted, or use a heap (Kth Largest Element)
A large share of standard interview optimisations come from that list. Walk through it out loud. It is a search you can still run under stress, and it pairs well with the data structure decision guide.
Taking a hint without losing points
What matters is what you do with a hint, not that you needed one. Two responses to the same nudge:
"Oh, a hash map. Okay." Then silent typing.
"A hash map, so I trade O(n) memory for constant-time lookup, which takes me from O(n²) to O(n). Let me redo the loop with that." Then typing.
Same hint. The second response wins back most of the credit because you extended the idea instead of just accepting it. It is the same thinking-out-loud habit that carries the rest of the round.
What actually costs you
- Silence longer than about thirty seconds. The interviewer cannot give credit for reasoning they cannot hear.
- Defending a dead approach after it is clearly failing. Backing out costs two minutes. Stubbornness can cost the round.
- Guess-and-check debugging. Flipping
<to<=at random tells the interviewer you do not have a model of your own code. - Throwing away a working brute force with eight minutes left because it is not optimal. Something correct beats half of something elegant.
Most rubrics weight problem solving and communication heavily, and both are visible while you are stuck. See what human interviewers score and how TechInView's AI evaluates a round.
Practise being stuck
You cannot practise recovery on problems you can already solve. Pick problems a bit above your level, set a timer, and make yourself keep talking the whole time. Recording yourself is uncomfortable and works well. Silent practice never touches this failure mode, which is why pressure has to be trained. A voice mock interview is one way to get that pressure without a friend on call.
FAQ
How long should I struggle before asking for help?
Two to three minutes of visible, narrated effort. Beyond that you are spending time you need for implementation.
Does asking for a hint mean I failed?
No. Interviewers expect some back and forth. Long silence and refusing to change course are what sink candidates.
What if I do not finish?
A clearly explained approach with partial code still earns credit for communication and problem solving. Before time runs out, say what the remaining steps would be.
Summary: getting stuck in a coding interview is normal; going quiet is what costs you. Work out which kind of stuck you are, narrate, shrink the problem, name your blocker, and build on any hint you get.