In a pairing round you spot a structural flaw behind the seeded bug — do you patch narrowly or restructure?
answer
- Two horizons, one session
- Say what you saw before you choose
- Verifiability decides it
- The scope belongs to the interviewer
- Narrow fix plus a named follow-up
basics
~20 sDefault to the narrow, verified fix and name the structural flaw as follow-up work you would open. Restructure only when the minimal change would be a knowing hack, the larger one is provable in the time left, and the interviewer confirms the scope is open.
solid answer
~50 sSay what you found before you decide anything: name the structural weakness, say what class of defect it will keep producing, and then propose the plan you intend to follow. In almost every timed round the right plan is the narrow fix plus a written follow-up, because it is the only option you can verify before the session ends, and because a candidate who separates the defect from the design shows exactly the discipline a team wants in a production incident. Restructuring earns its place in three conditions together: the minimal change would be a hack you would object to in review, the restructure is genuinely small and coverable by the existing suite, and the interviewer has confirmed the scope allows it. Ask that last one explicitly — the scope is theirs to set. What loses the round is starting the restructure silently, because the interviewer sees only a growing diff and a red suite.
go deeper
Learn the default and follow it: make the reported case pass with a small change, then say what else you noticed. You are not expected to redesign someone else's code in an hour.
Be able to explain why verification decides this — a small change can be proven correct in the session and a large one cannot — and to write the follow-up note concretely rather than vaguely.
Show that you ask about scope instead of assuming it, and that you can name the defect class the flaw will keep producing. Interviewers score the fact that you saw it and still chose the disciplined path.
Own the tradeoff between fixing an instance and removing a class, under a real budget. Be ready to argue when accumulating narrow patches becomes the more expensive choice, and how you would sequence the structural work so it is scheduled rather than smuggled into a bug fix.
## The decision Somewhere in a good practical round you will see past the seeded defect to the reason it exists: a boundary in the wrong place, a shared mutable structure, an ordering assumption baked into two modules. The exercise then poses a genuine engineering judgment, and it is the one this round is best at revealing — because the wrong answer is attractive. Fixing the design feels more senior than patching the symptom, which is exactly why candidates walk into it. ## The default, and why it is the default The default is the narrow fix plus an explicit follow-up, for three reasons that are about the constraint rather than about ambition: - **Verification.** You can prove a four-line change is correct in the time you have. You cannot prove a restructure is correct in the same time, and an unverified restructure is worth less than no change at all — it destroys the evidence you had. - **Reviewability.** A diff that mixes a behaviour fix with a structural move cannot be reviewed as either. Separating them is a habit teams pay for. - **Reversibility.** A narrow fix can ship now and be reverted cheaply if it is wrong. A restructure is a decision with a long tail, and making it inside 75 minutes on code you met an hour ago is not judgment, it is confidence. The naming matters as much as the fix. Say it concretely: which class of defect the flaw produces, what you would change, roughly what it would cost, and how you would sequence it behind the patch. That sentence is often what the interviewer writes on the scorecard, because it demonstrates you saw the design problem *and* chose correctly anyway. ## When restructuring is the right call Three conditions, and you want all three: 1. **The minimal fix would be a knowing hack.** If the only way to make the failing case pass without touching the structure is a special case you would block in review, patching it teaches the interviewer something worse than the flaw did. 2. **The larger change is small and covered.** The seam is a few lines away, and the existing suite exercises the affected paths well enough that a green run after the move is real evidence rather than an absence of tests. 3. **The scope is confirmed open.** Ask: 'the deeper issue looks like the ordering assumption between these two parts — is fixing that in scope, or would you rather I patch the reported case and write the follow-up?' The interviewer sets the scope. Asking is not weakness here; unilaterally expanding it is the failure. ## A worked illustration At a developer-tools vendor selling a build-analytics service, the seeded failing test shows a nightly rollup under-reporting when a record arrives late. Forty minutes in, a candidate sees the real cause: the merge step and the sum step read the same buffer with no ordering guarantee, so late arrival is one of several ways it can be wrong. Two paths from there. The strong one: fix the ordering at the call site in 5 lines, re-run the 138-test suite to green, then say — the buffer is shared by 3 call sites and only one of them is now ordered correctly; the durable fix is to make the merge return a value instead of mutating in place, which is maybe half a day with the tests it needs, and here is the note I would leave. The weak one: begin the half-day change with 35 minutes remaining. At the buzzer the seeded test is still red, 11 other tests are red, and the diff spans 9 files. The diagnosis was better than most candidates managed, and none of it is visible. ## What this is really scoring At the top of the ladder, the interesting question is not whether you can see the structural flaw — plenty of candidates can. It is whether you can hold two horizons at once: fix the reported thing now, verifiably; and record the thing that will cause the next three reports, so it can be scheduled rather than improvised. Teams promote for that, and this round is one of the few places in a loop where it can be observed directly rather than claimed in a story. The symmetric failure is worth naming too: patching narrowly and saying nothing. That candidate looks identical on the diff to one who never noticed, and the round has no way to give credit for a thought that was never spoken.
- How do you word the follow-up so it counts, rather than sounding like an excuse for the narrow patch?Make it specific and costed. Name the mechanism, the class of defect it produces, the change you would make, and a rough size — the ordering assumption between the merge and the sum will keep producing wrong totals whenever records arrive out of order; making the merge return a value instead of mutating removes the class, and it is about half a day with tests. Vague regret sounds like an excuse; a plan does not.
- The interviewer says the scope is open and invites you to restructure. Does that change your answer?It removes one of the three conditions, not all of them. Verifiability still binds: if the existing tests do not cover the paths you would move, a green run afterwards proves little, and you should say so. When the coverage is there and the seam is close, take the invitation — and still land a verified state before the buzzer, even if that means stopping partway with the suite green.
- What if the narrow fix requires a special case you would object to in review?Then say that out loud, because it is the condition that flips the default. Describe the hack, say why you would block it in review, and propose the smallest structural change that avoids it. If time will not allow even that, implement the narrow version, mark it explicitly as a stopgap in a comment or your summary, and state what must replace it. Knowingly shipping a hack silently is the only truly bad option.
saying these in an interview costs you the question
- Starting a restructure silently, so the interviewer sees only a growing red diff
- Rewriting the seeded codebase instead of making the failing case pass
- Patching narrowly and never mentioning the structural cause you saw
- Expanding scope without asking whether the round allows it
- Claiming a large refactor is safe when no test covers the moved paths