The usual advice for system design interviews is "practise with a partner". It's good advice, but partners are hard to schedule, and most preparation happens alone, in the evenings, with a whiteboard or a blank drawing tool. Solo practice can be very effective, as long as it looks like the interview rather than like reading.
This guide assumes you already have a structure for the round. If you don't, start with our 45-minute system design framework, which breaks the interview into requirements, estimates, API and data model, high-level design, deep dive, and pressure test. What follows is how to rehearse that structure by yourself.
Why reading isn't practice
Reading system design write-ups builds vocabulary: you learn what a consistent hash ring is, why queues decouple services, how a news feed might be built. That's necessary. But the interview doesn't test whether you recognise a good design. It tests whether you can produce one, out loud, under time pressure, from a vague prompt, while someone asks questions.
Those are different skills. The only way to build the second is to do it, many times.
A solo practice session
Each session takes about an hour: 45 minutes of design and 15 of review.
1. Pick a prompt you haven't designed before. Write it at the top of the page, exactly as an interviewer might say it: "Design a URL shortener." No extra detail. The vagueness is part of the exercise.
2. Start a 45-minute timer and work through the framework phases, keeping an eye on the clock. A rough checkpoint: requirements and estimates done by minute 12, high-level design by minute 25.
3. Talk out loud the whole time. This is the part that feels strange and matters most. Say your clarifying questions, then answer them yourself as a reasonable interviewer would ("let's say 100 million links, read-heavy"). Explain each component as you add it. If you only design silently, the interview will be the first time you design and explain at once.
4. Write the requirements down first, where you'd show them to an interviewer, and refer back to them as you design.
5. When the timer ends, stop, even if you're mid-thought. Where you got to is useful information.
6. Review for 15 minutes. This is where most of the learning happens (more on it below).
Picking prompts
Rotate across types of problem, because each stresses a different part of the toolkit:
| Type | Examples | What it practises |
|---|---|---|
| Read-heavy | URL shortener, news feed, product catalogue | Caching, replication, read paths |
| Write-heavy | Metrics pipeline, logging system, chat messages | Partitioning, queues, write throughput |
| Coordination | Rate limiter, booking system, distributed lock | Consistency, shared state, race conditions |
| Real-time | Chat, live location, notifications | Connections, fan-out, delivery guarantees |
| Large files | Photo sharing, file sync, video upload | Object storage, CDNs, chunked uploads |
The job description is the best source of prompts. A posting about payments suggests designing a ledger or a webhook delivery system; one about a consumer app with global users suggests a feed, notifications, or a multi-region read path. Design what the team actually builds.
Reviewing your own design
Without an interviewer, you're the reviewer. Go through these questions after each session, and write the answers down:
- Did every component trace back to a requirement? Cross out anything you can't justify.
- Did my estimates change any decision? If not, either the estimates were decoration or you didn't use them.
- Where did time go? Most people over-spend on the high-level design and run out of time for the deep dive.
- What did I go deep on? Was it the hardest part of this problem, or the part I was most comfortable with?
- Which tradeoffs did I name? Consistency versus availability, latency versus cost, simplicity versus scale. If you made a choice without naming its cost, note it.
- Where was I vague? Phrases like "and then we scale it" or "the service handles that" are where an interviewer would push.
Then compare your design with a write-up of the same problem, if you can find one. Not to copy it, but to spot considerations you didn't raise. Note them as focus areas for next time.
Simulating the pushback
The pressure test (the interviewer changing the requirements or attacking a weak spot) is the hardest phase to practise alone. Some ways to approximate it:
- Prepare a list of generic follow-ups and draw one at random when you finish the high-level design: "Traffic grows ten times", "the cache cluster goes down", "two requests for the same user arrive at once", "we need this in three regions", "how do you know it's unhealthy?"
- Attack your own design. For each component, ask what happens if it's slow, if it's down, or if it's receiving twice the traffic.
- Explain the design to someone non-technical and note every question they ask. "What happens if...?" questions from outsiders are often the same ones interviewers ask.
Rerun what went badly
A few days after a session that didn't go well, design the same prompt again from a blank page, with the timer. The second attempt is where the review turns into skill: you'll scope faster, use your estimates, and spend the saved time in the deep dive. Rerunning one weak prompt teaches more than starting three new ones.
How often, and for how long
Two or three sessions a week over a few weeks builds more fluency than a long weekend of cramming. Keep a simple log of each session: the prompt, where the time went, and two or three focus areas from the review. After a few weeks the log shows you what's improving and what needs attention.
Mix in some study between sessions, aimed at whatever the review turned up: a building block you explained vaguely, a tradeoff you didn't know how to weigh. If you also have a technical deep dive coming, much of the same material applies; see how to prepare for a project deep dive.
Watching the other side
One more solo exercise: watch a strong design being produced, and play the interviewer. In Hardmode's Switch seats mode you ask the questions and an AI candidate works through the design the way the best candidate for the job would, so you can see how it scopes, estimates, and handles your follow-ups. When you'd rather be the one at the whiteboard, the system design round gives you a scratchpad and an interviewer that does the pushing back for you.