Home / Blog / How to Recover After a Wrong Approach in a Coding Interview

How to Recover After a Wrong Approach in a Coding Interview

Published 2026-10-05 · Luna Interview

Fifteen minutes in, you have a half-written solution, and then you see it: the greedy choice fails on a simple case, or the sort destroys the order you need, or the nested loops will never fit the input size. Your stomach drops. The tempting move is to keep patching and hope nobody notices.

Realizing you took a wrong approach is not the failure. Most interviewers expect some wrong turns. What they watch is how you recover. This guide gives you a short routine for recovering after a wrong approach in a coding interview so the pivot reads as good judgment instead of panic.

Why wrong approaches happen to strong candidates

• You pattern-matched too fast ("looks like sliding window") before checking the constraint that breaks it.
• You skipped a hand-worked example, so the flaw stayed hidden.
• The problem was designed with a tempting but wrong first idea.
• Nerves made you commit early to avoid silence.

None of these mean you are not good enough. They mean you need a recovery move you have practiced.

The 60-second recovery routine

1. Stop typing (2 seconds)

Take your hands off the keyboard. Continuing to type while you think signals that you have not noticed the problem, and it adds more code you will need to undo.

2. Name the flaw out loud (10 seconds)

Say exactly what breaks, with a concrete case:

"I just realized greedy fails here. With coins 1, 3, and 4 and a target of 6, greedy picks 4 + 1 + 1, which is three coins, but 3 + 3 is two."

Naming it with an example shows you understand why the approach is wrong, which is valuable signal in itself.

3. Salvage what still works (10 seconds)

Most wrong approaches still contain useful pieces: input parsing, a helper function, the base cases, the data structure you chose.

"The parsing and the edge-case checks still hold. The part that has to change is how I pick the next coin."

4. Re-plan before you code (20–30 seconds)

State the new approach and its complexity before touching the keyboard:

"Instead, I'll compute the minimum coins for every amount up to the target, building on smaller amounts. That's O(target × number of coins) time and O(target) space."

If you are not sure of the new approach yet, say the brute force that is definitely correct, then improve from there.

5. Check in briefly (5 seconds)

"Does that direction sound reasonable before I rewrite this part?"

Interviewers often give a small nod or hint here. If they say "go ahead," you have their buy-in.

6. Verify the new plan on the breaking case

Walk the example that broke the old approach through the new one before coding much. If it handles that case, you have real evidence you are on the right path.

Rewrite or patch?

When you rewrite, do not delete the old code silently. Comment it out or leave it above with a note like // first attempt: greedy, fails on [1,3,4], 6. It shows your reasoning trail.

Talk tracks for different moments

Caught it yourself early:

"Before I go further, let me test this on a tricky case. ... Yes, this breaks with duplicates. Let me adjust."

Interviewer points it out:

"Good catch, thank you. You're right, that fails when the array is unsorted. Let me think about what changes."

Thank them, do not argue, and do not over-apologize. Then use the routine.

Running low on time:

"I have about eight minutes. The correct approach is a BFS from all the rotten cells at once. Let me code the core loop and talk through the edge cases."

Feeling the panic:

"Give me a few seconds to rethink this."

Then actually rethink: write the input, the expected output, and one line describing the new idea.

What interviewers notice in a recovery

In real engineering work, changing direction after finding a flaw is normal. A clean recovery shows the kind of engineer people like working with.

Prevent the next wrong approach

You cannot avoid every wrong turn, but you can catch them earlier:

• Work one example by hand before choosing an approach.
• Try one adversarial case (duplicates, negatives, empty, sorted vs unsorted) before coding.
• Say the brute force first. It gives you a correct fallback if the clever idea collapses.
• Check the constraints. Input size often tells you whether O(n²) is acceptable.

Practice drills

1. Deliberate wrong start. Pick a problem where a greedy idea is tempting but wrong. Start with greedy, find the counterexample, and run the full recovery out loud.
2. Partner interrupt. Have a partner say "Does that work for [case]?" at a random moment. Practice the thank-and-adjust response.
3. Five-minute rescue. Set a timer for five minutes left, then practice stating the correct approach and coding only the core.
4. Recording review. Record a mock and listen for the moment you realized something was wrong. How long did you stay silent?

Soft practice note

Recovery is a skill you build by practicing it under a little pressure. If you want a Chrome side panel to run timed drills where you deliberately pivot and narrate the change, Luna Interview is built for calm, structured practice. It is for rehearsal, not for getting around interview rules.

Day-of checklist

• [ ] One hand-worked example before choosing an approach
• [ ] One adversarial case before coding
• [ ] Brute force stated as a fallback
• [ ] Recovery routine ready: stop, name, salvage, re-plan, check in, verify
• [ ] Thank-and-adjust sentence ready if the interviewer finds the flaw
• [ ] Reminder: a clean pivot is signal, not failure

The wrong approach is one moment in the round. The recovery is what the interviewer remembers.

Rehearse with an AI interview copilot, then browse commonly reported interview questions.