What to Do When You're Stuck in a Coding Interview

Getting stuck is not the failure. Freezing silently is. When your mind goes blank, say what you are stuck on out loud, re-walk one tiny input by hand, and if nothing clicks in a minute, write the brute force and optimize from there. Interviewers are not scoring whether you were stuck; they are scoring how you move when you are. We run mock interviews all day, and the candidates who recover well do the same handful of things every time. Here is the playbook.

First, name the block out loud

The worst move is to go quiet and stare at the editor while a timer runs. Across FAANG-style rubrics, coding rounds usually run 30 to 45 minutes, and interviewers grade four things: communication, problem solving, technical competency, and testing. Silence torpedoes the first two and gives the interviewer nothing to grade.

So narrate the stuck state precisely. Not "I'm confused," but "I know a hash set tracks seen characters, but I'm not sure how to shrink the window when I hit a duplicate." That sentence does three things: it keeps your problem solving visible, it tells the interviewer exactly where to nudge you, and it often unsticks you because you just stated the subproblem cleanly.

A good template:

"What I have so far is X."
"The part I'm stuck on is Y."
"The approaches I'm weighing are A and B, and here's the tradeoff."

This is different from rambling. If you want the line between the two, we wrote a separate guide on thinking out loud without rambling. The short version: narrate decisions, not keystrokes.

Re-walk a tiny example by hand

When you are stuck on logic, stop writing code and work one small input on paper or in a comment. Pick something minimal: a 3-character string, a 2x2 matrix, an array of 4 numbers. Trace the exact state transitions a correct answer would need.

Take "Rotate Image," a frequent ask at AT&T. If you cannot remember the in-place trick, draw a 2x2 matrix and physically move each cell to where it belongs after a 90-degree clockwise turn. You will notice that the first row becomes the last column. That observation is the whole solution: transpose the matrix, then reverse each row. You did not recall a formula; you rediscovered it from one example. This works because most matrix problems are index bookkeeping, and the indices become obvious once you see them move. (If this pattern is shaky, drill it on matrix questions.)

The same move rescues "Longest Substring Without Repeating Characters." Trace abcabcbb character by character and watch what has to happen when the second a arrives: your window has to shrink from the left until the duplicate is gone. Walking the example surfaces the sliding-window mechanic even if the phrase "sliding window" never came to mind.

Fall back to brute force, then optimize

If a minute of exploring does not produce the clever approach, commit to the obvious one. State it plainly: "The brute force here is O(n squared), and I'll code that first to get something correct, then look for a better bound." This is a strength signal, not a weakness. A working slow solution plus a clear optimization path beats a half-written optimal solution that does not run.

"Number of Divisible Triplet Sums," another AT&T question, is a clean example. The brute force is three nested loops checking every (i, j, k) triplet, which is O(n cubed). Write it. Then look at the structure: you are checking (nums[i] + nums[j] + nums[k]) % d == 0. The unlock is to think in terms of remainders modulo d. Fix one index, and count how many earlier pairs leave the complementary remainder, using a hash map of remainder counts. You went from O(n cubed) to O(n squared) by starting from the brute force and asking "what work am I repeating?"

That question, "what am I recomputing?", is the single most reliable optimization trigger. Repeated recomputation points to a hash map, a prefix sum, or memoization almost every time.

Run through the pattern checklist

Being stuck often means you have not matched the problem to a known pattern yet. Keep a short mental checklist and test the problem against each. We teach candidates to literally walk down this list out loud:

Signal in the problem	Pattern to try
Contiguous subarray or substring, "longest/shortest"	Sliding window / two pointers
Matching, nesting, "valid" ordering	Stack
"Count pairs/triplets summing to"	Hash map of complements, remainders
Sorted input, "find target / boundary"	Binary search
Grid, levels, shortest path	BFS / DFS

"Valid Parentheses" is the textbook case: the moment you see nested, matched brackets that must close in the right order, the stack pattern should fire. Push opens, pop on a matching close, and the string is valid only if the stack ends empty. If you had been stuck, running the checklist would have caught it at the word "closed by the same type." Build this reflex by practicing grouped by pattern on our practice sets rather than solving problems at random.

Take hints without tanking your score

Interviewers drop hints when they see you stalling, often phrased as questions like "have you considered a different data structure?" Treat that as a gift, not a penalty. How you use a hint matters more than needing one.

Do this:

Acknowledge it. Repeat the hint in your own words so you are sure you understood it.
Do not instantly abandon your current approach. Check whether the hint slots into what you already have.
Think out loud as you apply it, so the interviewer sees you integrating the idea rather than guessing.

Needing one or two nudges on a hard problem rarely sinks a candidate. Needing to be dragged through every step does. There is a real difference between "I was stuck, got a pointer, and ran with it" and "I could not move without being told what to type." Aim to be the first.

If debugging is where you stall rather than ideation, that is a separate skill with its own tactics, and our debug-under-pressure guide covers isolating the failing case fast.

What getting stuck actually costs you

Here is the editorial take from watching thousands of mock rounds: candidates massively overestimate the damage of getting stuck and underestimate the damage of poor communication while stuck. The rubric rewards a candidate who narrates a clear recovery, writes a correct brute force, and articulates the path to better complexity, even if they never finish the optimal version. It punishes long silences, flailing edits, and defensiveness, even when the final code is close.

So manage the clock honestly. If you have spent several minutes stuck, say so and make a decision out loud: "I'll lock in the O(n squared) solution so we have something correct, then spend remaining time on the optimization." That sentence is a hire signal. It shows judgment, which is exactly what senior interviewers are grading.

FAQ

How long should I struggle before asking for a hint?

Give yourself roughly two to three minutes of visible, out-loud effort on a sticking point before you ask. Frame the ask specifically: "I'm deciding between recursion and an iterative stack here, do you have a preference on direction?" A targeted question reads as problem solving; a vague "I'm stuck, help" does not.

Does asking for a hint mean I failed the interview?

No. Rubrics score how you incorporate feedback, and taking one or two hints on a genuinely hard problem is normal. The failure mode is needing step-by-step hand-holding or ignoring a hint the interviewer clearly offered. Acknowledge it, apply it visibly, and keep driving.

Should I write brute force even if I think I can see the optimal solution?

If the optimal is clear and you can code it confidently, go straight to it but state the brute force baseline and its complexity first. If the optimal is fuzzy, write brute force. A correct slow solution is worth far more than a broken clever one, and it gives you a safe fallback if time runs short.

What if I go completely blank and cannot think of any approach?

Drop to the smallest possible input and solve it by hand, then a slightly larger one, and look for the rule you are applying. Manual tracing almost always surfaces a pattern. Narrate the whole process so the interviewer sees structured thinking even before you have an algorithm.

Is it okay to tell the interviewer I'm stuck?

Yes, as long as you pair it with specifics and a next step. "I'm stuck on the window-shrinking logic, let me trace a small example" is strong. "I'm stuck" followed by silence is not. Honesty plus a concrete move forward is exactly the behavior the rubric rewards.