A system design interview is 45 to 60 minutes, a vague prompt like "design a food delivery app", and a whiteboard. There's no single right answer, which makes people nervous: if there's no answer key, what is the interviewer actually grading?
The good news is that they're grading the same things this course has been building all along. The interview is a compressed, slightly artificial version of real design work. This lesson explains what interviewers listen for, how to run the hour, and how to handle the moments that throw people off.
What's being assessed
An interviewer can't check whether your design would survive production. They have an hour and a whiteboard. So they listen for signals that you'd make good decisions on a real team.
| Signal | What they hear when it's strong |
|---|---|
| Problem framing | You asked questions, narrowed the scope and wrote down requirements before drawing |
| Estimation | You turned users into requests per second and storage, with units, and used the numbers to make choices |
| Sound design | Each part has a reason. The data model fits the queries |
| Tradeoffs | You named alternatives and costs without being asked |
| Depth | On at least one hard part, you went well past the boxes |
| Failure thinking | You asked what happens when things are slow, crash or run twice |
| Communication | You led the discussion, kept it organised and checked in |
Notice what's not on the list: naming the most technologies, or matching what some famous company actually built. An interviewer would much rather hear "one Postgres primary handles this, here's the maths" than a diagram copied from a conference talk.
The interviewer is asking themselves one question: would I trust this person to design a part of our system?
How the bar changes with level
The same prompt is used for different levels. What changes is what counts as strong.
| Level | Expected |
|---|---|
| Junior or new grad | A working end-to-end design with sensible API and data model. Some prompting is fine |
| Mid-level | Drives the hour. Reasonable numbers. Handles one or two deep dives with real detail |
| Senior | Spots the hard part early, goes deep on it, discusses failure and tradeoffs without prompting |
| Staff and above | All of that, plus how the system evolves, operational cost, team boundaries and what not to build |
So if you're junior, don't panic about not knowing Raft. Show that you can get from requirements to a design that works, and explain why. If you're senior, a correct but shallow design is not enough. The deep dive is where you earn the level.
Running the hour
Use the six steps from the first lesson in this module, with a rough clock. This is the hour-long version of that lesson's 45-minute budget: the extra time goes to deep dives and a wrap-up.
0-5 Clarify requirements and scope. Write them down.
5-10 Estimate: users, requests/s, storage, read/write ratio.
10-20 API and data model.
20-30 High-level design. Walk one request through it.
30-50 Deep dives: one or two hard parts, failure modes.
50-55 Wrap up: bottlenecks, what you'd do next, questions.
A few habits that make a big difference:
- Think out loud. The interviewer can only grade what they hear. Silence for three minutes followed by a finished diagram scores worse than the same diagram built while explaining each choice.
- Write things down. Requirements, numbers, the API, the tables. It shows structure, and it gives both of you something to point at.
- Walk a request through. After drawing the design, trace one real action: "a customer taps Place Order, the request goes to..." It catches gaps and shows you understand how the parts connect.
- Check in. "I'm going to go deeper on the live tracking part, unless you'd rather I look at something else?" Interviewers often have a part they want to see. Let them steer you there.
Clarifying questions that matter
The first five minutes are where most people lose points, by asking nothing or by asking too much. Ask questions whose answers change the design.
For "design a food delivery app", good ones:
- Which parts are in scope: ordering, restaurant side, rider dispatch, live tracking, payments?
- How many cities, orders per day and restaurants? If they say "you decide", decide out loud: "I'll assume one large city, 500,000 orders a day."
- Does the restaurant need to see orders within a set time?
- How live does rider tracking need to be?
Less useful: "What programming language should I use?" or "Should I use AWS?" Neither changes the design.
Pick your questions
The prompt is: "Design a system that sends push notifications for a large app." You have time for four clarifying questions. Which four?
Show one answer
- How many notifications a day, and how bursty? A daily digest to 50 million users at 9am is a very different load from a steady trickle.
- What kinds? Transactional ("your order is out for delivery") versus marketing campaigns. Transactional ones are urgent. Marketing ones can wait and must respect user preferences.
- Delivery guarantees? Is it acceptable to miss one occasionally, or to send one twice? (Twice is usually worse for users.)
- Which channels? Mobile push only, or also SMS and email, each with its own provider limits.
Each answer moves a part of the design: queue sizing, priority lanes, de-duplication, provider rate limits.
Going deep
The deep dive is where interviews are won. Pick the hardest, most interesting part of this problem, not a generic one. For a food delivery app, that might be rider location at scale, matching riders to orders, or not losing an order when the payment call times out. For a URL shortener, it's generating short codes that never collide, and handling the read load.
A strong deep dive has a shape:
- State the problem precisely, with a number. "150,000 riders send a location every 4 seconds: 37,500 writes a second, and we need 'nearest riders to this restaurant' in under 100 ms."
- Give two or three options, and their costs.
- Choose one, and say why for this case.
- Break it. What fails, and what do we do? "If the Redis node holding locations dies, a replica takes over and may be missing the last few seconds of positions. Riders resend every 4 seconds, so the map heals itself almost at once. We don't need durability here."
When things go sideways
You don't know something. Say so, then reason. "I haven't used Cassandra in production, but I know it's designed for high write throughput with tunable consistency. Here's how I'd think about whether it fits." Bluffing gets caught, and it's worse than an honest gap.
The interviewer pushes back. Usually it's not "you're wrong". It's "show me you can handle a change". "What if traffic grows 100x?" is an invitation to walk the growth steps from Module 9. Don't throw your design away. Say what breaks first and what you'd change.
You get a hint. Take it, and say so: "Good point, if a flash sale sends thousands of orders a second at one item, a single stock-count row becomes the bottleneck. Let me rethink that." Taking feedback well is a signal too.
You're running out of time. Don't rush to draw more boxes. Summarise: what you designed, the main tradeoffs, the next bottleneck, and what you'd do with more time.
Practise out loud, with a timer, ideally with another person. Reading designs builds knowledge. Only speaking them builds the skill of explaining a design while you create it, which is what the interview tests. The labs at the end of each module, and the lab in this module, are good practice prompts.
Handle the curveball
You've designed Tiffin with one Postgres primary and replicas, at 250,000 orders a day. The interviewer says: "Now it's 50 million orders a day. What changes?" Outline your answer in a few lines.
Show one answer
First, the numbers. 50 million a day, with 60% in 3 hours, is about 2,800 orders a second at peak. At ~15 row writes per order, that's around 40,000 writes a second for orders alone, which is past what one primary can comfortably take.
Then, in order: move anything that doesn't belong out of the main database (rider pings, events, logs). Partition and archive. Then shard the order data, by city as a starting point since nearly all operations are within one city, and split the largest cities further. Order IDs must become globally unique. Search is already its own index. Teams of this size likely mean services with their own databases.
Then name the hardest new problem: cross-shard queries like a customer's order history across cities, and how you'd serve it.
What to remember
- Interviewers grade signals: framing, estimation, sound design, tradeoffs, depth, failure thinking and communication.
- The bar rises with level. Seniors are judged mostly on the deep dive and on raising tradeoffs unprompted.
- Run the hour with the six steps and a clock. Think out loud, write things down and walk a request through.
- Ask clarifying questions whose answers change the design.
- A good deep dive: state the problem with a number, give options, choose, then break it.
- Admit gaps and reason from first principles. Treat pushback as an invitation, and take hints openly.