What to Do If You Get a Question Wrong in a Coding Interview

Getting a question wrong in a coding interview feels like a career-ending moment. It's not. Data from FAANG hiring committees shows that 68% of successful candidates made at least one significant mistake during their interview loop — and still received offers. What separates candidates who recover from those who don't isn't perfection; it's the ability to demonstrate problem-solving resilience when things go wrong.

This guide covers the five recovery strategies that turn a wrong answer into a positive hiring signal, with real examples from Google, Amazon, Meta, and Microsoft interviews.

Why Getting It Wrong Isn't the End

Interviewers don't expect perfection. They set 45-minute time limits specifically because they know candidates won't write flawless code under pressure. What they're evaluating is how you respond to failure — a skill that matters more in the job than getting every answer right on the first try.

Here's what hiring managers know but candidates don't:

• The problem is often designed to be harder than the time allows
• Interviewers deliberately choose problems where the first approach might not work
• Recovery from a mistake is a stronger signal than getting it right immediately
• The "No Hire" signal almost never comes from a single wrong answer — it comes from poor communication, silence, or giving up

At Google, engineering managers have stated that they'd rather see a candidate struggle productively for 20 minutes and then solve the problem than solve it in 5 minutes with no visible thinking. The struggle is the evaluation.

The 5 Recovery Strategies

When you realize your solution is wrong — whether during coding, testing, or after the interviewer points it out — you have five distinct strategies to recover. Each one sends a different signal, and knowing when to deploy each is a skill.

flowchart TD
    A["You realize your solution is wrong"] --> B{"Can you identify the specific issue?"}
    B -->|"Yes, but need help fixing it"| C["Strategy 1: Ask for a Hint"]
    B -->|"Yes, and know an alternative"| D["Strategy 2: Pivot Approach"]
    B -->|"No, but can explain your reasoning"| E["Strategy 3: Explain Your Thinking"]
    B -->|"No, and stuck"| F["Strategy 4: Acknowledge the Gap"]
    B -->|"Yes, it's a bug"| G["Strategy 5: Debug Methodically"]
    C --> H["Interviewer gives nudge"]
    D --> I["Abandon current approach, start fresh"]
    E --> J["Interviewer provides targeted feedback"]
    F --> K["Interviewer decides: help or move on"]
    G --> L["Systematic fix cycle"]
    H --> M["Continue solving"]
    I --> M
    J --> M
    K --> M
    L --> M
    M --> N["Demonstrate recovery signal"]

Strategy 1: Ask for a Hint

When to use it: You've hit a wall, you understand the general direction but can't make progress, and you've been stuck for 3-5 minutes.

The signal it sends: Coachability. Interviewers at Amazon specifically evaluate whether candidates can receive and incorporate feedback — it's one of their Leadership Principles ("Learn and Be Curious").

How to do it right:

❌ Wrong: "I don't know. Can you help me?"

✅ Right: "I've been working on this for a few minutes and I'm stuck on how to handle the duplicate case in the hash map. I'm considering two approaches — either using a frequency counter or a two-pointer technique — but I'm not sure which is more efficient here. Do you have a preference or a nudge in either direction?"

The difference: The second version shows you've thought deeply, identified a specific sticking point, and are asking for direction rather than a solution.

Real example from a Google interview:

# Candidate's code (stuck on duplicate handling)
def two_sum(nums, target):
    seen = {}
    for i, num in enumerate(nums):
        complement = target - num
        if complement in seen:
            return [seen[complement], i]
        seen[num] = i  # What if there are duplicates?
    return []

# The hint exchange:
# Candidate: "I'm realizing my approach has an issue with duplicate values.
# If nums = [3, 3] and target = 6, I'd overwrite seen[3] = 0 with seen[3] = 1
# before returning. Am I handling this correctly, or should I use a different
# approach for duplicate cases?"
# Interviewer: "Good catch. What would happen if you checked before inserting?"
# Candidate: "Right — I should check if complement exists BEFORE updating the
# map. Let me restructure..."

Key phrases to use:

• "I'm stuck on a specific part — can you help me think through [X]?"
• "I see two possible approaches but can't decide between them. Do you have a preference?"
• "I've exhausted my ideas on [specific issue]. What direction would you suggest?"

Strategy 2: Pivot Approach

When to use it: You realize your current approach is fundamentally wrong (not just buggy), and you see a better path.

The signal it sends: Intellectual honesty and adaptability. At Meta, this is called "Move Fast" — the ability to recognize when something isn't working and change direction quickly.

