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

If you're stuck in a coding interview, don't freeze and don't stay quiet. Work through a fixed sequence out loud: restate the problem, solve a small example by hand, state a brute force, find its bottleneck, simplify, and only then ask for a targeted hint. Most interviewers score how you recover from a stall, not just whether you stall, so a visible process can still earn a hire.

This guide gives you a 7-step "stuck recovery ladder" with time thresholds for a typical 45-minute round, exact scripts for asking for hints, and a plan for getting partial credit when the clock runs out.

Key Takeaways

• Getting stuck is expected. Many interview problems include a twist or follow-up, and the interviewer is watching what you do next.
• Silence costs you more than wrong ideas. Narrate every step, even "I'm checking whether sorting helps."
• Climb the ladder in order: restate, example, brute force, bottleneck, pattern check, simplify, then hint. Each rung has a time limit.
• Ask for a hint at around the 8 to 10 minute mark of real stuckness, and make it narrow: ask about one sub-step, not the whole solution.
• If you pass the halfway point with no optimal path, code the brute force. Working, tested code beats a perfect idea you never wrote.
• Practice recovery as a skill, with timed drills and mock interviewers who give deliberately small hints.

Why Is Getting Stuck in a Coding Interview Normal?

Getting stuck is a normal part of coding interviews. Interviewers often pick problems with a twist, a hidden optimization, or a follow-up, so they can see how you reason when the obvious approach stops working. If you solved everything instantly, they would learn little about you.

Many structured interview rubrics score several things separately: problem solving, coding quality, communication, and testing or verification. Our breakdown of what interviewers look for in coding interviews covers these in detail. Being stuck only touches one of them directly. The way you handle it touches all four.

That is why candidates who "didn't finish" sometimes get offers and candidates who "basically solved it" sometimes don't. If you want examples of how that plays out, see whether you can fail a coding interview and still get hired.

Blanking vs. being stuck

These are two different problems with different fixes:

• Blanking is a stress response. Your working memory shuts down, and you can't think even about things you know. The fix is physical and concrete: slow your breathing, read the prompt aloud, type an example.
• Being stuck is a reasoning problem. You understand the question but can't see the approach. The fix is a process, which is what the ladder below gives you.

If blanking is your main issue, our guide to technical interview anxiety goes deeper on the stress side.

The Stuck Recovery Ladder: 7 Moves With Time Thresholds

The stuck recovery ladder is a sequence of seven escalating moves, each with a rough time budget. You move up a rung when the current one stops producing progress. The timings below assume a 45-minute round with about 35 minutes for the coding problem. Scale them down for shorter screens.

After rung 7, if you still have no path and you are past the halfway point of the round, switch to the salvage plan covered later. Don't stay on the ladder forever.

Rung 1: Restate the problem and the constraints

Many "stuck" moments are actually misreadings. Restate the problem in your own words and confirm input size, value ranges, duplicates, and what to return for empty input. Constraints are clues: an input size near 10^5 usually means you need O(n log n) or better, while a size near 20 often allows exponential search.

Rung 2: Solve a small example by hand

Write a 4 to 6 element input and solve it manually, narrating as you go. Watch what your own brain does. If you found the answer by scanning once while remembering something, that "something" is often the data structure you need.

Rung 3: State the brute force

Say the simplest correct approach and its time and space complexity, even if it's obviously too slow. This does three things: it proves you understand the problem, it gives you a fallback to code later, and it gives you something to optimize. If you need a refresher on cost analysis, keep the Big O notation cheat sheet handy during prep.

Rung 4: Name the bottleneck

Look at the brute force and ask, "What work am I repeating?" Most optimizations remove repeated scanning, repeated sorting, or repeated recomputation of the same sub-result. Saying the bottleneck out loud often triggers the fix.

Rung 5: Run a pattern checklist

Go through common tools quickly and out loud: hash map, sorting, two pointers, sliding window, prefix sums, binary search, heap, stack, BFS or DFS, dynamic programming. Our coding interview patterns cheat sheet maps problem signals to these patterns, which makes this step much faster under pressure.

Rung 6: Simplify the problem

Solve an easier version first. Drop a dimension (1D instead of 2D), assume sorted input, assume no duplicates, or solve for k = 1 before general k. Then ask what breaks when you put the constraint back.

Rung 7: Ask for a targeted hint

By this point you've shown 8 to 10 minutes of structured effort, so a hint looks like collaboration, not surrender. The next section covers how to ask.

How Do You Ask for a Coding Interview Hint Without Losing Points?

Ask for a hint about one specific sub-step and show your current thinking first. A good hint request summarizes what you have, names where you're blocked, and proposes a direction for the interviewer to confirm or redirect. That makes the hint small, and small hints cost little.

Here are scripts you can adapt:

• Confirm a direction: "I have an O(n^2) solution. I think the repeated work is recomputing the range sum. Is a precomputed structure the right direction, or should I be thinking differently?"
• Choose between options: "I'm deciding between sorting first and using a hash map. Sorting loses the original indices, which I need. Does that rule it out?"
• Check a constraint: "Can I assume the input fits in memory? If so, I'd store everything in a map first."
• Ask for the smallest nudge: "I'm stuck on how to handle negative numbers here. Could you give me a small nudge on that part only?"

Avoid these:

