A free system design mock interview needs three things you can get without paying: a script that forces the order real design rounds follow (requirements, estimates, API, data model, high-level design, deep dive, trade-offs), an interviewer who knows what to probe, and a rubric to score against. This page gives you a 45-minute script, the prompts the interviewer should use, a scoring rubric by level, free ways to practice and the failure modes that sink otherwise strong candidates.
Why 45 minutes? Meta's own software engineering interview prep post says its design interview is 45 minutes long and that the interviewer typically saves the last five minutes for your questions (the post was last updated in 2022, so check your recruiter's current guide). Other companies run longer: Amazon's interview guide describes loop interviews of 45-60 minutes each. The script below uses 40 minutes of design plus 5 for questions; for a 60-minute round, give the extra time to the deep dive.
The 45-minute system design mock interview script
| Minutes | Phase | The candidate | The interviewer checks |
|---|---|---|---|
| 0–5 | Requirements | Asks about users, core features, what's out of scope, and latency, availability and consistency goals | Did they scope before drawing anything? |
| 5–10 | Estimates | Rough requests per second, storage, bandwidth and the read/write ratio | Do the numbers drive a decision? |
| 10–14 | API | Three to five core endpoints or events with their key fields | Does the API cover the requirements and nothing extra? |
| 14–18 | Data model | Entities, keys, access patterns and the choice of store | Does the store fit how the data is read? |
| 18–28 | High-level design | Clients, load balancer, services, stores, caches and queues; walks one request end to end | Is there a working path for every core feature? |
| 28–38 | Deep dive | One or two components in depth: scaling, partitioning, hot keys, failures | Depth, not a tour of more boxes |
| 38–40 | Trade-offs and wrap-up | Names bottlenecks, what changes at 10x, and what to monitor | Can they critique their own design? |
| 40–45 | Candidate's questions | Asks the interviewer two or three real questions | Not scored in this mock |
The order matters more than the exact minutes. If the interviewer pulls you into a deep dive early, follow, then come back and close the loop. What you should never do is skip requirements and estimates because you think you already know the answer. For the concepts behind each phase, keep our system design interview cheat sheet open while you prepare, not while you practice.
The script phase by phase, with one example prompt
To make the script concrete, here is how each phase might sound for “design a notification system.” The numbers are assumptions we chose for the example, not real traffic figures. Our full notification system walkthrough goes deeper.
Requirements (0–5)
Ask before you draw: which channels (push, email, SMS, in-app)? Do users set preferences? Is there a broadcast case, such as one message to every user? What matters most: low latency, or never losing a notification? Write the answers down where the interviewer can see them, and say what you're leaving out of scope.
Estimates (5–10)
Assume 10 million daily active users receiving 20 notifications a day: 200 million a day, or about 2,300 per second on average (200 million divided by 86,400 seconds). Plan for peaks several times higher. At roughly 1 KB per stored notification, that's about 200 GB a day, or around 73 TB a year. Then say what the numbers mean: writes are steady but bursty, so you'll want a queue between intake and delivery. The free system design cheat sheet tool has a capacity calculator for this step.
API (10–14)
Keep it small: POST /notifications with a user ID, template, channel and priority; GET /users/{id}/notifications?cursor= for the in-app inbox; PUT /users/{id}/preferences. Add an idempotency key on the send call now; you'll need it in the deep dive.
Data model (14–18)
Notifications are read by user and time, so key them by user ID and creation time in a store that handles high write volume. Preferences are small, read on every send and rarely updated, so a relational table with a cache in front is enough. A delivery log records each attempt and its status.
High-level design (18–28)
Draw the request path: the API validates the request and checks preferences, writes the notification, and puts a message on a per-channel queue. Channel workers pull from the queues and call the push, email or SMS provider, then record delivery status. Walk one notification through every box out loud.
Deep dive (28–38)
Pick the riskiest parts: retries with backoff when a provider fails, deduplication using the idempotency key so a retry never sends twice, per-user rate limits, and a separate high-priority queue so a password reset isn't stuck behind a marketing broadcast.
Trade-offs (38–40)
Name what you chose and what it cost: at-least-once delivery with deduplication instead of exactly-once, eventual consistency for the inbox, and SMS as the expensive channel you'd limit. Close with what you'd monitor, such as queue depth, provider error rates and delivery latency.
The interviewer's side: how to run the mock
Whoever plays the interviewer needs a few rules, or the mock turns into a friendly chat:
- Start vague. Give only the one-line prompt. Answer clarifying questions with realistic numbers, but never volunteer requirements.
- Don't lead. If the candidate misses something important, note it on the rubric rather than hinting.
- Throw one curveball around minute 25. Change a requirement or break a component and watch how the candidate adapts.
- Take notes per rubric row, and save all feedback for the end.
Prompts to use as the interviewer, roughly in order:
- “What's out of scope for this version?”
- “Your estimate says this many writes per second. What does that change in the design?”
- “Walk me through exactly what happens when a request comes in.”
- “This database node goes down. What happens to in-flight requests?”
- “Traffic jumps 10x for a day. What breaks first?”
- “How do you make sure the same action doesn't happen twice?”
- “What would you monitor, and what should page someone at night?”
- “If you had another week, what would you change?”
For the prompt itself, rotate through problems with existing walkthroughs so the candidate can compare afterward. A warm-up such as a URL shortener or a rate limiter suits a first mock; a news feed or the notification system suits mid-level practice; a distributed key-value store stretches senior candidates.
Interviewer rubric for a system design mock interview
Score each dimension as below the bar, at the bar or above the bar. This is our rubric for practice, built from the phases above; companies don't publish their internal scoring, and expectations vary by level and team.
| Dimension | Below the bar | At the bar | Above the bar |
|---|---|---|---|
| Requirements and scope | Starts drawing immediately | Asks core questions, states scope | Finds the requirement that shapes the whole design |
| Estimation | Skips it, or numbers go unused | Reasonable numbers, stated assumptions | Numbers decide a specific component choice |
| API and data model | Missing or unrelated to the features | Covers the core flows; store fits access patterns | Anticipates pagination, idempotency, schema change |
| High-level design | Boxes with no request path | Every core feature works end to end | Clean separation that makes later scaling easy |
| Deep dive | Stays broad, lists buzzwords | One component explained in real depth | Two deep dives, including failure handling, unprompted |
| Trade-offs | Presents one option as the only answer | Names alternatives when asked | Raises trade-offs and costs before being asked |
| Communication | Long silences, interviewer has to drive | Thinks out loud, checks in | Drives the session and adapts well to the curveball |
Level changes what “at the bar” means. As a rough guide, a mid-level candidate should produce a complete, working design and one solid deep dive with some prompting. A senior candidate should drive without prompting, cover failure modes on their own and handle the curveball calmly. Staff-level candidates are usually also expected to talk about cost, operations and how the system evolves. Ask your recruiter what your level's design round emphasizes.
Free ways to practice a system design mock interview
- A friend or colleague who has done design rounds. The best option if you can get it. Send them this script, the rubric and the prompts beforehand.
- Peer mock platforms. Some sites match you with another candidate for free peer practice. We compared what's actually free on each in our guide to the best free mock interview websites, checked October 2026.
- Solo, on the tool you'll use. Record yourself talking through a prompt on a whiteboard or drawing tool, then score the recording with the rubric. Ask your recruiter which tool the round uses; Google's virtual interview candidate guide, for example, points system design candidates to Google Drawings. The same guide says using AI to answer interview questions leads to disqualification, so keep AI in your practice, not your interview.
- An AI mock interview. CoPilot Interview's Mock Interview mode (we make it) includes system design in its question mix. In the desktop app, paste the job description and your résumé, choose the level and set the mix to system design; the AI reads the question aloud, listens to your spoken answer and scores it out of 10 with what to fix, a model answer and the follow-up a real interviewer would ask. One system design question fits a free 15-minute session. The browser AI mock interview has a system design track with nothing to install, and you can attach a screenshot, such as a photo of your diagram, to your answer.
An AI mock is good for volume and for drilling the order of the phases. It doesn't replace a person who interrupts, challenges your diagram and asks why. Mix both: AI rounds during the week, and a person at least once before the real thing. Our system design interview hub covers the core topics in more depth.
Failure modes to watch for in your mocks
| Failure mode | What it looks like | Fix |
|---|---|---|
| Drawing before scoping | A full diagram by minute three, then a requirement that breaks it | Spend the first five minutes on questions only |
| Estimates that change nothing | Careful math, then the same design you'd draw anyway | End every estimate with “so this means…” |
| Components without reasons | “Add a cache, add Kafka” with no explanation | Give each box one sentence: what it's for and why here |
| Broad, never deep | Twelve boxes, none explained past one line | Pick one component and go three questions deep |
| Silent thinking | Long pauses while drawing | Narrate decisions, even half-formed ones |
| Defending instead of adjusting | Arguing with the curveball | Accept the new constraint, then rework the affected part |
| No time for trade-offs | Still drawing at minute 40 | Set a timer for minute 35 and start wrapping up |
| Ignoring failure | Every component is assumed to stay up | For each store and service, say what happens when it fails |
How many mocks, and in what order
There's no official number. A practical plan is six mocks over three weeks:
- Week 1: two warm-up prompts. Goal: hit every phase in order and finish on time. Score only requirements, estimation and communication.
- Week 2: two mid-level prompts. Goal: one real deep dive per session, including what happens when a component fails.
- Week 3: two harder prompts with a curveball. Goal: adapt without restarting. Make at least one of these with a person.
After each mock, write down the lowest-scoring rubric row and make it the only goal for the next session. Redo a prompt you struggled with a week later, without reading its walkthrough first.
Practice a system design round out loud, free
Set the mix to system design, answer the question out loud, and get a score out of 10 with what to fix, a model answer and the follow-up a real interviewer would ask. Free for 15 minutes a day, no credit card.
Try a free AI mock interviewFAQ
How long is a system design mock interview?
Plan for 45 minutes: about 40 minutes of design and 5 for your questions. Meta’s prep post describes a 45-minute design interview, and Amazon’s guide describes loop interviews of 45 to 60 minutes, so ask your recruiter and give any extra time to the deep dive.
Can I do a system design mock interview for free?
Yes. Use the script and rubric on this page with a friend or colleague, try a free peer mock platform, record yourself solo, or use CoPilot Interview’s free plan, which includes Mock Interview with system design questions for 15 minutes every day.
What do interviewers look for in a system design interview?
Broadly: whether you scope the problem, use estimates to make decisions, produce a design that works end to end, go deep on at least one component, discuss trade-offs and failures, and communicate clearly. Expectations rise with level, so ask your recruiter what your round emphasizes.
How many system design mock interviews should I do?
There is no official number. Six mocks over three weeks, across different prompts and with at least one session in front of a real person, is a practical plan if you already know the core concepts.
Can an AI run a system design mock interview?
Yes, for practice. CoPilot Interview’s Mock Interview mode reads a system design question aloud, listens to your spoken answer and scores it out of 10 with what to fix, a model answer and a follow-up. It does not replace a person challenging your diagram, so mix both.
What should I use to draw in a mock system design interview?
Practice on the same tool your interview will use, and ask your recruiter if you are unsure. Google’s virtual interview candidate guide, for example, points system design candidates to Google Drawings. For solo practice, paper or a whiteboard photo works too.