What to Do When You Get Stuck in a Coding Interview
Sarah Jenkins
Engineering Manager
Getting stuck in a coding interview is not a failure state. It is the expected state, and most questions are chosen precisely because a good candidate will not see the answer immediately. What decides the outcome is the next ninety seconds, and almost nobody has a plan for them.
The only genuinely fatal move
Going quiet. Assessment stops when speech stops, because there is nothing to assess. Thirty seconds of silence feels like five seconds to you and like a minute to the interviewer, and the note that gets written afterwards is "got stuck and shut down", which is a judgement about temperament rather than about the algorithm.
The instinct to go silent is completely natural. Thinking hard is quiet work. But a technical interview measures your thinking through your speech, so silent thinking is, from the far side of the table, indistinguishable from panic.
The unsticking ladder
Work down this list in order. Each rung is something to say, not something to think, and each one buys you time while producing signal rather than consuming it.
| Rung | What you say | Why it helps |
|---|---|---|
| 1. Name the state | "Let me think about this out loud for a second." | Buys thirty seconds legitimately |
| 2. Restate | "So I need X given Y, and Z is the constraint." | Surfaces misreadings, which cause much of being stuck |
| 3. Brute force | "The obvious O(n²) way is this. Let me start there." | A slow answer beats no answer, and often reveals the fast one |
| 4. Small case | "Let me do it by hand for n = 4." | Patterns appear in examples that do not appear in the abstract |
| 5. Name the blocker | "I need to find duplicates in constant space and I do not see how." | Invites a hint without asking for one |
Rung five is the underused one. Precisely naming what you cannot do is a demonstration of understanding, and interviewers reliably respond with a nudge because you have shown them exactly where you are. "I'm stuck" gets you nothing; "I'm stuck on this specific sub-problem" usually gets you the hint and the credit for having isolated it.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
- Brian Kernighan, The Elements of Programming Style (1978)
The same asymmetry appears under interview pressure. The clever solution you half-remember is the one you cannot debug on a whiteboard with someone watching. Writing the plain version and improving it is not a concession; it is the strategy with the better expected outcome.
Why the brute force is not a loss
Candidates resist writing the obvious slow solution because it feels like admitting defeat. In the scoring it is close to the opposite. A working slow solution gives you a correct answer on the board, a complexity to improve against, and a concrete artefact to reason about. Many optimisations are only visible once the slow version is written down.
🔑 Say it as a plan, not an apology
"I'll write the O(n²) version first so we have something correct, then look at whether the sorted structure lets me drop a factor" is a strategy. "I can only think of the slow way, sorry" is the same code with a worse note attached to it.
How to take a hint well
Taking a hint costs far less than candidates assume, but taking it badly costs a lot. Two failures: ignoring it and continuing down your own path, and accepting it without understanding it and then coding something you cannot explain.
The right response is to absorb it out loud. "So you are suggesting the array being sorted means I can move two pointers inward instead of scanning. Then the inner loop disappears and it is linear." That shows the hint landed and that you can carry it, which recovers most of the ground you lost by needing it.
This is trainable, and only one way
You cannot practise being stuck on problems you can solve. You need problems slightly above your level, attempted out loud, with the clock running and something interrupting you. That combination is uncomfortable, which is why it is rare, and it is exactly why it is the thing that moves your interview results.
Do it enough times and being stuck stops feeling like an emergency. It starts feeling like the part of the interview you have a procedure for, because you do.
More Articles
The Hidden Framework Behind Meta's Technical Interview Process
April 12, 2026 · 15 min read
Why You Keep Failing Technical Interviews (And It's Not Your Coding Skills)
January 10, 2026 · 10 min read
The Complete Guide to Technical Interview Follow-ups
August 5, 2025 · 7 min read