How should you budget the clock in a 45-minute technical phone screen?
answer
- The invite length is not problem time
- Setup and closing are fixed overheads
- Ask early: one problem or two
- Decide your stopping point before you need it
- Reserve minutes for checking, cut them last
basics
~20 sReserve a few minutes for setup and a few for closing, ask early whether the screener has one problem or two, and size your depth on the first problem to whatever answer you get. A finished modest solution beats a perfect unfinished one.
solid answer
~50 sTreat the invite length as a budget with fixed overheads. Setup — joining, audio, opening the shared-editor session link, brief intros — reliably eats four to six minutes, and a closing window for your own questions eats another three or four, so a 45-minute invite gives you somewhere near 35 minutes of problem time. The single most useful thing you can do with that budget is ask, early, whether there is one problem or two: two problems means the first must be finished rather than perfected, and depth you spend on it comes directly out of the second. Then keep checking in against the clock out loud — saying you have a working version and asking whether to optimise or move on lets the screener spend their own budget deliberately. Silent overrun is what turns a competent screen into a no-hire.
go deeper
Know that setup and closing consume real minutes, so a 45-minute call gives roughly 35 minutes of problem time. Ask early whether there is one problem or two.
Explain how the answer to that question reshapes your depth budget, and describe the reserve you keep at the end of each problem for checking rather than for more features.
Demonstrate live re-planning: naming a blown budget, deliberately trading a better approach for a finished one, and telling the screener what you are doing and why.
Own the design tradeoff when you set the format: one problem yields depth but a single point of failure, two yield breadth but reward speed over care, and the choice biases who passes.
## The budget has fixed overheads Candidates plan a screen as though the invite length is problem time. It is not. Using an illustrative 52-minute invite at a developer-tools vendor, hiring a mid-level full-stack engineer, a realistic split looks like this: | Segment | Minutes | Notes | | --- | --- | --- | | Joining, audio, opening the session link, intros | 6 | Shrinks to 2 if you opened the link beforehand | | First problem | 23 | Includes reading, agreeing the approach, writing, checking | | Second problem, if there is one | 19 | Often a smaller problem, or a variation on the first | | Your own questions, next steps | 4 | Screeners protect this; it is not spare capacity | On a 45-minute invite the same overheads leave roughly 35 minutes of problem time. That number, not 45, is what you are planning against. ## The one question that reshapes the plan Ask near the start: **is this one problem or two?** The answer changes the entire depth budget. - **One problem.** You have room to explore, discuss alternatives, and improve a first working version. Depth is rewarded, because there is nowhere else for the remaining time to go. - **Two problems.** The first must *finish*. Every extra minute of polish on problem one is a minute stolen from problem two, and a screener with two problems planned usually wants signal from both. Aim to land the first in a little over half your problem time and leave the rest intact. Some screeners will not commit — they decide based on how the first goes. That is still useful information: it means the first problem is the real one and the second is a bonus, so finishing cleanly matters more than moving fast. ## Spending the first problem's budget A workable internal split for a 23-minute problem: a few minutes to understand it and agree on an approach, the bulk on writing, and a firm reserve of four or five minutes at the end for checking and cleanup. The reserve is what candidates cut first and should cut last — it is where an off-by-one gets caught and where the session link gets left in a readable state. The key discipline is **deciding a stopping point before you need one**. Pick, in advance, the moment at which you will stop improving and start confirming: for example, when a third of the problem budget remains. Once you are past that mark, new ideas get *described* rather than implemented. ## Check in against the clock, out loud The screener owns the schedule and you do not, so surface your position and let them steer. Two short check-ins are usually enough: - After a first working version: *I have something working for the straightforward cases — would you rather I improve this or move on?* - When the reserve begins: *I have about five minutes of my own budget left; I am going to use it to check edge cases rather than start the faster version.* Both read as clock management, not as asking for permission. They also protect you: if the screener wanted to move on, you now know, and if they wanted the faster version you have their blessing to spend the time. ## The failure this prevents The most common way a capable candidate loses a phone screen is spending the clock reaching for the optimal solution and never running anything. It rarely feels like a mistake in the moment — each minute is spent productively on a genuinely better approach — and it ends with a session link containing an unfinished rewrite and a screener with nothing to write up. Budgeting the clock is the specific countermeasure: the reserve exists precisely so that ambition cannot consume the whole call. ## Recovering a budget you have already blown If you are at two-thirds of the clock with nothing working, stop adding and start subtracting. Simplify to the least clever thing that can produce a right answer for the ordinary case, get that to a demonstrable state, and say plainly what you are doing and why. A screener watching a candidate deliberately trade elegance for a finished result at minute 30 is watching good judgment; a screener watching the same candidate still typing at minute 44 is watching a no-hire. ## Preparing the budget before the call Open the session link early. Have water, a notepad, and a quiet room. Know your own overhead: if you habitually spend eight minutes understanding a problem, that is not a flaw, but it means you must plan a shorter writing window rather than pretending the eight minutes will not happen.
- Why does hearing that there are two problems change how deep you go on the first?Because the budgets are shared. A screener with two problems planned wants evidence from both, so polish on the first is subtracted directly from the second. The target shifts from best possible answer to finished, checked, and legible in a little over half the problem time, with improvements described rather than implemented.
- Is it acceptable to ask the screener how much time is left?Yes, and it reads as competence rather than anxiety. Asking once or twice, tied to a decision — whether to optimise or move on — shows you are managing a shared budget. Asking every few minutes reads as anxiety, and asking never usually ends with a session link full of unfinished work.
- What do you do if setup eats far more of the clock than planned?Name it and re-plan out loud: acknowledge the lost minutes, and say you will aim for a straightforward working solution rather than the stronger approach you would otherwise attempt. Screeners generally account for lost setup time in their write-up, but only when the candidate visibly adapted rather than pretending the budget was unchanged.
saying these in an interview costs you the question
- Planning against the invite length instead of actual problem time
- Never asking whether there is a second problem
- Cutting the checking reserve first when time gets tight
- Silently overrunning rather than surfacing the clock position
- Still adding to an unfinished rewrite in the final minutes