System Design Road

Part 8 · Lesson 8.1

The Interview That Ran Out of Time

A framework for the 45-minute interview9 steps · 11 min

Where we are: you've finished the course. You've grown Chirp from one server to fifty million users, and built chat, ride-sharing, payments and video along the way. Part 8 is about turning that understanding into a good 45 minutes with a stranger and a whiteboard, which is a different skill.

What you’ll learn

  • A six-step plan for a 45-minute design interview, with time for each step
  • What interviewers are actually scoring, and how it changes with seniority
  • How to think out loud, make trade-offs visible and use the interviewer’s hints
  • The habits that sink otherwise strong candidates
Lesson trace

Lesson 8.1 The Interview That Ran Out of Time

Step 1 of 9 · 1 min · The story

Sana had been a backend engineer at Chirp for two years. She'd been on call during the cricket final (lesson 4.5) and helped build the sharding migration (lesson 5.1). If anyone at Chirp understood large systems, it was her. So when she interviewed for a senior role at a larger company, she expected the system design round to go well.

The question was "Design a notification system that can send push, email and SMS to 100 million users." She started by asking a good clarifying question about which channels mattered most. Then she began designing the database schema: the notifications table, its columns, the indexes. It was a good schema. It took 25 minutes, because the interviewer kept asking reasonable questions about it, and she kept answering them in depth.

At minute 38, the interviewer said, "We have a few minutes left. Can you walk me through the overall architecture?" Sana drew five boxes in a hurry. She never got to retries, rate limits per user, provider failures, or how to send a campaign to 100 million people without melting anything, which were exactly the topics she knew best.

The feedback was polite: "Strong technical depth in the areas discussed. Did not demonstrate the ability to design an end-to-end system in the time available."

She knew the material. She didn't have a plan for the 45 minutes. This lesson is that plan.

Step 2 of 9 · 1 min

What the interviewer is looking for

It helps to know how you're being assessed. The details vary between companies, but most system design rubrics look at roughly the same things:

  • Understanding the problem. Did you find out what actually needs to be built, and how big it is, before building it?
  • Designing a working system. Is there a clear, end-to-end design where requests flow from users to storage and back, and the main features work?
  • Depth. On the hard parts, can you go deep: real mechanisms, real failure modes, real numbers?
  • Trade-offs. Do you see the alternatives, explain why you chose one, and say what it costs?
  • Communication. Can the interviewer follow your thinking? Do you respond to their questions and hints?

Notice that "knows a lot of technologies" isn't on the list. Naming Kafka, Cassandra and Kubernetes earns nothing by itself. Explaining why a log fits this problem better than a queue (lesson 4.1) earns a lot.

Expectations also rise with level. For a junior role, a sensible, working design with a few good trade-offs is a strong result. For a senior role, interviewers expect you to drive the conversation yourself, pick the right parts to go deep on, raise failure modes before being asked, and make decisions with numbers behind them.

Step 3 of 9 · 3 min

The six steps

Here's a plan for 45 minutes. The times are guides, not rules: the interviewer may steer you, and you should let them. But having a plan means that when you're 20 minutes in, you know whether you're on track.

1. Clarify the problem (about 5 minutes)

Never start designing straight away. The prompt is deliberately vague, and part of the test is whether you narrow it down.

