How to Recover from a Wrong Solution Mid-Interview

How do you recover from a wrong solution mid-interview?

Three moves: stop typing, name the bug out loud, and propose the fix in one sentence before re-coding. Don't apologize, don't restart silently, and don't pretend it's still working. Self-correction, catching and fixing your own mistake on the record, is one of the highest-graded signals on coding-interview rubrics, sometimes higher than a clean first-try solution. Recovery is the rubric.

As of the 2026 hiring cycle, interviewers at companies running structured loops are explicitly told to grade debugging behavior, because the day-job is mostly fixing code that doesn't work yet, not writing it perfectly the first time. I've watched strong new grads talk themselves out of an offer by quietly deleting a wrong solution instead of narrating the fix. A wrong turn handled well is a free point, not a death sentence. The goal is to walk out able to say "I caught it, I named it, I fixed it" in your own voice, whether the round was a phone screen on a shared pad or a full onsite.

The 30-second recovery script

When you realize your solution is wrong (or the interviewer points it out), run this exact sequence:

Second 1-5, stop and acknowledge. "Wait. Let me look at this." Say it out loud. Stop typing. You can't think and type at the same time, and the interviewer needs to see you switch modes from production to debugging.

Second 5-15, name the bug. "The issue is that when there are duplicates, the hash map overwrites the earlier index, so I lose the first occurrence." Specific. Falsifiable. The interviewer can now grade your diagnosis.

Second 15-25, propose the fix. "I think if I switch the value from a single index to a list of indices, that handles it without changing the time complexity." Now you've shown the recovery has a destination, not just a problem.

Second 25-30, verify direction before re-coding. "Does that approach make sense, or are you seeing a simpler fix?" One short check. Then code.

The whole thing takes thirty seconds and reads as engineering. Compare that to silently deleting code, re-typing, and hoping the interviewer didn't notice, which is what most new grads do and is almost always graded down.

The five-step recovery method (the numbered version)

If you want one sequence to drill until it runs on autopilot, this is it. The same five beats work whether you caught the bug or the interviewer did:

1. Stop typing and acknowledge. "Wait, let me look at this." Switch visibly from writing code to reading it. A dry run, stepping the program by hand against an input instead of running it, is how you read it.
2. Name the bug specifically. Tie it to an input: "On [1,1,2] this returns 1 instead of 0 because duplicates overwrite the index." Specific and falsifiable beats "something's off."
3. Propose the fix in one sentence. "Switching the map value to a list of indices handles duplicates without changing the time complexity." One sentence proves you can target the bug, not just spot it.
4. Choose fix-in-place or scrap, and announce a scrap. A one-line repair is a fix; a wrong data structure is a scrap. If you scrap, say so and give a time estimate.
5. Re-code and re-trace the failing input. Run the exact case that broke it back through the fix, out loud, then hand the lead back: "Anything else you'd want me to check?"

Knowing which input to reach for in step 2 is its own skill, and it starts before you write a line. The guide on how to handle clarifying questions on a coding problem covers how to surface the constraints that tell you where your code is exposed. The verification motion in step 5 is drilled in full in the guide on how to test your code in an interview.

Fix in place vs scrap and restart: what the interviewer sees

The recovery that tanks a round is almost never the bug itself. It's choosing the wrong recovery and doing it silently. Here's how the two paths read across the moments that actually come up. Fixing in place means a one- or two-line repair you can name in a sentence; scrapping means your structure or approach can't represent the problem and you restart on purpose.

| The situation | Silent / wrong recovery | Narrated, deliberate recovery | |---|---|---| | Off-by-one or wrong operator | Delete and re-type quietly; reads as careless | Name it, change one line, re-trace the case; reads as debugging | | Hash map loses a duplicate index | Keep patching around it | One-sentence fix: switch the value to a list of indices | | Data structure can't represent the input | Force it and stall | Announce a scrap with a time estimate, then restart cleanly | | Interviewer catches the bug first | Get defensive: "are you sure mine works?" | "Good catch, let me trace it," then actually trace it | | You've restarted once already | Restart again silently (now a yellow flag) | Step back to clarifying the problem before more code | | Time is running short | Abandon the broken code, freeze up | Narrate a partial fix; partial credit beats silence |

Why apologizing hurts more than the bug

The instinct is to say "sorry, I should have seen that." Don't. It signals you think the bug is shameful (which makes the interviewer wonder how you'd act on a real team where bugs are constant), it eats time you should spend fixing, and it shifts the frame from "engineer at work" to "candidate being judged." Per the Pragmatic Engineer's writing on interview feedback patterns, candidates who say "good catch, let me fix it" significantly outperform candidates who say "I'm so sorry, I can't believe I missed that," even when the underlying mistake and fix are identical.

