A debugging interview is a technical round where you are given code that does not work, often an unfamiliar codebase with a failing test or a bug report, and asked to find and fix the problem while explaining your reasoning. It tests how you read code you did not write, form and test hypotheses, and use your tools, rather than how well you remember algorithms.
Companies that use this format want to see something close to everyday engineering work, since most engineers spend more time reading and fixing existing code than writing new code from scratch. The good news: a calm, systematic approach scores well even if you do not find the bug in the first ten minutes.
What does a debugging interview look like?
Formats vary, but most debugging rounds fall into one of these types:
- Failing tests in a small repository. You get a project of a few files to a few thousand lines, a test suite with one or more failures, and 45 to 60 minutes to make the tests pass.
- A bug report. You get a description such as "users sometimes see duplicate items on page 2" and must reproduce it, find the cause and fix it.
- A single broken function. A shorter variant inside a coding round: a function with a subtle bug or two, and you explain what is wrong and fix it.
- An incident discussion. No code; the interviewer describes a production problem and asks how you would investigate it step by step.
Some companies describe this round publicly. Stripe's Atlas guide on scaling engineering organizations describes a "Bug Squash" interview in which candidates and interviewers sit side by side to solve a real historical bug (as of October 2026). It is an older guide, so check with the recruiter for the current process; our Stripe interview process guide covers the full loop.
For how this round fits with other formats, see our hub on types of job interviews.
What is scored in a debugging interview?
Interviewers commonly care more about how you search than about how quickly you find the bug. Here is what strong and weak performance typically look like:
| Signal | Strong | Weak |
|---|---|---|
| Orientation | Spends a few minutes understanding the structure, entry points and tests before changing anything | Starts editing the first suspicious line |
| Reproduction | Runs the failing test or reproduces the bug first, and reads the actual error | Guesses at the cause from the description alone |
| Hypotheses | States a specific hypothesis and a quick way to check it | Makes random changes to "see what happens" |
| Tool use | Uses the debugger, targeted print statements, search and version history fluently | Reads the whole codebase line by line |
| Communication | Narrates what they know, what they suspect and what they ruled out | Goes quiet for long stretches |
| The fix | Minimal, targeted fix plus a test that would have caught the bug | Large rewrite, or a patch that hides the symptom |
| Root cause | Explains why the bug happened and where similar bugs might exist | Stops as soon as the test turns green |
A systematic debugging approach
Use the same steps every time. Having a routine keeps you moving when you are nervous and gives the interviewer a clear picture of your process.
- Orient (3–5 minutes). Read the README, look at the folder structure and find the entry point and the test files. Say out loud what you think each part does.
- Reproduce. Run the failing test or trigger the bug. Read the full error message and stack trace; it often points to the right file.
- Narrow the search. Find the boundary between correct and incorrect behavior. Which input works and which fails? Which function receives good data and returns bad data?
- Form one hypothesis at a time. "I think the offset is calculated from the page number without subtracting one." Make it specific enough to test.
- Test it cheaply. Add a print statement, set a breakpoint or write a tiny test. Confirm or rule out the hypothesis before changing real code.
- Fix minimally. Change the smallest thing that addresses the root cause, not the symptom.
- Verify and protect. Rerun the whole test suite, then add a test that fails without your fix.
- Explain. Summarize the root cause, the fix and anything else in the code that looks risky for the same reason.
A sample debugging walkthrough (example we wrote)
The setup: a small Python service returns a list of products in pages of 10. The bug report says, "Page 2 shows some of the same products as page 1." One test, test_pages_do_not_overlap, is failing.
Minutes 0–5, orient. "There's a products.py module with a get_page(page, size) function, a small data file and one test file. The test calls page 1 and page 2 and checks that no ID appears in both. Let me run it."
Minutes 5–8, reproduce. "It fails. The assertion shows one product, ID 11, on both pages. So the overlap is a single item at the boundary between pages."
Minutes 8–15, first hypothesis. "One possibility is duplicate rows in the data file, so the same product exists twice. Let me check that quickly by counting unique IDs in the file." The counts match, so the candidate says: "The data is clean, so I can rule that out. The problem is probably in how we slice the list."
Minutes 15–22, second hypothesis. "Here's the function. It computes start = (page - 1) * size, which looks right, and end = start + size + 1. Let me print the length of page 1." It prints 11. "So each page returns one item too many. The end index is treated as inclusive, but Python slices already exclude the end, so the last item of each page repeats as the first item of the next."
Minutes 22–35, fix and verify. The candidate changes the end to start + size, runs all tests (all pass) and adds a test that checks every page has exactly size items except the last one.
Minutes 35–45, explain. "The root cause was an inclusive-end assumption on an exclusive slice. I'd search for the same pattern in the other list endpoints, and I'd add a test for the last, partial page, which nothing covered before."
The first hypothesis was wrong, and that is fine. The interviewer saw a clear process, a willingness to revise and a fix that addressed the cause.
How do you prepare for a debugging interview?
- Fix real bugs in open-source projects. Pick a project in your main language, clone it, run the tests and work through a few beginner-labeled issues. Reading unfamiliar code is the core skill.
- Learn your debugger properly. Breakpoints, stepping into and over, watching variables and conditional breakpoints. Many candidates only use print statements, which is fine, but fluency with both is better.
- Practice reading stack traces. Break your own code on purpose and practice going from error to cause quickly.
- Set up your environment ahead of time. If you will use your own machine, make sure your language, test runner and editor work before the call.
- Rehearse narration. Debugging is where people go quiet most. Practice saying "what I know, what I suspect, what I'll check next" every few minutes. Our guide on thinking out loud in coding interviews has drills.
- Review common bug types. Off-by-one errors, null or empty inputs, mutation of shared state, wrong comparisons, time zones and caching are frequent sources.
Debugging also overlaps with the pair programming interview, where you may start from an existing codebase, and with the common coding interview mistakes worth avoiding in any technical round.
Practice it
The explanation part of a debugging round is the easiest to rehearse on your own. With CoPilot Interview, an AI interview assistant built for practice, you can run a mock technical interview from your résumé and the job description, answer out loud and get each answer scored out of 10 with what to fix. It is free for 15 minutes a day with no account. Use it to practice explaining root causes and trade-offs, and do the hands-on bug fixing in real repositories. Follow each employer's rules on AI tools, and use AI to prepare beforehand.
Rehearse your technical explanations
Answer technical questions out loud, get a score out of 10 with what to fix, and compare your answer against a model answer.
Try a free AI mock interviewFAQ
What is a bug squash interview?
Bug squash is a name some companies use for a debugging round: you work through a real or realistic bug in an existing codebase while the interviewer watches and discusses your approach. Stripe has described a round by this name in its public Atlas guide.
Do I need to find the bug to pass a debugging interview?
Not always. Interviewers commonly score your process: reproducing the issue, forming and testing hypotheses, using tools well and explaining clearly. Finding and fixing the bug helps a lot, but a disciplined search can still earn a positive rating.
Can I use a debugger in a debugging interview?
Usually yes, and using it well is a positive signal. Ask the recruiter what environment you will work in and whether you can use your own editor and tools.
How long is a debugging interview?
Commonly 45 to 60 minutes. Some debugging tasks are shorter and appear inside a regular coding round. Ask the recruiter for the length and the language of the codebase.
What language is the codebase in?
It depends on the company. Some let you choose from several languages, others use the language the team works in. Ask in advance so you can practice in that language and set up your tools.
How is a debugging interview different from a coding interview?
A coding interview asks you to write new code for a defined problem. A debugging interview asks you to understand existing code and find what is wrong, so reading, tool use and hypothesis testing matter more than knowing algorithms.