How do you budget a 75-minute pairing round on a repository you have never seen before?

## Why the clock is part of the exercise Practical rounds are usually scheduled somewhere between 60 and 90 minutes, and the time box is not incidental — it is the constraint that makes the round informative. Anyone can fix a defect with unlimited time. The question is what you choose to do when there is not enough of it, and interviewers read your time management as a proxy for how you will behave when a production issue is open and the fix window is short. ## A concrete allocation For a 75-minute session on an unfamiliar repository: | Block | Minutes | What happens | |---|---|---| | Orientation | about 10 | Build runs, full suite runs, failing case read, success criterion stated aloud | | Diagnosis | about 20 | Narrow the input, form and test one hypothesis at a time, keep the interviewer with you | | Change | about 25 | The smallest edit that addresses the cause, re-run after each step | | Reserve | about 8 | Full suite, probes removed, repository left clean | | Wrap-up | about 7 | Spoken summary, follow-up work, your questions | The numbers are a starting shape, not a rule; the discipline that matters is the **reserve**. Whatever the total, the last tenth of the session belongs to verification and handover, not to one more idea. ## Orientation without over-reading Orientation is not reading the codebase. It is establishing that you can run it, that the failure is real, and that you know what a fix would look like. Get the build green-lit, run the whole suite once so you know its baseline — if 4 tests were already failing before you touched anything, you very much want to know that in minute three rather than minute sixty — then read the failing case. If setup fails, say so immediately; wrestling silently with an environment for fifteen minutes is a worse signal than asking. ## Making the budget visible Say the plan when you begin: 'I will spend the first ten minutes getting this running and reading the failing case, then work one hypothesis at a time, and I want the last eight minutes for a clean suite run and a summary.' Then check in against it — at the halfway point, and again when you enter the reserve. This does three things: it lets the interviewer redirect you cheaply if you are about to spend twenty minutes on something they consider out of scope, it shows the self-management that senior work needs, and it means the end of the session is a planned landing rather than an interruption. ## When you will not finish Decide early, and prefer a clean partial state to a broken complete one. Concretely: revert or park the half-applied edit, get the repository to a state that builds, and then give the handover — what you reproduced, what you ruled out, the cause you believe is responsible, the change you would make, and how you would verify it. Many interviewers score that summary as its own line on the rubric, because it is the same handover an on-call engineer writes at the end of a shift. The failure this discipline prevents is specific and common: a candidate at a developer-tools vendor's 75-minute pairing round decides the seeded rollup module needs restructuring, is 30 minutes into moving code when time is called, and hands back a repository where the seeded test is still red and 11 previously passing tests now fail. The senior test engineer running the session has no evidence about debugging, no evidence about verification, and a diff nobody can evaluate. The same candidate, having spent that half hour on a narrow fix and a clean suite, would have passed comfortably. ## Asking about the budget It is entirely reasonable to ask at the start how long the round runs, whether the last minutes are reserved for questions, and whether finishing is expected at all. In many seeded exercises it is not — the defect is sized so that some candidates will not complete it, precisely so the panel can see how people behave under an unfinished clock.