When to fix vs when to scrap

Some bugs are local: a missing edge case, an off-by-one, a wrong comparison operator. An off-by-one error is iterating one element too far or one too few (range(len(arr)) versus range(len(arr) - 1)), and it's the single most common live-interview bug in Python and Java alike. Fix in place. State the fix, change two lines, move on.

Other bugs are architectural: your data structure can't represent what the problem needs, or your loop direction is wrong. That's a scrap, a deliberate restart because no local edit can save the approach. The skill of spotting which inputs expose these is the same one you use when you handle a coding problem you have never seen. You reason from the constraints to the structure.

The test: can you describe the fix in one sentence without restating the algorithm? If yes, fix in place. If you find yourself saying "well, if I changed the data structure, then I'd also need to change..." you're really doing a scrap. Announce it:

"My current approach can't handle case X without significant restructuring. I think a [different structure] handles it cleanly. Let me restart with that, should take about five minutes."

One scrap and restart is normal. Per Indeed Career Guide research on technical interview signals, the candidates who recovered from a complete restart inside a 45-minute coding round received "hire" or "strong hire" recommendations at a rate not statistically different from candidates whose first solution worked.

How to handle the interviewer catching your bug

If they catch it before you do, the playbook is:

1. Acknowledge briefly: "You're right, let me check." No "oh no" or "ugh."
2. Trace through it on the spot: "If the input is [1,1,2], my code returns 1 instead of 0. So yes, duplicates break it."
3. Diagnose out loud: "The bug is in the inner condition. I'm checking == when I should be checking <."
4. Fix: Change the line, re-trace the small example, confirm.
5. Thank them once, briefly: "Thanks for that, good check." Then move on.

What kills candidates here is defensiveness. "Are you sure?" "Hmm, I think mine works..." Even if you're fairly sure they're wrong, run their counter-example. If your code does survive, say "I traced through [1,1,2] and it returned 0, am I missing what you meant?" Calm verification beats defensive pushback every time. This is the same composure you'd hold with a rude interviewer: the test isn't whether you're right, it's whether you stay level.

Drill the recovery until the shape is automatic

Recovery is a learned skill. The drill: pick a LeetCode problem you've solved cleanly, then re-solve it knowing you'll introduce a bug halfway through. Practice catching it on a small example, naming it, and fixing it, all out loud. Don't pre-script the answer; script the shape of the response. The candidates who win recovery moments have rehearsed the shape so often that it runs even under stress.

The honest way to make this automatic is reps under realistic pressure with feedback, not a stealth tool whispering the answer mid-round. As of the 2026 hiring cycle, interview rubrics at firms like Google, Amazon, and Meta-style loops are tuned to catch recited answers a candidate can't defend, so a stealth shortcut isn't the edge it's sold as. The durable edge is being able to debug your own work live, whether the round runs on CoderPad, HackerRank's collaborative pad, or a plain shared doc. If you want to rehearse the five-step recovery against realistic prompts until it's muscle memory, run a timed mock interview and deliberately fix your own bug before the interviewer can. The plans on the pricing page cover unlimited timed sessions, and the $3 trial is enough to run your first few recoveries before your next real loop. The candidate who recovers out loud is the one who walks in able to say the whole answer, bug, fix, and all, in their own voice.

Key terms

Self-correction

Catching and fixing your own mistake on the record, out loud. One of the highest-graded signals on a coding-interview rubric, frequently scored above a clean first-try solution.

Dry run

Executing your code by hand against a chosen input, tracing the variable values line by line. The fastest way to confirm whether a suspected bug is real when you can't actually run the code.

Fix in place

A local repair (a missing edge case, a wrong operator, an off-by-one) that you can describe in one sentence without restating the algorithm. State it, change a line or two, re-trace, move on.

Scrap and restart

A deliberate rewrite because the data structure or approach can't represent the problem and no local edit can save it. One announced scrap inside a round is normal; the key word is announced.

Off-by-one error

Iterating one element too far or one too few in a loop bound or index. The single most common bug surfaced and fixed during a live coding interview.

Boundary condition

The behavior of your code at the first, last, or empty position, where a wrong comparison operator (== versus <) flips the result. The classic source of a one-line fix-in-place.

Adversarial case

The input chosen specifically because it is most likely to break your approach: duplicates, an empty list, a single element, or sorted-descending data. The trace that lets you catch the bug yourself.

About the author: Sam K. is the founder of InterviewChamp.AI and writes about the modern tech interview from the inside: what changed, what works for new grads, and where the old playbook fails.