Timeboxing a 45–60 Minute Round

The decision at minute 27

You are implementing a rate limiter in a 45-minute coding round. The interface is clear and most of a fixed-window version is on the screen. Then a boundary test demonstrates the familiar burst problem: a client can use its full allowance at the end of one window and again at the start of the next.

There are eighteen minutes left. You could replace the model with a token bucket, finish the fixed-window version and explain its limit, or keep editing until the interviewer stops you. Which answer should the clock choose?

It cannot choose without knowing what remains to be proved. If the interviewer asked for a production-quality policy, the model may need to change. If the exercise is primarily about implementation, an explicit fixed-window baseline, tested at its boundaries and followed by a credible extension, may be the stronger complete answer. The clock does not make the engineering decision. It forces you to make one while there is still time to show its consequences.

Timeboxing is therefore less about punctuality than about evidence. A round that ends with an ambitious artifact half built asks the interviewer to infer correctness, judgment, and recovery. A smaller answer that is framed, finished, tested, and honestly bounded gives them something they can evaluate.

The part of the clock you cannot borrow from

The calendar invitation is not the working time. Introductions, prompt reading, tool friction, interviewer follow-ups, and the closing conversation all take minutes. A nominal 45-minute round may offer little more than half an hour for the main artifact. Sixty minutes creates more room, but also permits a larger wrong turn.

Before beginning, establish what kind of completion the round values. Do not ask the interviewer to design your schedule. Ask which evidence deserves the largest share of it:

• In coding, is a correct baseline the priority, or is a particular complexity target part of the contract?
• In system design, should you establish broad coverage before choosing a deep dive, or is one subsystem already the focus?
• In practical coding, does “done” mean runnable behavior, tests, API shape, user-facing polish, or a production discussion?
• In a project discussion, which decision or difficulty should receive the depth?

Then state a plan with an ending. For example:

“I will get a correct baseline working first. I want to begin tests with about ten minutes left, so if implementation runs long I will defer the optimization rather than leave the baseline untested.”

That sentence exposes the priority, the checkpoint, and the intended scope cut. It also lets the interviewer correct a mismatch at minute three instead of discovering it at minute thirty-seven.

Follow the rate limiter through the round

Return to the coding prompt: “Implement a rate limiter.” Before touching the editor, the candidate asks whether the limiter is single-node or distributed, what identifies a client, how the limit and interval are supplied, and whether burst smoothing is required. The interviewer wants a testable single-process implementation first and extensions afterward.

The candidate now has a 45-minute contract:

• Minutes 0–5: settle the behavior and work one example. By minute five, the method signature and the meaning of “allowed” should be unambiguous.
• Minutes 5–9: choose a fixed-window baseline, explain its burst boundary, and outline the state. The model is knowingly limited, not accidentally naive.
• Minutes 9–27: implement the main path. Routine typing can be quiet; state changes and risky choices should remain visible.
• Minutes 27–37: run normal, limit-reached, rollover, different-client, and boundary-timestamp cases. Repair what the tests expose.
• Minutes 37–45: state complexity and limits, then explain how token-bucket state or shared storage would change the design.

At minute 27, the fixed-window burst is not a surprise; it is a declared trade-off. The candidate can say:

“The baseline now enforces the contract we agreed on. Fixed windows permit a burst across the boundary, so I am keeping the implementation stable and using the remaining time to test it. I will then show where token-bucket state would replace the counter and window start.”

If the interviewer instead says burst smoothing is required, the contract has changed. The candidate should revise the plan openly:

“Then fixed window is not sufficient. I have eighteen minutes, so I will reuse the interface, replace the state with tokens and a refill timestamp, and validate one refill case. I will leave distributed coordination as a design discussion.”

Both responses manage time well. The difference comes from the requirement, not from a rule that one algorithm is always safer. Timeboxing preserves the space in which that judgment can become visible.

Five rounds have five different clocks

The rate-limiter schedule transfers the central habit—give the end of the answer a protected start time—but not its exact allocation. Each round has a different primary artifact and therefore a different shape.

Coding: 45 minutes

Use roughly the first five minutes to clarify the contract and boundary behavior, then another five to choose the model, invariant, and expected cost. Aim to have the main path present by minute 28. Spend the next nine minutes on examples and failure-prone edges. Use the final eight to repair, establish complexity, and discuss an optimization or limitation.

Minute 28 is a decision point, not an automatic stop. If the solution is far from runnable, reduce it to the smallest correct version. An unimplemented optimal idea is not stronger than a baseline the interviewer has watched you validate—unless the requested complexity makes that baseline invalid, in which case say so and seek the narrowest viable route to the required approach.

System design: 60 minutes