Ask about:

  • The core features. "For a notification system: are we sending one-off notifications triggered by events, like 'someone liked your post,' and also bulk campaigns to millions of users? Do users have preferences, such as no email, or quiet hours?" Then agree on the three or four that matter, and say what you'll leave out: "I'll set aside templates and A/B testing unless we have time."
  • Scale. Users, daily actives, how many notifications a day, peak versus average. If the interviewer doesn't know, propose numbers and ask if they're reasonable.
  • Quality requirements. How fast must a notification arrive? Can it ever be lost? Can a user get it twice? How available must it be? These decide much of the design later (lesson 5.3's "what's the weakest guarantee it can live with?").

Write the agreed features and numbers down on the board. You'll refer back to them.

2. Estimate what matters (about 3–5 minutes)

Lesson 1.3's method, quickly. Estimate only what will change the design: requests per second at peak, storage growth, bandwidth if there's media. Round aggressively, and say out loud what each number means: "About 50,000 sends a second at peak during a campaign, so we'll need a queue in front of the providers, and the providers' own rate limits become our bottleneck." Lesson 8.2 is about doing this quickly under pressure.

3. Define the interface and data (about 5 minutes)

Sketch the main APIs (lesson 1.5): what calls come in, with what parameters. For a notification system: send(user_id, type, data, idempotency_key) from other services, and update_preferences(user_id, …) from the app.

Then the main data: what entities exist, roughly what's in them, and how they're accessed (lesson 3.1). Not a full schema. The access patterns matter more than the column types, because they decide where the data lives.

This is where Sana lost her time. Keep it brief, and move on. You can come back to details during the deep dive if they turn out to matter.

4. Draw the high-level design (about 10 minutes)

Now draw the system: clients, load balancer, services, queues, databases, caches, external providers. Then walk through the main flows on the drawing, one at a time: "A service calls send. We check the user's preferences and rate limits, write the notification with its idempotency key, and put a job on the channel's queue. Workers pick it up and call the push provider…"

Walking through flows is what proves the design works end to end. It also often reveals a missing box.

At the end of this step, you should have a complete, simple design that handles the agreed features at a basic level. It doesn't need to be clever yet. It needs to be whole.

5. Go deep on the hard parts (about 15 minutes)

This is the longest step, and where most of the evaluation happens. Pick two or three parts of the design that are genuinely hard for this problem, and go deep on them: mechanisms, numbers, failure modes, alternatives.

Choose them yourself if you're senior ("The hard parts here are the campaign fan-out, provider failures, and making sure nobody gets the same notification twice. Shall I start with the fan-out?"), and let the interviewer redirect you if they want to see something else. If the interviewer asks about a specific area, that's the area. They're telling you what they need to see.

For the notification system, a strong deep dive might cover:

  • Fanning out a campaign to 100 million users through chunked jobs and separate lanes, so campaigns can't delay urgent notifications (lesson 4.4's lanes).
  • Idempotency keys and per-user de-duplication, so retries don't double-send (lessons 1.5 and 4.1).
  • Provider outages: timeouts, circuit breakers, fallback providers, retry with backoff (lesson 6.1).
  • Respecting provider rate limits and per-user limits (lesson 6.3).

6. Wrap up (about 3–5 minutes)

Close the loop. Briefly cover:

  • Bottlenecks and how you'd scale them as numbers grow ten times.
  • Failure modes you haven't discussed: what happens if the database or a whole region fails.
  • How you'd know it's working (lesson 6.4): the two or three SLIs you'd measure.
  • What you'd do next with more time.

This shows you can see the whole system, including the parts you didn't build out.

Step 4 of 9 · 1 min

How to talk while you design

How you communicate is scored as much as what you draw. A few habits make a big difference.

Think out loud. Silence while you draw leaves the interviewer guessing. Narrate: "I'm putting a queue here because sending to providers is slow and can fail, and I don't want the calling service to wait on that."

Make trade-offs explicit. Whenever you choose something, say what you're choosing between, why, and what it costs: "I'll store notifications in Cassandra, partitioned by user, because it's append-heavy and read by user and time. The cost is that 'all notifications of type X' becomes a separate table or an analytics query." That one sentence demonstrates more than a box labelled "Cassandra."

Use numbers. "This should be fast" is weak. "This is one indexed lookup, under a millisecond, and we do it once per send" is strong.

Check in. Every few minutes: "Does this level of detail work, or would you like me to go deeper anywhere?" Interviewers often have specific things they want to see, and they'll tell you if you ask.

Treat hints as gifts. If the interviewer asks "What happens if the push provider is down for an hour?", they're not making conversation. They want to see failure handling. Go there.

Commit, and stay flexible. Make decisions instead of listing options forever ("we could use X or Y or Z…"). Pick one, give the reason, and change it if new information comes up. Changing your mind for a good reason is a strength, not a weakness.

Step 5 of 9 · 1 min

Habits that sink strong candidates

These come up again and again in interview feedback:

  • Designing before understanding. Starting with boxes before clarifying features or scale.
  • Spending the clock on one part. Like Sana's schema. A complete simple design beats a perfect half design.
  • Naming technologies without reasons. "We'll use Kafka" isn't a design decision until you say why.
  • Over-engineering for scale that wasn't asked for. A design for 10,000 users doesn't need sharding, and proposing it suggests poor judgment (lesson 1.3's lesson about Arjun's Cassandra cluster).
  • Ignoring failure. Designs where nothing ever times out, crashes or retries. Part 6 is there for a reason.
  • Not listening. Ploughing on with your plan while the interviewer tries to steer you somewhere else.
  • Going silent. Long silences while thinking. It's fine to think, but say what you're thinking about.

Step 6 of 9 · 1 min

From the real world: what "good enough" looked like

