System design interviews are the one round where showing up cold hurts the most. Coding rounds have a clear shape and you can grind LeetCode for them. Design rounds are open-ended, and if the first ten minutes of your onsite are also the first ten minutes your brain has spent in design mode all day, it shows.
You can't learn system design in 30 minutes. But you can warm up the parts you already know so they're loaded and ready. That's all this is. A warm-up, not a cram session.
Here's how I'd spend the half hour before I walk in or join the call.
Minutes 0-5: load your default template
Before anything else, write your scaffold from memory on a scratchpad. Not a specific system, just the empty structure you'll reach for no matter what they ask:
- Clarify requirements and scope
- Estimate scale (users, reads, writes, data size)
- Define the API
- Sketch the high-level diagram
- Pick the data model and storage
- Identify bottlenecks and scale them
- Discuss tradeoffs
If you can't write that from memory in five minutes, that's the most useful thing you'll learn this morning. The template is your safety net. When you're nervous and the prompt is vague, you fall back to the structure. You don't want to be inventing your approach live.
Minutes 5-10: re-anchor your numbers
You don't need to memorize a latency chart, but you should be able to ball-park a few things without freezing. Say them out loud:
- A read from memory is fast, a read from SSD is slower, a read across a data center is much slower.
- A single commodity database handles thousands of simple queries per second, not millions.
- A day has about 86,400 seconds. So 1 million requests a day is roughly 12 per second. 1 billion a day is roughly 12,000 per second.
That last one matters more than people expect. Half of "estimate the scale" is just dividing a daily number by 86,400 without panicking. Practice that one conversion and a lot of the math gets calmer.
Minutes 10-20: run one full problem in your head
Pick a problem you've done before. A URL shortener, a news feed, a rate limiter, something with a known shape. Don't pick something new. The point is to feel the motion of going end to end, not to solve a hard puzzle.
Talk through it out loud if you can. Requirements, scale, API, diagram, storage, bottlenecks. Time-box it to ten minutes so you feel the pace. Where do reads dominate? Where do you add a cache? Where does a single database stop being enough and you reach for a queue or a shard?
The goal is to catch yourself narrating. Interviewers score you on how you think, and thinking out loud is a skill that gets rusty if you only practiced it weeks ago. Mock interviews help here because they force the talking, but even a solo run on a familiar problem the morning of gets your mouth moving.
Minutes 20-25: rehearse your clarifying questions
The most common way strong engineers lose this round is jumping to a solution before pinning down what they're building. So prep the openers you'll always ask:
- Who uses this and what's the main thing they do?
- What's the rough scale, and is it read-heavy or write-heavy?
- What matters more here, consistency or availability?
- Any hard constraints I should design around?
Have these ready so the first move you make is asking, not drawing. It buys you thinking time and it signals seniority. Nobody good starts drawing boxes in the first minute.
Minutes 25-30: settle down
Stop studying. Close the laptop or put the notes away. Cramming a new pattern five minutes before the interview just adds noise you can't use.
Do something boring instead. Get water. Walk to the room. Read your scaffold one last time and trust it. You want to walk in with a calm, loaded template, not a head full of half-remembered architecture diagrams.
What this won't fix
If you've never done a full design problem before, 30 minutes won't save you. This warm-up assumes you've put in the reps over the prior weeks. It loads what's there. It doesn't install what isn't.
So the real prep is the practice you do before the morning of. Run mock design problems out loud, get used to narrating tradeoffs, and build the muscle memory for the scaffold. Then on the day, you just warm it back up.
Thirty minutes, one familiar problem, your template from memory, and your clarifying questions ready. Walk in warm.