Spend about eight minutes on users, requirements, scale, success criteria, and non-goals. By minute fifteen, establish the API or event surface, core data, and important consistency expectations. Use the next ten minutes to draw the high-level flow, then commit roughly minutes 25–42 to the riskiest subsystem. Reserve minutes 42–53 for failures and operations, and the final seven for trade-offs, limitations, and evolution.

The dangerous drift is even coverage. A diagram with twelve equally shallow boxes proves little about architectural judgment. Once the main flow is legible, name the boundary that deserves depth:

“Fan-out and retry semantics carry the correctness risk, so I will stay there. I will treat analytics and admin tooling as follow-up surfaces unless you want a different priority.”

Practical coding: 60 minutes

Practical tasks are usually larger than the clock. Use the first seven minutes to define the deliverable, then about five to sketch interfaces, state, and a test plan. Protect minutes 12–38 for the core behavior and 38–48 for tests or executable checks. Use the next seven for the most consequential refactor or error path. In the final five, account for omitted persistence, concurrency, security, observability, deployment, or scale.

The important move happens before implementation:

“In this hour I can deliver the in-memory behavior with tests and an interface that admits persistence. I will leave storage and concurrency as explicit extensions unless you want either evaluated in code.”

Without that bargain, it is easy to polish a class while the interviewer waits for runnable behavior, or to build infrastructure while the core case remains untested.

Project deep dive: 45 minutes

Give purpose, pressure, your role, and outcome about five minutes. Use the next seven to establish the architecture and the constraints that existed when the decision was made. Let minutes 12–25 carry two or three consequential decisions, then spend about ten minutes on the migration, incident, conflict, or failure that tested them. Keep the last ten minutes for impact evidence, reflection, and interviewer follow-up.

Background is the easiest part to overrun. Compress company history and the org chart before compressing the decision. A useful frame is: “I will give the context briefly, then stay with the cutover decision because that is where the technical and organizational trade-off became visible.”

Behavioral: 45 minutes

If the round is broad, use the opening minutes to learn which themes the interviewer wants to cover. A first story can occupy minutes 5–15 and a second, chosen for different evidence, minutes 15–25. Preserve the next ten minutes for follow-up depth on conflict, mistakes, stakeholder handling, or results. Use minutes 35–42 for another example or values discussion and keep the close for candidate questions.

An initial story should usually reach its consequence within about three minutes so the interviewer can investigate it. The clock is not asking you to speak faster. It is asking you to remove background that does not change the choice, your ownership, or the result.

When the schedule breaks

Every useful schedule will be interrupted. The interviewer adds a constraint; a test fails; the chosen data model proves awkward; the most interesting follow-up arrives early. The purpose of reset points is to adapt without watching the clock every thirty seconds.

Pause after framing, around the middle of the round, with about ten minutes left, and immediately after a correction that changes the approach. Ask:

1. What evidence is already secure?
2. What evidence would still make the answer complete?
3. What can be cut without making the remaining claim dishonest?

The answer should produce a visible decision:

“The high-level flow and storage model are established. We have twelve minutes left, so I am dropping the secondary admin path and using that time on retry behavior and observability.”

Cut breadth before correctness. In coding, defer an optional optimization or second implementation, not the boundary tests. In system design, drop a secondary component before the risky deep dive. In practical coding, omit production hardening before the runnable core and error path. In project and behavioral answers, shorten chronology before the decision, consequence, and reflection.

A reset is not an apology. Nor should it become a negotiation over every next move. State what the clock and the evidence imply, allow the interviewer to redirect, and continue.

Rehearse the cut, not just the plan

Plans are easy to make when nothing has gone wrong. Practice the moment when the plan loses contact with the work.

For a 45-minute coding prompt, set an alarm at minute 27. Whatever is on the screen, say what is complete, choose the smallest defensible scope, and begin validation no later than minute 35. Review whether the cut preserved the problem contract or quietly weakened it.

For a system design prompt, set alarms at minutes 15, 30, 45, and 53. At each one, name the evidence already visible and the next risk worth spending time on. If all components are receiving equal attention at minute 30, choose one deep dive immediately.

For a project story, tell the same material in ninety seconds, three minutes, and eight minutes. Each version must retain the constraint, your decision, its trade-off, and the result. What disappears should mostly be setup.

The clock should not make the answer frantic. Used well, it makes the answer deliberate: the reader of the work can see what was chosen, what was proved, and what was left outside the boundary. The next complication is that the interviewer may redraw that boundary for you—with a hint, a correction, or a disagreement—and the schedule must survive the change.

Related reading

• Chapter 19: The Six-Phase Response Loop
• Chapter 21: Thinking Aloud Without Narrating Noise
• Chapter 23: Handling Hints, Corrections, and Disagreement
• Chapter 24: Recovering When Stuck