# System Design Mock Interviews: A 45-Minute Drill, a Scoring Rubric and a Feedback Loop (2026)
> A mock interview only helps if it is timed, scored and followed by a fix. This lesson gives the 45-minute protocol, an interviewer script, a 1 to 4 rubric with level anchors, a debrief and error log, and solo and LLM modes.
*Source: https://www.infowok.com/system-design-mock-interview-practice-guide/ · Sukhveer Kaur · Published October 24, 2026*
---
Reading a solution feels like learning. The room asks for something else: produce a design from a blank board, on a clock, while someone interrupts. Reading rehearses none of that.
A mock interview rehearses exactly that skill. It also fails in quiet ways: a kind friend who scores everything high, a favourite prompt repeated until it is memorised, a solo run nobody checks. This lesson gives a protocol, a rubric that resists inflation, and a loop that turns each mock into a fix. The [sibling prep-plan lesson](/system-design-interview-prep-plan-2026/) turns it into a calendar.
- [The interview framework](/system-design-interview-framework-2026/) and [back-of-envelope estimation](/back-of-envelope-estimation-primer/).
- Two or three Module 4 problems read once, and the [building blocks](/system-design-building-blocks/) map. Mocking before that is covered under "How the Method Fails".
Name the six steps of the round and the minutes each gets. Requirements 5, entities 2, API 5, high-level design 13, deep dives 13, wrap-up 5, two spare. The mock below uses exactly this clock.
- A mock beats rereading because it forces you to produce the answer from memory, and the research behind that has limits you should know.
- Run every mock on the same 45-minute clock with a fixed interviewer script, so scores are comparable across weeks.
- Score seven dimensions from 1 to 4, each with a quoted piece of evidence. A score with no evidence is a guess.
- The mock is half the work. A 10-minute debrief, an error log and a redo of the weakest section turn a score into a fix.
- Solo and LLM mocks are good for volume and weak at honesty. Pair them with a human scorer.
Run a scored 45-minute mock alone, with a partner or with an LLM, write the debrief into an error log, and decide from the rubric whether you are ready for your target level.
## Why Does a Mock Beat Another Read-Through?
Two research results support the method. Both have limits.
In a 2006 study, students read prose passages, then took free-recall tests without feedback or restudied the same passages ([Roediger and Karpicke](https://doi.org/10.1111/j.1467-9280.2006.01693.x)):
- Five minutes later, restudying gave better recall.
- Two days and one week later, the tested students remembered substantially more.
- Restudying had made students more confident they would remember.
Pulling an answer out of memory is the testing effect, and a mock does exactly that. The study used students and prose, not engineers and designs.
A 1993 paper links differences among elite performers to the amount of deliberate practice ([Ericsson, Krampe and Tesch-Römer](https://doi.org/10.1037/0033-295X.100.3.363)). A 2019 replication of its violin study did not reproduce the main result: practice explained about 26% of the performance variance, against 48% in the original ([Macnamara and Maitra](https://doi.org/10.1098/rsos.190327)).
**Practising the real task beats rereading, and practice volume alone is not enough.** The feedback, error log and redo steps below are this course's design (judgement), not findings from those papers.
## The 45-Minute Protocol
Every mock uses the framework's clock, so a score today compares with a score next week. The box lengths are this course's recommendation. A real loop may differ: Amazon's page for SDE II candidates describes four 55-minute interviews ([Amazon](https://amazon.jobs/content/en/how-we-hire/sde-ii-interview-prep)). If yours is 55, keep the table and give the extra ten minutes to the deep dives. Microsoft's hiring tips tell candidates to ask clarifying questions and plan before implementing ([Microsoft](https://careers.microsoft.com/v2/global/en/hiring-tips/technical-interviewing)), which is the first half of this clock.
| Clock | Step | Interviewer does |
|---|---|---|
| 0:00 | Prompt | Reads it once |
| 0:01 | Requirements, 5 min | Answers only what is asked |
| 0:06 | Entities, 2 min | Silent |
| 0:08 | API, 5 min | Checks coverage |
| 0:13 | High-level design, 13 min | Nudges if stuck |
| 0:26 | Deep dives, 13 min | Opens the probe bank |
| 0:39 | Wrap-up, 5 min | Asks for failures |
| 0:44 | Candidate questions | Stops at 0:45 |
Three roles:
- The **candidate** draws and talks.
- The **interviewer** follows the script below and says as little as possible.
- The **observer** is optional. They hold the clock, tally nudges and fill in the rubric silently. With only two people, the interviewer scores afterwards from notes.
### The interviewer script
Opening line: "Design a URL shortener. You have 45 minutes. Ask me questions, talk while you draw, and I may interrupt." Before the session, write a one-page answer sheet with every number you will give if asked (writes per month, read ratio, latency target).
Withhold these until the candidate asks or earns them:
- Scale numbers, so asking for them is visible.
- Which deep dive to take. Mid-level candidates may be offered a choice; senior candidates choose.
- Any verdict on the design. Say "okay, go on", never "good" or "that's wrong".
Nudge in four steps and tally each one: wait 20 seconds (an assumption), then ask "which requirement does this serve?", then give a hint ("consider a cache miss"), then name the direction. A design reached only at step three or four scores 2 at most on that dimension.
### The probe bank for the deep dive
| Depth | Probes |
|---|---|
| Mid | The database is down: what happens? Why this store? How many requests a second does it handle? |
| Senior | Traffic grows tenfold: what breaks first? Two retries of one write: what happens? What consistency do you give up, and why? |
| Staff | Roll it out with no downtime: how? What does it cost per million requests, and what would you cut? A region is lost: what is the recovery target? |
For prompt-specific probes use the follow-ups companions listed in the prompt bank below. Ask three to four probes, not all of them. Depth on two beats a survey of ten.
## The Scoring Rubric
Each dimension scores 1 to 4. A 1 means missing, wrong, or reached only after a direct hint. A 2 matches the mid-level anchor, a 3 the senior anchor and a 4 the staff anchor. Score the lowest anchor you fully hit, never a half point, and write down one quote or timestamp as evidence.
| Dimension | Anchors |
|---|---|
| Requirements and scope | **2** asks a few questions, lists features
**3** quantifies qualities, states what is out of scope
**4** links each requirement to a later design choice |
| Estimation | **2** correct when prompted
**3** estimates only where a decision hangs on it, with units
**4** uses a number to reject an option, separates peak from average |
| API and data model | **2** endpoints cover the requirements
**3** names keys, access patterns, pagination, idempotent writes
**4** justifies the store against alternatives |
| High-level design | **2** works end to end
**3** every box exists because an endpoint needs it
**4** separates read and write paths, names the critical path |
| Deep dive | **2** correct on one component when led
**3** picks the parts the requirements stress, compares options with costs
**4** handles the hard case (hot key, resharding) and names what to measure |
| Trade-offs and failure modes | **2** names a trade-off when asked
**3** ends each deep dive with a cost, says what fails per component
**4** raises multi-region, rollout, abuse and cost unprompted |
| Communication | **2** explains when asked, some long silences
**3** narrates, checks in, recovers from pushback
**4** steers the conversation and summarises decisions |
**Total** the seven scores: 7 to 28. Then apply the readiness test below. Evidence matters because confidence is a poor guide: in the testing study above, the students who reread felt surer and remembered less.
### What does "ready" look like?
This is judgement, not an employer standard. No company publishes numeric cut-offs that this lesson found.
| Target | Ready when, three mocks in a row on different prompts | Total |
|---|---|---|
| Mid | All seven at 2 or more | 14+ |
| Senior | Five at 3 or more, none at 1, 2 nudges or fewer | 19+ |
| Staff | Three at 4, the rest at 3 | 24+ |
Check the arithmetic: seven 2s make 14; five 3s and two 2s make 19; three 4s and four 3s make 24. At least two of the three mocks should be scored by someone other than you.
## The Feedback Loop
A mock just ended. Which is the better next hour: another full mock on a new prompt, or ten minutes of debrief plus a redo of the weakest section? Decide, then read on.
The second. A new mock before the debrief repeats the gap and teaches nothing. The order is debrief, log, redo, then re-test.
### The 10-minute debrief
| Minutes | Who | What |
|---|---|---|
| 0 to 2 | Candidate | Scores themselves first, before hearing anything |
| 2 to 5 | Interviewer | Reads their scores, each with one quote and a timestamp |
| 5 to 8 | Both | Pick the two lowest scores, and any dimension where the two scorers differ by 2 |
| 8 to 10 | Candidate | Writes the log lines and books the redo |
Feedback speaks in evidence: "at 0:19 you chose a queue without saying why", not "you seemed unsure".
### The error log
One entry per gap. The root cause decides the fix, so name it:
```text
Date: 2026-10-24
Prompt: URL shortener
Dimension: estimation
What happened:
sized storage, never used it
Root cause:
knowledge | process | delivery
Fix:
redo estimation, 15 min
Redo by: 2026-10-26
Re-test: rate limiter, 10-31
Status: open
```
Knowledge gaps send you back to a lesson. Process gaps (you knew it and skipped it) need a checklist on the board. Delivery gaps (you knew it and said it badly) need speaking practice.
### Redo and re-test
**Redo rule:** repeat only the section that held the lowest score, for 10 to 15 minutes, within about 48 hours (an assumption, so the gap is still fresh). **Re-test rule:** a gap is closed when its dimension meets the target on two consecutive mocks with different prompts. Two, because one good score on the redone prompt proves memory, not skill.
## Practising Alone
A solo mock gives pacing and structure practice, with no one to withhold information.
1. Set a timer with alarms at 0:06, 0:13, 0:26, 0:39 and 0:44.
2. Draw on the tool you will use in the room. Speak every thought aloud.
3. Record screen and audio. Write the answers to your own clarifying questions on paper before you start, from the prompt-bank lesson.
4. Review the recording once at normal speed, pausing at each section boundary.
Score from the recording, not from memory. Review checklist:
```text
[ ] Requirements done by 0:06
[ ] One number per quality
[ ] Every box tied to an endpoint
[ ] One estimate changed a choice
[ ] A cost said per deep dive
[ ] A failure said per component
[ ] Longest silence under 20 s
[ ] No 3-minute monologue
```
A solo run cannot test reactions to interruptions or new facts. Cover that with a partner or an LLM.
## Finding Partners and Asking for the Rubric
Good sources, none needing a platform:
- Colleagues who have run interviews.
- A study group of three that rotates candidate, interviewer and observer.
- Local engineering meetups.
- An employer or university alumni mock programme, or a mentor.
Before each session send three things: the rubric, the clock, and the rule that the interviewer withholds numbers. Without the rubric, a friendly partner gives kind, vague feedback. Play the interviewer yourself for about one session in three (judgement): marking someone else against the anchors shows you what a 3 and a 4 sound like. Do not trade questions you agreed to keep confidential with an employer.
## Using an LLM as the Interviewer
An LLM gives unlimited volume at any hour. Use it for probes and pacing, not as the final judge. Paste this prompt with the rubric:
```text
Act as a system design
interviewer for a senior role.
Prompt: design a URL shortener.
Rules:
- Say nothing until I speak.
- Answer in one or two lines.
- Never volunteer numbers.
- Do not praise or correct.
- After each section, ask
one probe at my level.
- Interrupt if three minutes
pass with no trade-off.
When I say "debrief":
- Score 1-4 per rubric below,
each with a quote from me.
- No quote means score 1.
- List my claims that may be
wrong. Do not fix them.
```
Where it fails, and the guard for each (judgement):
| Failure | Guard |
|---|---|
| Flattering scores. Models trained on human preferences tend toward agreement ([Sharma et al.](https://arxiv.org/abs/2310.13548)) | Demand a quote per score; compare with your own score |
| Judge biases: the LLM-as-judge study names position, verbosity and self-enhancement bias ([Zheng et al.](https://arxiv.org/abs/2306.05685)) | Score yourself first; use a human for every third mock |
| Invented facts and numbers | Check every figure against the lessons |
| No pushback on a weak trade-off | Ask for the strongest objection to your choice |
| Cannot keep time | Run the timer yourself |
The [LLM-judge study](https://arxiv.org/abs/2306.05685) found strong judges matched human preferences on chat answers. It did not test system design interviews. Whether an assistant is allowed in a real round varies by company, so see the [framework lesson](/system-design-interview-framework-2026/) and ask your recruiter.
## The Practice-Prompt Bank
Ordered easy to hard, by this course's judgement of how many moving parts each has. "Study first" is the problem lesson; the companion holds the follow-up probes.
| Prompt | Deep dives to expect | Follow-ups |
|---|---|---|
| [URL shortener](/design-a-url-shortener/) | code generation, cached reads, 301 vs 302 | [companion](/design-a-url-shortener-follow-ups/) |
| [Rate limiter](/design-a-rate-limiter/) | algorithm, shared counters, limiter outage | [companion](/design-a-rate-limiter-follow-ups/) |
| [Typeahead search](/design-a-typeahead-search/) | prefix lookup, freshness, table scale | [companion](/design-a-typeahead-search-follow-ups/) |
| [Notification service](/design-a-notification-service/) | store first, retries, urgent vs bulk | [companion](/design-a-notification-service-follow-ups/) |
| [Chat system](/design-a-chat-system/) | delivery path, ordering, offline devices | [companion](/design-a-chat-system-follow-ups/) |
| [News feed](/design-a-news-feed/) | push vs pull, feed storage, ranking | none yet |
| [File storage](/design-a-file-storage-service/) | resumable uploads, dedupe, sync | [companion](/design-a-file-storage-service-follow-ups/) |
| [Web crawler](/design-a-web-crawler/) | URL frontier, dedupe, crash recovery | [companion](/design-a-web-crawler-follow-ups/) |
| [Video streaming](/design-a-video-streaming-service/) | adaptive bitrate, transcoding, delivery | [companion](/design-a-video-streaming-service-follow-ups/) |
| [Ride sharing](/design-a-ride-sharing-service/) | nearby search, matching, partitions | [companion](/design-a-ride-sharing-service-follow-ups/) |
| [LLM system](/llm-system-design-interview-2026/) | serving cost, caching, evaluation | [companion](/llm-system-design-interview-2026-follow-ups/) |
Draw prompts at random once you pass stage two below. For a twist, add one constraint from [failure modes](/failure-modes-and-resilience-patterns/) or from [rate limiting](/rate-limiting-explained/), such as abuse or a region loss.
## Cadence and Progression
Assume 8 to 12 mocks in total, two to three a week for three to four weeks. This is a planning assumption, not a research result. The [prep-plan lesson](/system-design-interview-prep-plan-2026/) sets the actual schedule. What matters here is the order:
| Stage | Rule | Move on when |
|---|---|---|
| 1. Open book | Notes open, no clock | You can recite the step order |
| 2. Timed | Clock, notes closed, a prompt you studied | No section runs 2+ minutes over, twice |
| 3. Unfamiliar | Random prompt, plus one twist | Senior anchors on five dimensions |
| 4. Full-loop day | Two or three mocks with breaks, different interviewers | Scores hold on the last one |
A full loop also has coding and behavioural rounds, which this guide does not cover.
## How the Method Fails
| Failure | Sign | Fix |
|---|---|---|
| Mocking before the building blocks | Scores stuck at 1 in design and deep dive | Study [caching](/caching-strategies/), [sharding](/database-sharding-and-replication-explained/) first; use stage 1 |
| Only favourite prompts | Scores climb on three prompts only | Random draw; one in three prompts new |
| Rubric inflation | Your total runs 3+ above a partner's | Quote per score; lowest-anchor rule; external scorer |
| Memorised solutions | The design collapses at the first twist | Stage 3 twists and probes |
| An uncalibrated partner | Always kind, or always harsh | Share the rubric; swap roles |
| Mocks instead of study | Same knowledge gap logged three times | Go back to the lesson, then redo |
**When not to use it:** before you have read the framework and the building blocks; in the last day or two before a real round, when rest likely helps more than a new gap (judgement); and for coding or object-oriented design rounds, which need other drills.
Scoring yourself generously and skipping the debrief. Totals rise, the real score does not, and the first honest feedback arrives in the actual interview.
## Try It: A Scored Solo Mock on the URL Shortener
Do not read [the URL shortener lesson](/design-a-url-shortener/) first. Assume 100 million new links a month, 100 reads per write and redirects under 100 ms, and answer your own questions with those. Then:
1. Run the 45-minute protocol alone: timer, aloud, recorded.
2. Review the recording with the checklist. Score the seven dimensions with a quote each.
3. Total them, pick the two lowest, write two error-log entries, and book a redo.
If you cannot find a quote for a score, it is a 1. Score first, then compare with the lesson's "What Each Level Should Show" table.
An imagined run, not data:
| Dimension | Score | Evidence |
|---|---|---|
| Requirements | 3 | 0:04 "out of scope: login" |
| Estimation | 2 | Sized storage, unused |
| API and data | 3 | Named code as key |
| High-level | 3 | Boxes tied to endpoints |
| Deep dive | 2 | Cache only, no hot key |
| Trade-offs | 2 | Cost named once |
| Communication | 3 | Silences under 20 s |
Total: 3+2+3+3+2+2+3 = 18. Senior needs 19, so this run falls one short. Weakest: estimation, deep dive, trade-offs.
Log entry: estimation, root cause process, fix "state the decision the number changes". Redo the 13-minute deep dive within 48 hours, then re-test on the rate limiter.
## What Each Level Should Show in Practice
| Level | Mock practice looks like |
|---|---|
| Mid-level | Finishes the clock with a working design; all dimensions at 2; needs a debrief partner |
| Senior | Drives deep dives; five dimensions at 3; keeps a log and closes gaps in two mocks |
| Staff | Raises cost, rollout and failure unprompted; designs the drill, calibrates others, interviews peers |
Your own score is the only measure of calibration. If you hear theirs first, you adjust toward it and the gap between the two scorers, which is the most useful signal, disappears.
Not another mock. Name the root cause in the log: knowledge sends you to a lesson, process to a checklist, delivery to speaking practice. Redo the section, then re-test on a new prompt.
Treat it as flattery until proven otherwise: demand a quote per score, score yourself first, and ask for the strongest objection to one of your choices. Models trained on human preference tend to agree.
Algorithm choice, shared counters and what happens when the limiter is down. Study the [rate limiter lesson](/design-a-rate-limiter/), then draw probes from its companion.
After your next debrief, close the notes and write the two top gaps from memory the next morning. If you cannot, the fix is not yet stored. That small recall test is the testing effect applied to your own error log.
## In One Picture
```text
Clock 5 + 2 + 5 + 13 + 13 + 5
Roles candidate, interviewer,
observer
Rubric 7 dimensions x 1-4,
one quote each
Debrief self-score, evidence,
top 2 gaps, log
Redo weakest section, 48 h
Re-test new prompt, two in a row
Ready 5 of 7 at 3+, none at 1
(senior, judgement)
```
## Conclusion
A mock is a measurement, and the loop is the training. Keep the clock fixed, score against anchors with evidence, and spend as long on the fix as on the run. Then the numbers mean something, and the gaps close one at a time.
**Which dimension is your lowest right now?** Tell us in the comments.
- **Turn this into a calendar:** the [prep-plan lesson](/system-design-interview-prep-plan-2026/) sets a 2 to 4 week schedule around these mocks.
- **Pick your first prompt:** start with the [URL shortener](/design-a-url-shortener/), then follow the bank above.
- **Practise the AI-feature round:** the [LLM system design guide](/llm-system-design-interview-2026/) is the hardest prompt in the bank.