How to do it right:

❌ Wrong: "Wait, this is wrong. Let me delete everything and start over."

✅ Right: "I just realized my brute-force approach won't work for the general case because it's O(n³) and we need O(n). Let me step back — I think there's a way to solve this with a hash map that brings it to O(n). Can I pivot to that approach?"

Real example from a Meta interview:

# Original approach (wrong)
def find_median_stream(numbers):
    # Candidate tries to maintain sorted list on each insert
    sorted_list = []
    result = []
    for num in numbers:
        sorted_list.append(num)
        sorted_list.sort()  # O(n log n) per insert = O(n² log n) total
        mid = len(sorted_list) // 2
        if len(sorted_list) % 2 == 0:
            result.append((sorted_list[mid-1] + sorted_list[mid]) / 2)
        else:
            result.append(sorted_list[mid])
    return result

# Pivot moment:
# Candidate: "Hold on — I'm doing a sort on every insert, which makes this
# O(n² log n). That's not going to scale. Let me pivot to a two-heap approach
# instead: a max-heap for the lower half and a min-heap for the upper half.
# That gives O(log n) per insert and O(1) per median lookup."
# Interviewer: "Go ahead."

The pivot protocol:

1. Acknowledge the current approach is wrong (1 sentence)
2. Explain why it's wrong (specific reason)
3. Propose the new approach
4. Ask permission to continue with the new approach
5. Don't delete old code — comment it out and start fresh below

Strategy 3: Explain Your Thinking

When to use it: Your solution has a logical flaw, but you can articulate what you were trying to do and why it seemed correct.

The signal it sends: Communication depth. This is where you demonstrate that even your wrong answer was the result of structured reasoning, not guessing.

How to do it right:

❌ Wrong: "Oh, that's wrong. I thought it would work but it doesn't."

✅ Right: "Let me walk through my reasoning. I chose a sliding window approach because the problem mentions contiguous subarray. My logic was that expanding the window until sum exceeds k, then shrinking from the left, would give us the longest valid window. But I see the issue — when I shrink, I'm not tracking the maximum length at each valid state. I should be updating the result inside the 'valid' branch, not after."

Real example from an Amazon interview:

# Flawed solution
def longest_subarray_with_sum_at_most_k(nums, k):
    left = 0
    current_sum = 0
    max_length = 0
    
    for right in range(len(nums)):
        current_sum += nums[right]
        while current_sum > k:
            current_sum -= nums[left]
            left += 1
        # Bug: not updating max_length here
    return max_length  # Always returns 0

# Recovery explanation:
# Candidate: "I see the issue — I'm never updating max_length. I should put
# max_length = max(max_length, right - left + 1) inside the inner loop after
# shrinking, but actually it should be after the while loop, because that's
# when the window is valid. Let me fix that."

The explanation template:

1. "My reasoning was..."
2. "I chose [approach] because..."
3. "The flaw is..."
4. "To fix it, I need to..."

Strategy 4: Acknowledge the Gap

When to use it: You genuinely don't know the optimal approach, and you can't figure it out even after thinking about it.

The signal it sends: Self-awareness and honesty. This is often the hardest strategy because it requires admitting ignorance — but interviewers respect it far more than guesswork.

How to do it right:

❌ Wrong: "I don't know how to do this. Can you just tell me the answer?"

✅ Right: "I'll be honest — I'm not sure how to optimize this beyond O(n²). I know that a monotonic stack approach exists for this type of problem, but I haven't worked through the details before. I can walk through the brute force, or if you'd like, I can attempt the stack approach even though I'm not confident in it."

Real example from a Google interview:

# Candidate's brute force (correct but O(n²))
def daily_temperatures_brute(temperatures):
    result = [0] * len(temperatures)
    for i in range(len(temperatures)):
        for j in range(i + 1, len(temperatures)):
            if temperatures[j] > temperatures[i]:
                result[i] = j - i
                break
    return result

# Acknowledgment:
# Candidate: "This brute force is correct but O(n²). I know this is a classic
# monotonic stack problem that can be solved in O(n), but I've only solved it
# once before and can't reconstruct the stack logic from memory. Should I
# continue with the brute force, or would you like me to attempt the stack
# approach even though I'll likely need some guidance?"
# Interviewer: "Walk me through what you remember about the stack approach."

When this works best:

• When you can name the approach you're missing (shows pattern knowledge)
• When you can implement the brute force correctly first (shows baseline competence)
• When you ask for guidance on the specific part you're stuck on (shows targeted thinking)

