Free lesson · Frontend System Design

Forty-five minutes is less time than you think

Easy10 min readfrontendsystem-design

Let me describe a failure I've watched happen more times than I can count, including, once, to me.

The prompt lands. You're prepared, you've got RADIO in your pocket, you start on Requirements - and Requirements is the fun part, because you get to ask smart questions and the interviewer nods approvingly. So you keep asking. You explore edge cases. You discuss whether the feed needs offline support, and that's interesting, so you go a few layers into service workers, and the interviewer is engaged, and it all feels like it's going great. Then you glance at the clock and twenty-two minutes are gone and you have not drawn a single component. Panic arrives. You rush through Architecture, skip Data Model entirely, hand-wave the API, and reach Optimizations - the phase that actually wins the round - with four minutes left and nothing but breathless bullet points to offer.

You didn't fail because you lacked knowledge. You failed because you had no budget, and a system design round without a time budget is a road trip without a fuel gauge. You feel fine right up until you're stranded.

This lesson is the fuel gauge.

The budget, mapped to RADIO

Here's a working allocation for a 45-minute round. It is not sacred - adjust to the prompt - but internalize it so your internal clock is calibrated and you feel when you're overspending.

gantt
    title 45-Minute Round Budget
    dateFormat mm
    axisFormat %M
    section Phases
    Requirements      :r, 00, 7m
    Architecture      :a, after r, 9m
    Data Model        :d, after a, 6m
    Interface / API   :i, after d, 7m
    Optimizations     :o, after i, 13m
    Buffer / Wrap     :b, after o, 3m

This is a Gantt chart titled "45-Minute Round Budget," laying the six phases end to end across the available time. Requirements takes the first seven minutes. Architecture follows with nine minutes. Data Model takes six. Interface and API takes seven. Optimizations is the longest single block at thirteen minutes. A final three-minute buffer closes the round for a summary and the interviewer's questions. The phases are sequential, with Optimizations claiming the largest share.

Look at where the time concentrates: Optimizations gets the most, and Requirements - despite being where everyone overspends - gets only seven minutes. Seven minutes is enough to scope a problem if you ask the right questions instead of all possible questions. The discipline is to extract the constraints that change your design (device, network, accessibility, scale of interaction) and stop. You are not trying to achieve perfect understanding. You are trying to bound the problem well enough to start, knowing you can loop back if you discover a gap.

Important: The clock is not your enemy - uneven spending is. A candidate who spends 7 minutes on every phase and lands all of RADIO beats a candidate who spends 20 brilliant minutes on Requirements and never reaches Optimizations. Completeness across the framework beats depth in one phase, every time, because the round is scored on breadth and depth, and you can't show breadth if you never get there.

The four ways people burn the clock

Every time-management failure I've seen is one of these four. Learn to feel them happening in real time, because the cost isn't the minute you're in - it's the phase you'll have to skip later to make up for it.

1. Rabbit-holing

You hit an interesting sub-problem and follow it down. "How exactly does the service worker cache invalidation work?" is a great question - in the Optimizations phase, with time to spare. In the Requirements phase, it's a rabbit hole that's about to cost you the architecture. The tell: you're three "and then" steps deep on a detail nobody asked you to detail yet.

The recovery: catch yourself and say it out loud. "I could go deeper on cache invalidation here, but I want to make sure I get through the architecture first - let me park that and come back to it in optimizations." Naming it turns a flaw into a signal of self-awareness.

2. Gold-plating

This is rabbit-holing's cousin: over-engineering a part that doesn't need it. You design a beautiful, fully generic, infinitely-configurable component system for what was supposed to be a simple list. You're solving for a scale and flexibility the requirements never asked for. Senior engineers right-size; gold-plating signals you can't tell what matters from what's merely possible.

The recovery: tie every elaboration back to a stated requirement. If you can't name the requirement that justifies the complexity, drop it.

3. Silence

You go quiet to think, and you draw in silence for ninety seconds. To you it feels like concentration. To the interviewer - who cannot see inside your head - it's a black box. They don't know if you're being brilliant or you're stuck, and the uncertainty itself counts against you, because the round is partly a test of whether you communicate while you work.

