What interviewers score
Companies word it differently, but most rubrics come down to the same seven skills. A strong round shows all of them; a common way to fail is to be strong on one and silent on the rest.
- Problem framing
- Turning a vague prompt into a short, agreed list of features and numbers, and spotting what makes the problem hard.
- Driving the round
- Keeping a structure, managing time, and choosing where to go deep, instead of waiting for the interviewer to steer.
- High-level design
- A complete design that covers every core feature, with clear request flows and storage that fits the access pattern.
- Technical depth
- Explaining how your components actually work when the questions move from what, to why, to what if, to how much.
- Trade-offs and judgment
- Naming the alternative you rejected, committing to a choice, saying what it costs, and keeping things simple.
- Scale and reliability
- Using numbers to make decisions, finding bottlenecks and single points of failure, handling retries, duplicates and hot keys.
- Communication
- Clear explanations, a whiteboard in step with what you say, taking hints well, and being honest about what you don't know.
How to spend 45 minutes
A structure keeps you from running out of time with half a design. These are the steps most interviewers expect, with a rough time budget for a 45-minute round.
- 0–8 min
Requirements
Name three or four core features and say what you are leaving out. Then pin the numbers: daily users, reads versus writes, latency, and whether data can be briefly stale. Find the one requirement that makes this problem hard.
- 8–12 min
Estimation
Only the numbers that change a decision: peak requests a second, storage over a few years, and the read to write ratio. Round hard and say what each number means for the design.
- 12–18 min
API and data model
A handful of endpoints for the core flows, the main tables or documents, and the key you look things up by. The access pattern picks the database, so say it out loud.
- 18–28 min
High-level design
Start simple and complete: client, API, service, storage, and a cache only if the numbers asked for it. Walk one write and one read through the boxes before adding anything.
- 28–40 min
Deep dives
Pick the hard part yourself, offer two options, choose one, and say what it costs. Expect follow-ups like what happens when this node dies, or when traffic is ten times higher.
- 40–45 min
Wrap-up and scorecard
Name what breaks first at 10x, how you would notice (the metric and the alert), and the one decision you would revisit with more time.
What changes from mid to senior to staff
The same question is asked at every level. What changes is how much you drive, how deep you go, and how early you think about failure.
| Skill | Mid-level | Senior | Staff+ |
|---|---|---|---|
| Who drives | You drive through the high-level design. The interviewer may lead the deep dives. | You drive most of the round and pick at least one deep dive yourself. | You drive nearly all of it. The interviewer is a peer you check in with. |
| How deep | You can explain how your core components work. | You hold up under what-if and how-much questions in about two areas. | You go deep in several areas, with detail that comes from running systems. |
| Trade-offs | You state trade-offs when asked and choose reasonably. | You volunteer trade-offs and commit to a decision. | You decide crisply, name the downsides of your own choices first, and cut complexity. |
| Failure and scale | You handle common failure questions when prompted. | You cover the main failure modes and monitoring without being asked. | You design for failure, rollout and SLOs from the start. |
The concepts to know first
You don't need to know every technology. You need to know about a dozen ideas well enough to explain how they work and what they cost. Start with these, in this order.
- Back-of-the-envelope estimationEvery round has numbers. Learn the five or six shortcuts that make them quick.
- Load balancingThe first box after the client in almost every design.
- Caching strategiesCache-aside, write-through, invalidation and stampedes come up in most read-heavy questions.
- SQL vs NoSQLYou will be asked why you picked your database. The access pattern is the answer.
- Database shardingWhat you do when the data or writes outgrow one machine, and what it breaks.
- ReplicationHow you survive a dead node and scale reads, and the lag that comes with it.
- Message queuesDecoupling, smoothing bursts, and the duplicates that every retry creates.
- IdempotencyThe answer to most what-if-it-retries questions, especially anything with money.
- CAP theoremThe vocabulary for what your system does during a network partition.
- Hot keysThe celebrity, the viral post, the flash sale. Interviewers love this follow-up.
Then the rest: all system design concepts, or the one-page system design cheat sheet.
A four-week practice plan
About an hour a day. Shorter if you already design systems at work, longer if you are new to it.
Week 1
The building blocks
Read the ten concepts above. For each one, write two sentences: when you would use it and what it costs. Do one classic question, like a URL shortener, slowly and with notes, to learn the shape of a round.
Week 2
The classics, timed
Four questions in 45 minutes each, out loud: a news feed, a chat app, a rate limiter and a ride-hailing app. After each one, compare your design with a model answer and write down the one thing you missed.
Week 3
Depth and failure
Pick questions where the hard part is correctness: payments, ticket booking, a job scheduler. Practice answering what if this node dies, what if the message is delivered twice, what if traffic is 10x.
Week 4
Mock rounds
Three or four full mock rounds with someone pushing back, a person or an AI interviewer. Focus on the feedback patterns across rounds, not any single score, and fix the weakest skill.
Good questions to start with
Mistakes that sink good engineers
- Drawing boxes before agreeing on what the system must do and how big it gets.
- Estimation as ritual: computing numbers that never change a decision.
- Naming technologies without saying why: Kafka, Redis and Cassandra are not a design.
- Designing for a billion users when the stated scale fits on one database.
- Spending half the round on one component and never finishing the core flows.
- Going quiet while thinking. The interviewer can only score what you say.
- Defending a choice after the interviewer showed it breaks, instead of adapting it.
Practice it out loud
Reading model answers feels productive, but the round tests something reading can't: thinking and talking at the same time, with someone interrupting. Do at least half your practice out loud and timed. SysRound runs that round for you: a voice AI interviewer that asks the follow-up questions, a shared whiteboard, and feedback on each of the seven skills at the end, with a model answer. It is an AI practice tool and can be wrong, so use it alongside practice with people.
Questions people ask
How long is a system design interview?
Usually 45 to 60 minutes, with a few minutes at the start for introductions and at the end for your questions. That leaves roughly 35 to 50 minutes of design, which is why pacing matters as much as knowledge.
Do mid-level engineers get system design interviews?
Often, yes. Many companies include a system design round from mid-level up. The question can be the same as for a senior candidate; the bar is different. Mid-level candidates are expected to reach a complete, sensible design, and the interviewer may lead the deep dives.
How many questions should I practice?
Quality beats count. Eight to twelve questions done properly, timed and out loud, with a review afterwards, prepares you better than skimming fifty write-ups. The concepts repeat across questions, so each new one goes faster.
Is there a right answer in system design?
No single right answer, but there are wrong ones: designs that miss a core requirement, ignore the stated scale, or fall over on a common failure. Interviewers score how you reach and defend your design, not whether it matches theirs.
Can I practice system design alone?
You can learn the concepts alone, but the round is a conversation, so practice it out loud. Talk through a question with a timer running, record yourself, or use a mock interviewer, human or AI, that asks follow-up questions and pushes back.