Debugging interviews: how the round works and how to narrate it
In a debugging interview you get unfamiliar code and a bug report, and you have 30 to 60 minutes to find the cause and fix it. Prep guides agree that the method is scored more than the speed: reproduce the failure, read what the code does, state a hypothesis, narrow it down with a test or a print, make the smallest fix, then check it and look for the same bug nearby. Saying each step out loud is what makes the method visible.
Key points
- Reproduce first. A bug you cannot trigger is a bug you cannot prove fixed.
- Read the code path before editing anything, and say what each part is supposed to do.
- Say a hypothesis before each experiment, and what result would confirm or rule it out.
- Make the smallest change that the hypothesis predicts will fix it.
- Verify with the original report and one more case, then ask whether the same mistake appears elsewhere.
What the round looks like
Formats vary. Some rounds give a short program of 50 to 200 lines with one planted bug; others hand over a small codebase with failing tests and several issues of rising difficulty. You usually can run the code. Some companies call it a “bug squash” or fold it into a code review exercise, where you read a change and point out what will break.
What stays the same is the signal: can you find your way around code you did not write, and do you debug by evidence rather than by guessing. Editing at random until the tests pass is a pattern interviewers name as a fail, even when it eventually works.
The method, step by step
- Restate the report: what was expected, what happened, under which input.
- Reproduce it, ideally with the smallest input that still fails.
- Read the code path the input takes. Say what each function is meant to return.
- Form a hypothesis about where the state first goes wrong.
- Test the hypothesis with the cheapest experiment: a print, an assertion, a smaller input.
- Fix with the smallest change the hypothesis predicts will work.
- Verify: the original case, an edge case, and the existing tests.
- Look around: does the same mistake appear in sibling code? Would a test have caught it?
A worked bug: the best-sellers list
Report: “The best-sellers widget shows slow-moving products at the top.” Best-selling means most units sold. The function:
def best_sellers(orders, k):
counts = {}
for order in orders:
for line in order["lines"]:
counts[line["sku"]] = counts.get(line["sku"], 0) + 1
ranked = sorted(counts, key=counts.get)
return ranked[:k]Narrating it
“Small case: product A in three orders of one unit, B in one order of 500 units, C in two orders of one unit. By units sold I expect B, A, C.”
“It returns B, C, A. A sold more than C but comes last, so the order looks reversed. Line six sorts ascending and takes the first k. Hypothesis: it needs reverse=True.”
“With that change I get A, C, B. Now the 500-unit product is last. So there’s a second cause: line five adds 1 per order line and ignores the quantity. That also explains why B looked right before: it had the fewest lines.”
“Adding line['qty'] instead of 1 gives B, A, C, which matches. I’ll check ties and a k larger than the number of products, and I’d add a test with a bulk order, since nothing caught this.”
Common mistakes
- Editing before reproducing, so you cannot tell whether the change did anything.
- Changing several things at once and losing track of which one mattered.
- Stopping at the first fix without re-running a case that reflects what the report means. One bug can hide another.
- Rewriting the function instead of fixing the bug. The interviewer wants the smallest correct change.
- Going quiet while reading. Say what you are reading for.
- Skipping verification because the fix “obviously” works.
How to practise
Practise the reading as much as the fixing. When you open unfamiliar code, say what you are reading for: where the input enters, where the output is built, and which variables change along the way. Interviewers cannot see you read; a sentence such as “I’m looking for where the count is updated” shows them you have a plan.
Take small programs you wrote months ago, plant one bug in a copy (an off-by-one, a wrong default, a reversed comparison, ignored input), wait a day, then find it out loud with a timer. Reading other people’s code changes helps too: code review guides list what reviewers look for (correctness, edge cases, naming that hides intent), and that list doubles as a list of where bugs hide.
Questions
Is a debugging round harder than a coding round?
It tests a different skill: there is less to invent and more to read. Candidates who are fast at writing new code are sometimes slow at reading unfamiliar code, which is why the round exists.
Can I use a debugger?
Usually yes, if the environment has one. Prints and assertions are fine too. What matters is that each experiment tests a hypothesis you said out loud.
What if I cannot find the bug in time?
Say what you have ruled out and what you would try next. A clear trail of evidence scores better than a lucky fix with no explanation.
Practise this out loud with Vera
Mockich has no separate debugging round on the site today. The closest practice is the coding round, 45 min: two problems at regular and one deeper at lead, in an editor that runs your code. Vera asks for your plan and its complexity before you type, stays mostly quiet while you work, and gives at most three small nudges, never the answer. The report scores problem solving, code quality and correctness, complexity and optimization, testing and edge cases, communication (plus production thinking at lead) and quotes what you said. When a case fails, Vera does not fix it for you; expect a question about what you expected and why the case fails.
Related guides
Sources
We read these sources on 2026-11-03 for the round format and the habits interviewers reward (source 5 only as a course outline in search results); the checklist of what to read for follows the engineering practices guide (CC BY 3.0), and the best-sellers bug, its code and the spoken lines are our own.
- [1] techinterview.org, Debugging interview format
- [2] PracHub, Code review interview guide: how to find bugs and explain trade-offs
- [3] Levelop, Why companies are moving from “solve this problem” to “explain this code”
- [4] Google, Engineering Practices: what to look for in a code review (CC BY 3.0)
- [5] Exponent, Debugging interviews (practical coding interviews course, course outline)