The recovery: narrate continuously, even your uncertainty. "I'm weighing two options for the data layer right now - give me a second to think about which fits the offline requirement better." That sentence buys you the same thinking time without the black box.

4. Freezing on the blank moment

The interviewer asks something you didn't prepare for - "what happens if two requests come back out of order?" - and your mind goes white. The clock keeps draining while you sit in the void. This is the most expensive failure because the silence and the unanswered question both cost you.

The recovery: have a script for the blank moment. We have a whole framework for this later (Arun's Stuck Protocol), but the 10-second version: say what you do know, out loud, to buy momentum. "Out-of-order responses - okay, the risk is a stale response overwriting a fresh one. So I need a way to tell which response is current. Let me think... I could tag each request with the query it belongs to and discard any response that doesn't match the current query." You just reasoned your way out of the freeze in front of them, which is exactly the skill they're testing.

stateDiagram-v2
    [*] --> OnTrack
    OnTrack --> RabbitHole: chasing a detail too early
    OnTrack --> GoldPlating: over-building
    OnTrack --> Silence: thinking without narrating
    OnTrack --> Freeze: hit an unknown
    RabbitHole --> OnTrack: "let me park that"
    GoldPlating --> OnTrack: tie back to a requirement
    Silence --> OnTrack: narrate the tradeoff aloud
    Freeze --> OnTrack: say what you know, reason out
    OnTrack --> [*]: round complete

This is a state diagram showing how a candidate moves between being on-track and the four time-burning failure states. From On Track, you can slip into Rabbit Hole by chasing a detail too early, Gold Plating by over-building, Silence by thinking without narrating, or Freeze by hitting an unknown. Each failure state has a labeled path back to On Track: parking the detail for the rabbit hole, tying work back to a requirement for gold plating, narrating the tradeoff aloud for silence, and saying what you know to reason out of a freeze. The goal state is reaching round complete from On Track.

How to recover when you're already behind

Sometimes you look up and you're simply behind - twenty-five minutes gone, only at Architecture. Do not pretend it isn't happening and do not silently rush. Triage out loud:

"I'm conscious of time, so I'm going to move faster from here. I'll sketch the data model briefly, define the key part of the API, and then spend my remaining time on the two optimizations that matter most for these requirements - perceived performance and accessibility - and name the rest as things I'd handle in production."

That sentence is gold, and here's why: it converts being behind into demonstrated prioritization. The interviewer now sees someone who, under time pressure, correctly identifies what matters and protects it. That is exactly the on-the-job behavior they're hiring for - because real deadlines are exactly this, a forced choice about where the remaining time goes. You've turned a stumble into evidence.

Tip: Keep a literal running clock in your head tied to checkpoints, not a stopwatch you stare at. The two checkpoints that matter: "Am I done with Requirements by ~7 minutes?" and "Am I into Optimizations by ~29 minutes?" If you blow the first checkpoint, tighten Architecture. If you're at risk of blowing the second, start triaging immediately. Those two checkpoints alone prevent the most common catastrophic outcome - never reaching Optimizations.

When the round isn't 45 minutes

Not every round gives you 45 minutes - some companies run 30-minute frontend rounds, and a few stretch to 60. The budget isn't a fixed table to memorize; it's a ratio to scale. Whatever the length, Requirements stays around 15% and Optimizations stays the largest slice at roughly a third. In a 30-minute round that means about 5 minutes scoping and roughly 9 on optimizations - which forces even harder prioritization, so the gaps-naming move from the last lesson becomes essential rather than optional. The instinct to protect is always the same: guard the back of the round. The shorter the round, the more ruthless you have to be about not overspending early, because there's simply less slack to recover from a Requirements overrun. If you've internalized the ratio rather than the literal minutes, you adapt on the fly when the interviewer says "we've actually only got half an hour."

The asymmetry you must protect

If you remember one thing from this lesson, make it this: the front of the round is forgiving and the back of the round is not. Spending an extra two minutes in Requirements feels harmless and often is harmless - the interviewer is engaged, the conversation flows. But that debt isn't free. It's a loan against Optimizations, and Optimizations is where the round is scored most heavily. Every minute you overspend early is a minute stolen from the phase that decides the outcome.

So when in doubt, move on. An imperfect-but-complete pass through RADIO, with real depth in Optimizations, beats a gorgeous, thorough, half-finished answer that dies at the API phase. Interviewers have seen a hundred candidates who never reached the interesting part. Be the one who budgeted for it.

Interview: Make your time-awareness visible. Saying "I'm watching the clock, so let me move to X" two or three times across the round is not a weakness - it's a senior tell. It shows you treat the 45 minutes as the constraint it is, that you can prioritize under pressure, and that you won't be the engineer who gold-plates the easy 80% and ships the hard 20% late. Time-awareness spoken aloud is itself part of what's being scored.

A worked recovery: watch someone climb out

Abstract advice about "triaging out loud" is easy to nod at and hard to actually do when your pulse is up. So let me narrate a real-shaped recovery, the way it sounds in the room, so you have a model to imitate.

The prompt was "design a commenting system with nested replies." The candidate - let's say it's you - got fascinated by the data model for arbitrarily-deep nesting, which is genuinely interesting, and spent a luxurious thirteen minutes on it. You look up. It's 26 minutes in. You're at the end of Data Model, you haven't touched the API, and you haven't started Optimizations, where this round will be scored. Your stomach drops.

Here's the wrong move, the one most people make: pretend it's fine, speed up silently, and try to cram all of RADIO into the remaining time at double speed. The result is a blur, you sound flustered, and the interviewer watches you panic.

Here's the recovery. You take one breath and you say it out loud:

"I want to flag my own time here - I went deep on the nesting model because it's the interesting part, but I've got about eighteen minutes left and I haven't covered the API or optimizations yet. So I'm going to make a deliberate call: I'll define the comment-fetching API quickly, then spend the bulk of my remaining time on the two optimizations that matter most for a comment thread - rendering performance for deeply nested trees, and the real-time update strategy when new replies arrive. I'll name caching and accessibility as things I'd handle but won't detail unless you want me to."

Read that again and notice everything it accomplishes in one paragraph. You acknowledged the overspend before the interviewer had to - which reads as self-awareness, not weakness. You named the remaining budget, which shows you're tracking time. You chose the two highest-impact areas for this specific problem, which is prioritization under pressure. And you pre-named the gaps, which is the senior signal from the framework lesson. You converted a stumble into a live demonstration of exactly the judgment the round exists to measure.

That's the whole trick: the recovery is not damage control, it's evidence. A round where you budget perfectly and never stumble shows competence. A round where you stumble and then visibly, calmly re-prioritize out loud shows competence and resilience - and resilience is harder to fake and more valuable on a team, because real projects slip and the question is always what you do when they do.

Tip: Practice the recovery sentence until it's reflexive, the same way you'd practice the framework. Mock yourself into the behind-schedule situation on purpose during prep - start a timer, deliberately rabbit-hole, then practice climbing out with the triage sentence. The first time you say it for real should not be the first time you've ever said it. A recovery you've rehearsed sounds composed; one you're improvising sounds like panic.

What you should carry out of this lesson

A 45-minute round needs a budget mapped to RADIO, with the heaviest spend in Optimizations and a disciplined cap on Requirements. The four failure modes - rabbit-holing, gold-plating, silence, and freezing - each have a verbal recovery that converts the stumble into a signal, because the recovery itself demonstrates self-awareness, prioritization, or grace under pressure. And when you fall behind, you triage out loud, which turns "I ran out of time" into "I correctly protected what mattered."

You now have the three things the rest of the course assumes: you know what's being tested, you have a framework with the gaps-naming overlay, and you have a time budget with recovery scripts. The only honest way to prove all three click together is to run them on a real problem, start to finish, watching the clock. So that's exactly what we do next - a complete RADIO pass on autocomplete search, the most-asked frontend design question there is, narrated the way you'd narrate it in the room.

Back to Frontend System Design