Debugging Interview Practice: Bug Bash in Unfamiliar Code

A debugging interview gives you a codebase you have never seen and a problem in it: a failing test, a bug report, or a vague symptom. You have under an hour to find the cause, fix it, and show the fix is safe. Some companies call it a bug bash or a bug squash. It is one of the formats that make up the AI coding round, and it shows up in classic loops too. For the AI rules each company sets, see our AI coding interview overview.

Practice it on AICodingRound. Every bug hunt in our library is a ticket in a working multi-file app that describes a symptom, not a line number, and tests check that your fix is safe. Start with Back-to-back bookings rejected (easy, about 20 min). The beta is free and places are limited: get a place.

What a debugging round looks like

Few companies describe this round in public, so most of what is known comes from candidates and prep sites. We label each item.

• Stripe (reported). Prep site Aced, which says its Stripe guide is updated by candidates, describes "an unfamiliar repository with a failing test or open issue" and 45 to 60 minutes to investigate and resolve it, in the language and IDE you know best (Aced). Prepfully describes 3 to 5 bugs or failing unit tests in code that purposely lacks comments, types and documentation (Prepfully). Our Stripe bug bash guide covers that round in detail.
• Google (reported). Google's AI-assisted pilot round is reported to ask candidates to "read, debug and optimize" existing code (Moneywise, citing Business Insider).
• Canva (confirmed). In its AI-assisted round, Canva asks: "Can they identify and fix issues in AI-generated code?" (Canva Engineering, June 11, 2025).
• DoorDash and others (reported). A Blind thread complaining about debugging rounds has replies naming DoorDash, and a reply from a Microsoft-tagged user who says they failed a 45-minute debug round (Blind; anonymous posts, year not shown).

The same Blind thread opens with a complaint you may share: "there's not really any good resources to prep for debugging interviews." That is the gap this guide tries to fill.

Why your process counts more than the fix

Aced's Stripe guide puts it plainly: "a clear, well-articulated diagnosis often carries more than a completed fix" (Aced). That matches what you would expect from the interviewer's seat. A lucky guess that fixes the bug tells them nothing about the next bug. A clear, narrated search that runs out of time still shows how you work.

So the interviewer is watching for a few things:

• Do you reproduce the problem before you change anything?
• Do you form one hypothesis at a time and test it, or edit at random?
• Do you say what you have ruled out, and why?
• Is the fix small, and do you check it did not break anything else?

Prepfully lists random guessing as a red flag and recommends testable hypotheses, small fixes and a regression test for each fix (Prepfully).

The loop: five steps for code you have never seen

1. Reproduce. Run the failing test, or turn the bug report into the smallest request or input that shows the problem. Write down the exact expected and actual result. If you cannot reproduce it, nothing after this step is reliable.

2. Map the path. Find where the request enters, which functions it passes through, and where the data is stored. Do not read every file. Follow one real input from the edge to the database and back. Say the path out loud as you go.

3. Narrow it down. Cut the path in half. Is the data already wrong when it reaches the halfway point? Then the bug is earlier. Add a print or a breakpoint, check, and cut again. When the code has history, the same idea works across commits: git bisect "uses a binary search algorithm to find which commit in your project's history introduced a bug" (git docs).

4. Fix the cause, not the symptom. Once one hypothesis survives a test, make the smallest change that removes the cause. Resist cleaning up nearby code. A tidy refactor in a debugging round makes your change harder to review and easier to get wrong.

5. Guard it. Write a test that fails before your fix and passes after it. Then run the whole suite, not only your new test. Explain in two sentences what caused the bug and why your change is the right place to fix it.

Using AI without losing the thread

First, find out if AI is allowed. Rules differ by company and by round. One candidate quoted by Prepfully says AI is not allowed in Stripe's bug bash, while Canva expects candidates to use their own AI tools. If you are not sure, ask your recruiter. Using AI in a round that bans it is the fastest way to fail.

When it is allowed, use the AI to speed up step 2 and step 3, and keep the decisions yourself:

• Ask narrow questions: "Where is this function called?" or "What does this query return when the list is empty?" Not "find the bug."
• Treat every answer as a claim. If the AI says a value is never null, find the place that guarantees it, or test it.
• Do not let it rewrite a whole file. A large AI diff hides the one line that matters.
• Keep your own notes of what you ruled out. The AI does not know what you already checked.

What else your fix can break

Real bugs often sit in shared code. The function you change may also be called by an export job, a webhook handler or a nightly sync. Before you call the work done, search for every caller of what you changed, and ask what each one expects.

Also think about data that is already wrong. If a bug wrote bad rows for a week, fixing the code does not fix those rows. You do not have to write a cleanup script in the interview, but saying "existing records still need a backfill" shows you think like the person on call.

A 45-minute plan for the round

This is our suggestion, not a company rule. Adjust it to the time you are given.

If you are stuck at minute 25, say so, say what you have ruled out, and say your best remaining hypothesis. That is still a strong signal.

A practice ladder, easy to hard

Each of these is a real ticket in a multi-file app from our library. The tickets describe symptoms, not causes.

• Back-to-back bookings rejected (easy, Python, about 20 min). A good first run of the five steps.
• Nightly warehouse sync misses orders (medium, Python, about 10 min). A short drill where the data looks fine until you look closely.
• One merchant's order webhooks stopped arriving and the worker logs the same error forever (medium, Python, about 40 min). Start from logs, not from a failing test.
• The accountant's month-end export doesn't match the dashboard (hard, Python, about 60 min). Rows go missing or appear twice, and more than one suspect looks guilty.
• Flash sale sold 53 units of a kettle with 40 in stock (hard, TypeScript, about 60 min). Hard to reproduce on purpose.

Run the loop on AICodingRound

AICodingRound is built for this round. Pick a problem from the ladder, set a timer for its time limit, and run the five steps exactly as you would on the day: reproduce in the terminal, map the path, narrow it down, fix the cause, guard it with a test. Narrate out loud, even alone.

When you submit, tests check that the fix works and that nothing else broke, so a fix that breaks another caller shows up. Then a short debrief asks what caused the bug and how you checked your fix: the same two-sentence summary the 45-minute plan ends with. The report gives a level per skill (Strong, Solid or Developing), including how you used AI.

Bring your own Claude or Codex as a coach: it reads code and explains, but it does not write the fix. For a round that bans AI, leave it closed. The beta is free and places are limited: get a place.

If your bug is in a query, our guide to SQL debugging interview questions has a method for that.