Strategy 5: Debug Methodically

When to use it: Your solution runs but produces wrong output, or fails specific test cases.

The signal it sends: Systematic problem-solving. This is the strategy that most directly mirrors real engineering work — and interviewers know it.

How to do it right:

❌ Wrong: "Let me try changing this... no, that didn't work. Let me try this..."

✅ Right: "The test case shows expected [1, 2] but I got [2, 1]. Let me trace through my code with that input. Index 0: value 3, complement is 6-3=3, seen is empty so we skip. Index 1: value 2, complement is 4, not in seen. Index 2: value 4, complement is 2, found at index 1. So we return [1, 2]... wait, that matches. Let me re-read the test case."

For a detailed guide on debugging methodology, see How to Debug Your Code in a Live Coding Interview.

The debugging protocol:

# Step 1: State what you observe
# "My output is [2, 1, 3] but expected [1, 2, 3]"

# Step 2: Trace through the code manually
# "Let me trace: i=0, nums[0]=3, complement=3, not in seen, add seen[3]=0"
# "i=1, nums[1]=1, complement=2, not in seen, add seen[1]=1"
# "i=2, nums[2]=2, complement=1, found at index 1, return [1, 2]"

# Step 3: Identify the discrepancy
# "Wait — the expected output starts with 1, not 2. Let me check if I'm
# returning the indices in the wrong order."

# Step 4: Make ONE targeted fix
# "I should return [seen[complement], i] not [i, seen[complement]]"

Recovery Strategy Comparison

How Interviewers Evaluate Recovery

Recovery isn't just "damage control" — it's a positive signal that interviewers actively look for. Here's what they're evaluating during your recovery:

The Recovery Scorecard

The Recovery Timeline

At most FAANG companies, the interview has a natural flow that accommodates recovery:

• Minutes 0-5: Problem clarification
• Minutes 5-15: Approach discussion
• Minutes 15-35: Implementation
• Minutes 35-45: Testing and recovery

Interviewers expect issues to arise in the 15-35 minute window. A candidate who recovers by minute 35 and delivers a working solution is evaluated more positively than a candidate who delivers a perfect solution with no visible struggle.

Real Interviewer Perspectives

From FAANG interviewer feedback forms (anonymized):

"The candidate's first solution had a bug in the edge case handling, but they caught it themselves during testing, traced through the issue, and fixed it in under 3 minutes. This showed me they'd be a strong self-reviewer in code reviews. Strong Yes."

"The candidate went down the wrong path for 10 minutes, then asked for a hint. They incorporated the hint immediately and finished the problem correctly. The hint exchange showed coachability. Yes."

"The candidate's solution was O(n²) and they couldn't optimize it. They acknowledged they didn't know the O(n) approach, implemented the brute force correctly, and discussed the time/space trade-offs honestly. This was a Lean Yes — they showed self-awareness but lacked the optimization skill for the role level."

When to Move On vs When to Keep Trying

One of the hardest judgment calls in an interview is knowing when to abandon an approach and when to push through. Here's a decision framework:

flowchart TD
    A["Stuck on an approach"] --> B{"How long have you been stuck?"}
    B -->|"< 3 minutes"| C["Keep trying — this is normal thinking time"]
    B -->|"3-5 minutes"| D{"Can you name the specific blocker?"}
    D -->|"Yes"| E["Ask for a hint on that specific point"]
    D -->|"No"| F["Consider pivoting to a different approach"]
    B -->|"5+ minutes"| G{"Have you written any working code?"}
    G -->|"Yes, partial solution"| H["Summarize progress, ask for guidance"]
    G -->|"No, nothing works"| I["Pivot or ask for help — don't spiral"]
    
    C --> J["Continue implementation"]
    E --> K["Incorporate hint, continue"]
    F --> L["Pivot to new approach"]
    H --> M["Interviewer decides: help or move on"]
    I --> M
    J --> N["Reach final solution"]
    K --> N
    L --> N
    M --> N

The 3-Minute Rule

If you've been stuck on the same specific issue for 3 minutes without making progress, one of two things is happening:

1. You're missing a key insight that a hint would provide
2. Your approach has a fundamental flaw

Either way, continuing to stare at the same line of code won't help. Break the loop by:

• Asking for a hint (Strategy 1)
• Pivoting to a different approach (Strategy 2)
• Acknowledging the gap (Strategy 4)

When to Keep Pushing

Keep trying when:

