In a fix-the-bug round on a seeded repository, what working sequence do interviewers score highest?
answer
- Five beats, in order
- Do not theorise before you have seen it fail
- The failing test is the specification
- Smallest change, cleanup kept separate
- Whole suite, not just the one test
basics
~20 sReproduce the failure first, read the failing test as the specification, localise with evidence rather than guesswork, make the smallest change that turns that case green, then re-run the whole suite and say what you would follow up. Diagnosis before edits is the scored part.
solid answer
~50 sThe rewarded loop is reproduce, localise, minimally fix, verify, narrate. Start by running the build and the failing test so the symptom becomes something you have seen, not something you were told. Read the test itself: it encodes the behaviour the code was supposed to have, and it usually names the entry point. Localise from evidence — the failure output, a stack trace, a narrowed input, a temporary probe you remove afterwards — and state your hypothesis aloud before you edit, so a wrong turn is cheap to correct. Then change as little as possible: the smallest edit that makes the failing case pass, with cleanup kept separate and offered rather than smuggled in. Finish by running the full suite, not just the one test, and by naming the regression you checked for. If time is short, a verified partial diagnosis beats an unverified fix.
go deeper
Memorise the order — reproduce, read the test, localise, minimal fix, verify — and practise it on someone else's project until you do it without thinking. Say each step aloud as you take it.
Explain why each beat exists: reproduction turns a report into evidence, the failing test is the specification, and a small diff is the only change you can verify inside the session. Show that you separate the fix from cleanup.
Show judgment when the evidence contradicts you — when your fix breaks other tests, or the failure will not reproduce. Interviewers score how you handle being wrong mid-session more than the speed of the correct fix.
Own the tradeoff between fixing the instance and fixing the class. Be able to argue when a narrow patch plus a written follow-up is the responsible call and when the defect class justifies asking for a larger change, and to defend that choice against the time and verification budget you actually have.
## The shape of the exercise In a fix-the-bug round the interviewer hands you two things: a repository you have never seen, and one failing test that encodes a reported defect. Everything else — the architecture, the naming, the test framework, the quality of the surrounding code — is scenery. The exercise is a controlled version of the most common task in software work, and it is scored on process, because the process is what generalises to the codebase you would actually join. ## The five beats **1. Reproduce.** Run the build and the failing test before you read anything at length. Two minutes here buys you the actual error text, the actual line, and the confidence that the environment works. Candidates who skip this end up debugging a mental model instead of a program, and they occasionally discover at minute forty that the test was failing for a setup reason. **2. Read the failing test as the specification.** The test states the intended behaviour, the inputs that matter and the entry point into the code. In a seeded exercise it is almost always the shortest path to the relevant module. If the test's own assertion is unclear, say so — noticing that the specification is ambiguous is a scored observation, not a complaint. **3. Localise with evidence.** Follow the failure inwards: the stack or error output, then narrowing the input, then a temporary print or an assertion at the boundary between the parts you suspect. Say the hypothesis out loud before you act on it — 'the rollup is summing the buckets before the late-arriving ones are merged, so I expect the total to be low, let me check that' — because a stated hypothesis lets the interviewer correct you in seconds and shows the reasoning that a silent edit hides. Remove the probes you added. **4. Make the smallest change that works.** The fix should be as close as possible to the defect, and it should be separable from anything you would also like to tidy. If the surrounding code is genuinely poor, say what you would change and why you are not changing it now. Rewriting the seeded codebase instead of making the failing case pass is the single most common way this round is lost: it consumes the clock, breaks tests that were passing, and leaves nothing verifiable at the end. **5. Verify and narrate.** Re-run the failing test, then the full suite. State what you checked for regressions and what you would still want — a test for the neighbouring case, a check on the boundary the original test did not exercise. If you can add that extra test inside the time, it is one of the strongest signals available in this format. ## A worked illustration At a developer-tools vendor selling a build-analytics service, a senior test engineer opens a 75-minute pairing session with a repository and one red test: the nightly rollup under-reports totals when a build record arrives after the window closes. A strong candidate spends about 9 minutes reproducing and reading the test, narrows the input until a two-record case reproduces the wrong total, forms the hypothesis that the merge happens after the sum rather than before, confirms it with one temporary probe, makes a four-line change, and re-runs 138 tests to green with about 20 minutes to spare — then spends part of that adding a case for a record arriving exactly at the boundary, and names the larger restructure they would open as follow-up work. A weak candidate in the same session decides the module needs splitting, spends 40 minutes on that, and is mid-move when time is called: the seeded test is still red, several previously green tests are now red, and the interviewer has seen no evidence about debugging at all. ## What to say when the clock beats you Honest partial work is scoreable; unverified work is not. Land the repository in a state that builds, then summarise: what you reproduced, what you ruled out, where you believe the defect is, what your next edit would be, and what you would run to confirm it. Many interviewers score that summary explicitly, because it is the same handover a real on-call engineer has to write.
- You believe you have found the defect but cannot reproduce it locally — what now?Treat the missing reproduction as the bug for the moment. Check the obvious environment causes, narrow the failing input, and ask the interviewer whether anything about the setup differs. Say plainly that you are not going to change code you cannot demonstrate is wrong; proposing a fix for a failure you have never observed is the guess this round is designed to expose.
- Your fix turns the seeded test green but two previously passing tests now fail. How do you respond?Do not delete or weaken them. Read what they assert: either your change is wrong, or those tests encoded the buggy behaviour. Say which you believe and why, show the evidence, and if it is genuinely the second case, propose updating them explicitly rather than quietly. Interviewers watch this moment closely because it is where candidates start bending evidence toward a fix.
- Would you write an additional test before or after making the fix?Before, when you can. A test that fails for the reason you believe is the cause converts a hypothesis into evidence and gives you a regression guard for free. When the setup cost is high, it is defensible to fix first and add the test immediately afterwards — but say that is what you are doing, and do actually add it.
saying these in an interview costs you the question
- Rewriting the seeded codebase instead of making the failing case pass
- Editing code before reproducing the failure once
- Weakening or deleting a test that your fix broke
- Bundling unrelated cleanup into the fix so the diff is unreviewable
- Re-running only the seeded test and declaring the round finished
- Announcing a cause with no evidence and defending it after it fails