• "Can you just tell me the approach?"
• "I don't know," followed by silence.
• Asking for a hint in the first two minutes before trying anything.
• Asking the same question again after getting an answer.

How to use a hint once you get it

How you use a hint matters more than whether you needed it. Repeat the hint in your own words, connect it to your bottleneck, and act on it within a minute or two. "Right, so if I store prefix sums in a map, I can check for the complement in O(1), which removes the inner loop." Then start coding.

If the hint doesn't land, say so honestly and ask one clarifying question about it. Nodding and then going silent is the worst outcome.

Worked Example: Climbing the Ladder on a Real Problem

Take a common medium problem: given an integer array and a target k, count the contiguous subarrays whose sum equals k. Values can be negative.

Rung 1: "So I return a count, not the subarrays. Values can be negative, and n could be up to around 2 times 10^4." That constraint already hints that O(n^2) may be borderline.

Rung 2: For [1, 2, 3] and k = 3, the answers are [1, 2] and [3], so the count is 2.

Rung 3: The brute force checks every start and end:

def subarray_sum_brute(nums, k):
    count = 0
    for i in range(len(nums)):
        total = 0
        for j in range(i, len(nums)):
            total += nums[j]
            if total == k:
                count += 1
    return count

"This is O(n^2) time and O(1) space."

Rung 4: "The repeated work is that, for every end index, I'm re-checking every possible start."

Rung 5: "Sliding window won't work because negatives mean the sum doesn't grow monotonically. Prefix sums might, since sum(i..j) is prefix[j] minus prefix[i-1]."

Rung 6: "If I know the prefix sum at j, I need to know how many earlier prefixes equal prefix[j] minus k. That's a lookup."

If you got here, you don't need rung 7. If you didn't, a good hint request would be: "I think prefix sums are involved, but I don't see how to avoid checking all earlier prefixes. Should I store them somehow?"

from collections import defaultdict

def subarray_sum(nums, k):
    seen = defaultdict(int)
    seen[0] = 1
    prefix = 0
    count = 0
    for x in nums:
        prefix += x
        count += seen[prefix - k]
        seen[prefix] += 1
    return count

"O(n) time and O(n) space. The seen[0] = 1 handles subarrays that start at index 0."

Notice that the brute force wasn't wasted. It defined the bottleneck, and the bottleneck pointed to the fix.

How Do You Salvage Partial Credit When You Can't Solve It?

If you're past the halfway point with no viable path to the optimal solution, switch from searching to shipping. Partial credit comes from evidence, and evidence means working code, tests, and clear analysis.

Use this salvage order:

1. Announce the switch. "Given the time, I'll code the O(n^2) version cleanly, then talk about how I'd optimize."
2. Code the brute force well. Good names, clear structure, no shortcuts. This is where your coding score comes from.
3. Test it. Walk through your small example and at least one edge case (empty input, single element, duplicates, negatives). Our debugging interview guide has a quick tracing method.
4. State the complexity and the bottleneck. Show you know exactly why it's slow.
5. Sketch the optimization in words. Even an incomplete idea, like "I think a monotonic stack could give each element's next greater value in one pass," shows direction.

What scores higher?

These are general patterns, not a guarantee. The bar changes by level and company, and senior roles usually expect you to reach the optimal approach with less help.

What Do Interviewers Write When You're Stuck?

Interviewers typically write down factual observations during or right after the round, then turn them into a score. When you get stuck, they note when it happened, what you tried, whether and how you asked for help, and what you did with it.

Here are illustrative examples of the kind of notes that help and hurt. They are not quotes from any real feedback packet, but they reflect the factual, observation-based style many interviewers aim for.

Notes that still support a hire:

• "Started with a brute force and stated O(n^2). Identified repeated work without prompting."
• "Got stuck on handling negatives. Asked a specific question about it. Used the hint immediately and finished."
• "Did not reach optimal, but brute force was clean and well tested. Described the right direction for the optimization."

Notes that hurt:

• "Long silent periods. Unclear what the candidate was thinking."
• "Started coding before understanding the problem; had to restart twice."
• "Received a hint on using a hash map but did not apply it."
• "Asked for the approach before attempting anything."

The difference between the two lists is visibility and momentum, not raw talent. That's why practicing how to think out loud in a coding interview pays off so much when you get stuck.

Practice Drills to Get Better at Being Stuck

You can train recovery directly. Normal problem grinding trains solving; these drills train the moments when solving fails.

Run at least a few mock interviews with a real person, because a live listener changes how you think. Our list of the best mock interview platforms compares paid and free options.

If you keep getting stuck on the same kinds of problems, the issue is probably a pattern gap, not a recovery gap. Work those patterns until you recognize them on sight, and keep an eye on why qualified candidates still fail technical interviews so you don't repeat the common mistakes.

Quick Reference: Your Stuck Checklist

Keep this list in mind during the round:

1. Restate the problem and confirm constraints.
2. Solve a tiny example by hand.
3. Say the brute force and its complexity.
4. Name the repeated work.
5. Check hash map, sort, two pointers, window, prefix sums, binary search, heap, stack, graph search, DP.
6. Solve an easier version.
7. Ask one narrow hint after about 8 to 10 minutes of real effort.
8. Past halfway with no path? Code the brute force, test it, explain the optimization.

Being stuck isn't the failure. Being stuck and invisible is.