Everyone gets stuck in coding interviews. Strong engineers get stuck. The difference is what they do in the thirty seconds after the panic hits.
Getting stuck isn't the thing that fails you. Going silent, freezing, or quietly spiraling for five minutes is what fails you. So here's a plan you can run when your brain goes blank and the cursor is just sitting there.
First, say it out loud
The worst move is silence. The interviewer can't read your mind, and a long quiet stretch reads as "lost" even when you're thinking hard.
Narrate where you are. Something like: "I have a brute force in mind, but I'm trying to see if there's a way to avoid the nested loop." That single sentence does three things. It tells the interviewer you're working, it slows your own pulse down, and it often shakes the next idea loose just by forcing you to put words to the problem.
You don't need to sound polished. You need to keep the line open.
Go back to a concrete example
When the abstract version of a problem locks you up, get specific. Pick a small input and walk it by hand.
If you're asked to find pairs that sum to a target, stop staring at the array variable and write out [2, 7, 4, 1] with target 9. Trace what you'd actually do as a human. You'd probably scan for the number that completes each one. That instinct is usually the algorithm, you just hadn't named it yet.
Concrete examples are also how you catch the case you were about to miss. Empty input, one element, duplicates, negatives. Working a real example surfaces those before they surface you.
Lower the bar on purpose
If you can't see the optimal solution, write the bad one.
Say it plainly: "Let me get a working brute force down first, then I'll look at improving it." A correct O(n^2) beats a broken O(n) every time, and a lot of interviews are happy with the naive version plus a clear explanation of how you'd make it faster.
Getting any working code on the screen also breaks the freeze. Now you have something to point at, test, and improve, instead of a blank editor that keeps getting scarier.
Use the structure of the problem
When you're truly out of ideas, the problem itself gives hints. A few questions that tend to unlock things:
- Is the input sorted, or would sorting help? Sorting often unlocks two pointers or binary search.
- Am I recomputing the same thing? That points at a hash map for lookups or memoization.
- Am I tracking a running window or a min/max so far? That's a sliding window or a single-pass scan.
- Does the problem mention "shortest," "fewest," or "levels"? That smells like BFS.
You don't have to memorize a giant table. Just have a short mental checklist you can run when stuck, so you're prospecting instead of staring.
Take the hint, gracefully
Interviewers usually want you to pass. When one offers a nudge, take it. Don't treat a hint as a failure you have to apologize for.
Repeat it back so they know it landed: "Right, so if I sort first, I can use two pointers and drop the nested loop." Engaging well with a hint is itself a signal. It shows you collaborate and adjust, which is most of what the day job is.
What hurts you is ignoring the hint and plowing down the dead end anyway.
Manage the clock out loud
If you've burned several minutes on one piece, name it and make a call. "I've spent a while on the optimal approach. I'm going to lock in the brute force so we have something working, then come back if there's time."
That's not giving up. That's the judgment they're actually testing. Shipping a correct solution and being honest about its limits beats chasing perfect and running out of time with nothing on the screen.
How to make this automatic
This recovery plan only works if you don't have to think about it under pressure. Which means practicing it before the real thing, not improvising it on the day.
When you drill problems, practice the recovery, not just the answer. Say your reasoning out loud even when you're alone. Force yourself to write the brute force first sometimes. Do timed mock interviews so the clock stops feeling like an ambush. The goal isn't to never get stuck. It's to make getting unstuck a routine you've already run a hundred times.
Get stuck on purpose in practice, and you'll stay calm when it happens for real.