Debugging interview questions
6 questions across 2 sections, in the order you would learn them. Every answer here is one that works — but an answer you have read is not an answer you can give, so use Test yourself and say it out loud first.
Debugging systematically
Read the section that teaches thisIf this comes up in an interview
Walk me through how you debug something.
Reproduce it reliably first. Then one hypothesis at a time, choosing the cheapest experiment that could falsify it rather than confirm it. Bisect the pipeline to eliminate half the system per check rather than inspecting sequentially.
An AI feature returns a wrong answer but nothing errors. Where do you start?
The rendered prompt, exactly as sent, and the retrieved context. Most of the time the answer was not in what the model was given, which makes it a retrieval problem rather than a generation one, and those have completely different fixes.
A bug reproduces about one run in twenty. How do you work on it?
Measure the rate before changing anything, because a clean run proves almost nothing: at one in twenty, three consecutive passes happen about 85 per cent of the time, and you need around 59 runs to be 95 per cent sure of seeing it once. Then remove one source of variance at a time — fix the seed, temperature to zero, a single worker, a frozen clock — and see which one it hangs from. Separately, capture the full context of every failure as it happens, because you cannot go back and collect it.
What gets marked up. Strong answers give a rate rather than a story, and say what they would capture. Re-running until it passes is the answer being tested for.
How do you approach an intermittent bug?
Find what varies between runs: concurrency, timing, external dependencies, or sampling. For AI systems, non-zero temperature means identical input genuinely produces different output, so establish whether it is a bug or variance before hunting.
The tools: debugger, profiler, logs, bisect
Read the section that teaches thisIf this comes up in an interview
A nightly batch job that used to take 20 minutes now takes three hours. How do you find out why?
Check what changed: code, data volume, dependencies, the external APIs it calls. Profile a run on a sample to see where time goes, and look at logs for per-step timings. If a code change is suspected, bisect between the last good and first bad versions.
Then they push further
The profile shows it waiting on network calls that used to be fast. Now what?
Check whether the service slowed down or whether you now make more calls, for example a retry storm or a loop that lost its batching. Logs with per-call timings and counts separate the two.
What gets marked up. Marked up for measuring before guessing and for checking what changed. Jumping to a fix without data is marked down.
What does git bisect do?
Binary search through commit history to find the one that introduced a problem. You mark a good and a bad commit, and git checks out midpoints for you to test, or runs a test script automatically.
These are the questions for one topic. The whole question bank covers every topic on the site.