Courses › AI-Assisted Coding › Round Types

Debugging with AI

Hypothesis-driven debugging instead of the "fix this error" loop.

Debugging rounds hand you a failing test suite or a bug report and ask you to find and fix the problems, often several of them, sometimes interacting. The trap in AI-assisted debugging is the "fix this error" loop: paste the stack trace, accept a patch, rerun, repeat. It sometimes works, but it hides your reasoning, it often fixes the symptom instead of the cause, and interviewers are specifically watching for it.

The loop that scores well

[Reproduce] -> [Read the failure] -> [Hypothesize] -> [Test the hypothesis] -> [Fix the root cause] -> [Run everything] -> [Explain]

1. Reproduce and triage

Run the tests and group the failures. Ten failing tests often have two or three causes. Start with the failure that looks most fundamental, such as a parsing or model error that other failures depend on. The goal is to fix causes, not to chase every red line.

2. Read the failure yourself first

Read the assertion, the expected value and the actual value, and the top of the stack trace in *project* code. Form your own hypothesis before you ask the assistant. Say it out loud:

"Expected 3 items but got 4, and the extra one is a duplicate. My guess is the dedup step compares objects by identity instead of by ID."

3. Use the assistant to test hypotheses, not to guess

Good uses:

  • "Explain what merge_records does with duplicate IDs. Walk through it with this input."
  • "Where else is normalize_date called, and do any callers pass time zones?"
  • "Write a minimal test that isolates whether the bug is in the parser or in the sorter."
  • "Add temporary logging around the cache lookup so we can see the keys."

Weak uses:

  • "Fix this error" with a pasted stack trace and no hypothesis
  • Accepting a patch that makes the test pass without understanding why it works

4. Fix the root cause and check the blast radius

Before you accept a fix, ask yourself:

  • Does it fix the cause, or just silence this particular symptom (a special case, a swallowed exception, a loosened assertion)?
  • Does the same bug exist anywhere else? Look for copy-pasted logic.
  • Could the fix break another caller?

[!WARNING] Never edit the test to make it pass Unless you can explain why the test itself is wrong, and say so explicitly, changing an assertion is a red flag. Assistants sometimes do this quietly when they're asked to "make the tests pass". Read every diff to the test files.

5. Run everything, then explain

Run the full suite after every fix. Some bugs hide behind others. At the end, give a short summary of each bug: the symptom, the root cause, the fix, and how you'd prevent it. For example: "Off-by-one in pagination. range(1, n) skipped the last page. Fixed with range(1, n + 1) and added a test for an exact multiple of the page size."

Bugs that are planted most often

  • Off-by-one errors at boundaries (pagination, ranges, slicing)
  • Mutable default arguments, or shared state leaking between tests
  • Comparing by identity instead of equality, and string vs. number comparisons
  • Time zone, date format and locale issues
  • Integer division and rounding of money
  • Missing await or unhandled errors in async code
  • Caches that aren't invalidated after a write
  • Wrong error handling: catching too much, or swallowing an exception

Narration is the signal

In a debugging round, the interviewer can't see your reasoning unless you say it. A short narration at each step ("Hypothesis: X. Checking by running Y. Confirmed, because Z.") turns an ordinary fix into a strong score.

[!TIP] Practice Debug a Failing Test Suite with AI · Reviewing AI Code