It's easy to walk into an interview thinking a strong design must be elaborate. A useful corrective is to look at what real, very successful products actually ran on.

When Facebook bought Instagram in April 2012, Instagram had 13 employees and more than 30 million users. Its engineers had written publicly about their stack, and it was strikingly ordinary:

  • Stateless Django app servers behind load balancers (lessons 2.1 and 2.2).
  • PostgreSQL for the main data, split into thousands of logical shards mapped onto a few physical servers, so shards could be moved to new machines without re-sharding (lessons 5.1 and 5.2).
  • 64-bit IDs built from a timestamp, the shard ID and a per-shard sequence, generated inside Postgres (lesson 4.3).
  • Redis for feeds and sessions, memcached in front of the databases (lesson 2.4).
  • Photos in S3, served through a CDN (lesson 2.3), and a task queue for background work (lesson 4.1).

Every part of it is something this course covers, used plainly. There's no exotic database and no custom infrastructure. What made it work was that the pieces were the right ones for Instagram's access patterns, and the team understood them well enough to run them.

That's what interviewers are looking for too. A correct, boring design you can explain, estimate and evolve beats an impressive one you can't defend. When you're tempted to add a technology, ask the question from lesson 1.3: what number in my estimate makes this necessary?

Step 7 of 9 · 1 min

Practising

Reading about interviews doesn't make you good at them, just as reading about cricket doesn't improve your batting. What helps:

  • Do full, timed practice runs, out loud, with a clock visible. Lesson 8.4 has prompts. Use a whiteboard or the online drawing tool the company uses.
  • Practise with another person playing interviewer, who interrupts with follow-up questions (lesson 8.3 has the common ones).
  • Review each run: where did the time go? Which step ran over? What did you not get to?
  • Keep a short list of your own go-to deep dives, with numbers you know well: a cache's hit-ratio math, a sharding key choice, idempotency keys, fan-out trade-offs. The lessons in this course are a good source.

Sana practised six full runs over three weeks, with Meera playing interviewer. Her next design interview, at a different company, was "design a chat system." She spent four minutes clarifying, drew the whole system by minute 22, and spent fifteen minutes on ordering, delivery receipts and gateway reconnect storms (lesson 7.1). She got the offer.

Step 8 of 9 · 2 min

Try these yourself

1. You're 20 minutes into a 45-minute interview, and you're still discussing the data model. What should you do?

Say so, and move on: "I want to make sure we get to the whole system, so let me sketch the high-level design now and come back to the data model details if they matter." Then draw the complete design quickly. A complete simple design, followed by depth where the interviewer wants it, beats a perfect partial one.

2. The prompt is "Design Instagram." List four clarifying questions you'd ask first.

Examples: Which features are in scope (posting photos and videos, feed, follows, likes, comments, stories, search)? How many users and daily actives, and how many uploads and feed views a day? Is the feed chronological or ranked? What are the latency and availability expectations, and can a post appear in feeds a few seconds late? Then agree on three or four core features and say what you're leaving out.

3. An interviewer asks, "What happens if your cache cluster restarts?" What are they probably checking, and how would you answer?

Whether you understand that a cache can become load-bearing (lesson 2.4): with an empty cache, every read hits the database. A good answer covers the database's load at a cold start, protecting it (limiting concurrent queries, shedding load, serving stale data), avoiding restarting the whole cache at once (replicas, rolling restarts), and warming the cache before switching traffic.

4. Rewrite this weak statement as a strong one: "We'll use Kafka for the events."

For example: "Post events go into Kafka, partitioned by post ID, because three consumers (search indexing, notifications and analytics) each need every event, in order per post, and we want to be able to replay events to rebuild the search index. A simple job queue would give each event to only one consumer."

5. For a senior role, what's the difference between a good wrap-up and an excellent one?

A good wrap-up lists bottlenecks and next steps. An excellent one connects them to numbers and failure modes: what breaks first at ten times the load and how you'd fix it, what happens if a region fails and how much data could be lost, which two or three SLIs you'd alert on, and which trade-offs you'd revisit as requirements change.

Step 9 of 9 · 1 min

Further reading

  • Alex Xu, System Design Interview: An Insider's Guide, volume 1, for many worked examples in interview format.
  • Martin Kleppmann, Designing Data-Intensive Applications, for the depth that strong deep dives are made of.
  • Public engineering blogs from companies you're interviewing with: they show what they care about, and give you real examples to mention.
  • Instagram Engineering, "What Powers Instagram: Hundreds of Instances, Dozens of Technologies" (2011) and "Sharding & IDs at Instagram" (2012).