System Design Interview Prep: How to Run a Mock
By Rostyslav Myronenko, holder of 14 active AWS certifications.
. 6 min read
Most system design interview prep starts with reading: a book, a course, a list of questions. Reading teaches the building blocks. Using them out loud for 45 minutes while someone takes notes is a separate skill, and mock interviews are how you practise it.
This post has a four-week prep plan, how to run a mock system design interview with a friend or another candidate, the 1–10 rubric I use for the five signals, a sample scorecard, and what to do between mocks. The prompts are the widely published ones. None is taken from any company's interview loop.
Why solo practice stops working
Practising alone with a timer gets you a long way. The system design interview questions post sets out how: one prompt, 45 minutes, talking out loud, recorded, scored afterwards.
Then it levels off, for three reasons. Nobody interrupts you, so you never practise recovering your train of thought. Nobody pushes back on a choice, so you never have to defend it. And you score your own recording, which is kinder than any interviewer. A mock fixes all three by putting a second person in the interviewer's seat.
A four-week system design interview prep plan
This assumes an hour on weekday evenings and a longer session at the weekend.
- Week 1, building blocks. Go over load balancers, caches, queues, databases, partitioning and replication until you can explain each in two sentences and name its main trade-off. Learn the back-of-envelope numbers. Do one prompt with no timer, just to see the shape of a full answer.
- Week 2, solo and timed. Do two prompts against a 45-minute clock, out loud and recorded. Score each one with the rubric below. Note the lowest row.
- Week 3, first mocks. Do two mocks with someone in the interviewer's seat. Between them, work only on the lowest row.
- Week 4, unseen prompts. Do one or two mocks on prompts you haven't practised, because the real round won't use your favourite. Stop two days before the loop and rest.
How to run a mock system design interview
You need three things: a prompt the candidate hasn't seen, a 45-minute timer, and a blank whiteboard or drawing tool with no template. Peers can take turns, one mock each per evening.
Before the mock, the interviewer reads the prompt and writes down three things:
- The requirements to reveal only when the candidate asks. If the candidate never asks about scale, the interviewer never mentions it.
- One change to make around minute 25, such as ten times the traffic, a new region, or a hard latency target.
- The five rows of the scorecard, with space for notes under each.
During the mock, the interviewer answers questions, interrupts once or twice to ask "why that and not the alternative?", and makes the change at minute 25. Afterwards they take ten minutes to give each row a score and one sentence, and to name the single thing to fix first.
A 1–10 rubric for the five signals
These are the same five signals as on the coaching scorecard. Seven or more is strong, five or six is mixed, four or less is weak.
| Signal | Weak (around 3) | Mixed (around 6) | Strong (8 and up) |
|---|---|---|---|
| Requirements | Starts drawing before asking anything | Asks what the system does, skips latency, availability and scale | Pins down users, scale, latency, consistency and what's out of scope within five minutes |
| Data model | No entities or keys named | Names tables but not how they're queried | Names entities, access patterns and keys, and picks storage that fits the queries |
| Scaling story | No numbers at all | Estimates the load but never uses the numbers | Puts numbers on traffic and data, and says what breaks first as they grow |
| Trade-offs | Presents one option as the only one | Names alternatives when asked | Names the option not taken and its cost without being asked |
| Communication | Long silences, runs out of time | Talks throughout but never checks in | Drives the agenda, checks in, adapts to the change and finishes with a summary |
A sample scorecard
Here is how a scorecard might read after a mock of the news feed prompt, one of the twelve in the system design interview questions post. It's an example, not a real candidate.
Requirements were mixed: the candidate asked about followers, ordering and freshness, but never about latency. The data model was solid. The scaling story is the row to fix. There was no estimate of posts per second or followers per account, so the choice of fan-out on write was asserted rather than argued, and when the minute-25 change arrived ("one account has ten million followers") the design had nothing to adjust. Trade-offs only came up when prompted.
For the next mock, use a different prompt from the same family and do the arithmetic before drawing anything.
What to do between mocks
- Work on one row at a time, the lowest. Spreading effort across all five moves none of them.
- Drill that row in short reps. For the scaling story, do five-minute estimates on three prompts in an evening. For trade-offs, take a finished design and name the rejected option for every box.
- Redo a prompt a week later and watch only the row you've been fixing.
- Keep a small log of scores per row and per mock. The trend tells you when you're ready better than how the last mock felt.
Peer mock or paid mock
A peer mock costs nothing, and you should do several. Its limits are the interviewer's. A peer may not know what to probe, may not push back hard, and may score kindly because they'll be in the candidate's seat next.
A paid mock is worth it once you've done a few solo and peer rounds and the scores have stopped moving, or two to three weeks before a loop that matters. What you're paying for is an interviewer who has run the prompt many times, knows where candidates usually lose points, and writes the scores down honestly.
FAQ
How many mock interviews should I do before a system design interview?
Keep going until two things are true: the 45 minutes no longer surprises you, and your lowest-scoring signal has moved up. For most people that's a handful of mocks over two or three weeks, not one the night before.
Can I do a system design mock interview on my own?
Partly. A timed, recorded prompt that you score afterwards trains structure and pacing. It can't reproduce an interviewer who interrupts, pushes back or changes a requirement, and handling those moments is part of the communication grade.
What should the interviewer do in a mock?
Hold back the requirements until the candidate asks, interrupt once or twice, change one requirement halfway through, take notes against the five signals, and give the scores straight afterwards with one thing to fix.
How long does system design interview prep take?
As a rough guide, plan four weeks of an hour on weekday evenings and longer sessions at weekends if you already design systems at work. If the building blocks are new to you, add time before the mocks start.
A mock with someone in the interviewer's seat
If the loop is for a cloud role, the AWS solutions architect interview questions post covers the AWS scenario round that often comes with the design round.
In a coaching mock I play the interviewer: a published prompt, a 45-minute clock, one requirement that changes halfway, and a written scorecard on the five rows within a day. Sessions run on weekday evenings and at weekends, in English or Ukrainian.