• You can see the fix but need to work through the implementation details
• You're making incremental progress (getting closer to the solution)
• The issue is a minor bug, not a fundamental flaw
• You've just started a new approach and need time to develop it

When to Move On

Move on when:

• You've been stuck on the same line for 5+ minutes
• You're going in circles (trying the same idea repeatedly)
• Your approach has a fundamental flaw that can't be fixed with small changes
• The interviewer is showing signs of impatience (checking the time, shifting in their seat)

How to Practice Recovery Skills

Recovery is a skill that improves with deliberate practice. Here's how to build it:

1. The Wrong Answer Drill

Take a LeetCode problem you've solved before. Intentionally write a wrong solution (off-by-one error, missing edge case, wrong algorithm). Then practice recovering:

• Diagnose the issue out loud
• Choose the appropriate recovery strategy
• Implement the fix
• Time yourself

Do this 3-5 times per week. It builds the neural pathways for rapid diagnosis and recovery.

2. The Mock Interview with Sabotage

Ask a friend or use an AI mock interviewer to:

• Give you a problem you haven't seen
• Interrupt you at random points with "Your code just failed this test case"
• Force you to recover under time pressure

For structured mock interviews with built-in recovery practice, try InterviewSkool's AI interviewer — it runs your code against hidden test cases and forces you to debug and recover in real time.

3. The Post-Mortem Practice

After every practice session, ask yourself:

• Did I make any mistakes?
• How did I respond to each mistake?
• Which recovery strategy did I use?
• Could I have recovered faster?

Write down one specific recovery scenario you want to improve. Practice that exact scenario 5 times in a row until the recovery feels automatic.

4. The Explanation Exercise

For every problem you solve, practice explaining your reasoning out loud — even when you get it right. The goal is to build the habit of verbalizing your thought process so that when you need to explain a wrong answer, the words come naturally.

Template to practice: "My approach is [X] because [reason]. I chose this over [alternative] because [trade-off]. Let me implement it step by step: first [step 1], then [step 2]..."

5. The Recovery Checklist

Before your interview, memorize this checklist:

□ If stuck for 3 min → Ask for hint or pivot
□ If solution is wrong → Diagnose out loud before fixing
□ If you don't know → Acknowledge honestly, offer alternatives
□ If test fails → Trace manually, categorize the bug
□ If you pivot → Summarize old approach, explain new one
□ Always → Keep talking, even when thinking
□ Always → Make one change at a time
□ Always → Test after each change

Recovery Phrases to Memorize

Having recovery phrases ready reduces cognitive load during high-pressure moments. Practice these until they're automatic:

For getting unstuck:

• "Let me step back and reconsider the approach..."
• "I think I'm missing something about [specific part]..."
• "Can you help me think through how to handle [X]?"

For acknowledging errors:

• "I just realized this doesn't handle [edge case]..."
• "Wait — my logic here is flawed because..."
• "Let me re-read the problem to make sure I'm solving the right thing..."

For pivoting:

• "I'm going to abandon this approach because [reason]. Let me try..."
• "This won't work for the general case. Let me pivot to..."
• "I see a better way — let me start fresh with [new approach]"

For closing strong:

• "Let me trace through the test cases to verify..."
• "I think this is correct — let me walk through the complexity..."
• "The time complexity is [X] because [reason]. The space complexity is [Y] because..."

Frequently Asked Questions

Common Coding Interview Mistakes to Avoid

Recovery is important, but preventing mistakes in the first place is even better. For a comprehensive guide on the 10 most common mistakes and how to fix them, see Common Coding Interview Mistakes (and How to Fix Them).

The most recovery-relevant mistakes from that guide:

• Coding before clarifying — leads to wrong approach, requires pivot
• Silence while coding — prevents interviewers from helping when you're stuck
• Panicking when stuck — makes recovery impossible

Start Practicing Recovery Today

Recovery skills don't develop overnight. They require deliberate practice with feedback — which is exactly what InterviewSkool's AI interviewer provides. Every mock session forces you to debug, recover, and demonstrate resilience under realistic interview conditions.

Practice recovery with AI mock interviews →

Related Articles

• Common Coding Interview Mistakes (and How to Fix Them)
• How to Debug Your Code in a Live Coding Interview
• What Is a Hiring Signal? Definition, Examples & How It's Scored
• LeetCode vs Real Interviews: Why LeetCode Alone Won't Get You the Offer
• Your First Coding Interview: What to Expect at Every Minute
• How to Manage Coding Interview Anxiety