Free lesson · System Design Interviews

What Are System Design Interviews?

Easy12 min readsystem-designinterview-prep

Let me tell you something that took me five years and two failed interview loops to understand: system design interviews are not about knowing systems. They're about showing someone - a stranger with a laptop and a whiteboard - that you can think about systems under pressure, out loud, in a way that makes them trust you to build real things.

I'm Brandon Carter. I'm a Principal Engineer at Amazon Web Services, where I architect the cross-region replication layer for S3. I've also conducted over 300 interviews as an Amazon Bar Raiser. I've sat on both sides of the table - the side where you're sweating through your shirt trying to remember how consistent hashing works, and the side where you're watching a candidate and thinking, "Do I trust this person to build something that won't fall over at 3 AM?"

This course exists because those two sides see completely different things. Candidates think the interview is a knowledge test. Interviewers think the interview is a thinking test. That gap is where most people fail.

The Activity Itself

A system design interview is a 45-to-60-minute conversation where an interviewer gives you an open-ended problem - "Design Twitter," "Design a URL shortener," "Design a notification system" - and you build a solution from scratch on a whiteboard or shared document.

There is no single correct answer. There is no hidden solution the interviewer is waiting for you to guess. The interviewer is watching how you approach the problem, not what you draw on the board.

graph LR
    A[Interviewer poses<br/>open-ended problem] --> B[You clarify<br/>requirements]
    B --> C[You estimate<br/>scale & constraints]
    C --> D[You propose<br/>high-level design]
    D --> E[You dive deep<br/>into components]
    E --> F[You discuss<br/>tradeoffs & bottlenecks]
    F --> G[Interviewer probes<br/>with follow-ups]
    G --> E

This diagram shows the flow of a system design interview. The interviewer poses an open-ended problem. You clarify requirements, estimate scale, propose a high-level design, dive deep into components, and discuss tradeoffs. The interviewer then probes with follow-ups, and the cycle of diving deep and discussing tradeoffs repeats.

That loop at the end - where the interviewer asks follow-ups and you dive deeper - is where the interview is actually decided. The first fifteen minutes are setup. The last thirty minutes are the real evaluation. Most candidates spend too long on setup and never get to the part that matters.

What It Actually Tests

Here's the part that tripped me up for years. I thought system design interviews tested whether you know system design. They don't. They test five things, and knowledge is only one of them.

1. Can You Scope a Problem?

The interviewer gives you an intentionally vague prompt. "Design Uber." That could mean a hundred things. The first thing they're watching is whether you immediately start drawing boxes, or whether you pause and ask: "Are we designing the rider experience, the driver matching, the payment system, or the entire platform? What scale are we targeting? What's the most critical requirement - low latency on matching, or reliability on payments?"

The candidates who fail at this stage are the ones who start building before they know what they're building. In my 300+ interviews, this is the single most common mistake. Not a lack of knowledge. A lack of discipline around scoping.

2. Can You Make Reasonable Estimates?

If you're designing a system that handles "a lot of users," you haven't scoped anything. The interviewer wants to hear numbers. "Twitter has roughly 500 million tweets per day. That's about 6,000 tweets per second on average, with spikes to maybe 15,000 during major events. Each tweet is roughly 1 KB with metadata, so we're looking at about 500 GB of new data per day."

Are those numbers perfectly accurate? Doesn't matter. What matters is that you have a process for estimating, you use round numbers, and the estimates are in the right order of magnitude. The ability to do rough math on the spot - back-of-the-envelope calculations - is a signal that you've actually worked with systems at scale, or at least thought seriously about scale.

3. Can You Design at the Right Altitude?

This is the hardest skill and the one that killed me in my second Google interview. I had been building distributed systems at Stripe - systems handling over 100 million transactions per day. I knew exactly how those systems worked, down to the byte. And that was the problem.

When the interviewer asked me to design a payment processing system, I went straight into the details of exactly-once delivery semantics, idempotency keys, and two-phase commit protocols. I was technically right about everything I said. But I never drew the high-level architecture. I never showed the interviewer the big picture. I was so deep in the trees that they never saw my forest.

The right altitude for a system design interview is top-down. You start with the boxes - the major components and how they connect. You label the interfaces. You identify where the data flows. And then, when the interviewer asks "tell me more about this component," you go deep. You don't go deep unprompted. You wait for the signal.

graph TD
    subgraph "Wrong: Bottom-Up"
        W1[Start with database<br/>schema details] --> W2[Argue about<br/>indexing strategies]
        W2 --> W3[Never reach<br/>high-level design]
        W3 --> W4["Interviewer thinks:<br/>'Can't see the forest'"]
    end

    subgraph "Right: Top-Down"
        R1[Start with major<br/>components & data flow] --> R2[Label interfaces<br/>& protocols]
        R2 --> R3[Interviewer asks<br/>to go deeper]
        R3 --> R4[Now show depth<br/>where they care]
        R4 --> R5["Interviewer thinks:<br/>'Structured thinker'"]
    end

This diagram contrasts two approaches to system design interviews. The wrong approach starts bottom-up with database schema details, argues about indexing, and never reaches the high-level design. The interviewer concludes the candidate can't see the forest for the trees. The right approach starts top-down with major components and data flow, labels interfaces, then goes deeper only when the interviewer asks. The interviewer concludes the candidate is a structured thinker.

4. Can You Identify and Discuss Tradeoffs?

Every design decision involves a tradeoff. Choosing SQL over NoSQL. Choosing push-based over pull-based fanout. Choosing strong consistency over eventual consistency. The interviewer does not care which one you pick - they care whether you know you're making a tradeoff and can articulate what you're giving up.

The magic phrase in every system design interview is: "The tradeoff here is..."

"The tradeoff here is that by using a NoSQL store, we get horizontal scalability and faster writes, but we lose the ability to do complex joins and we need to handle consistency at the application level."

That single sentence - naming the tradeoff explicitly - earns more points than ten minutes of technically correct but unframed design.

5. Can You Communicate While You Think?

This is the meta-skill. System design interviews are not exams. They are conversations. The interviewer needs to follow your thinking in real time. If you go silent for three minutes while you think, the interviewer has no idea what you're doing. They can't give you credit for thought processes they can't hear.

The technique is simple: narrate as you draw. "I'm going to put a load balancer here because we said we need to handle 15,000 requests per second, and a single application server can handle maybe 1,000. So we need at least 15 servers behind this load balancer." That narration turns your design into a shared experience instead of a private one.

Interview: The five things system design interviews actually test:

Scoping - Can you narrow a vague problem into something buildable?

Estimation - Can you do rough math to set constraints?

Architecture - Can you design top-down at the right level of detail?

Tradeoffs - Can you name what you're gaining and losing with each choice?

Communication - Can you narrate your thinking out loud?

Knowledge is the prerequisite. These five skills are what the interview actually scores.

How System Design Differs from Coding Interviews

If you've been grinding LeetCode, you have a very specific mental model of what a tech interview looks like. There's a problem. There's a correct answer. You either find it or you don't. The evaluation is binary - does the code pass all test cases?

System design is the opposite in almost every way.

Dimension	Coding Interview	System Design Interview
Answer type	Single correct solution	Multiple valid approaches
Evaluation	Binary (pass/fail test cases)	Gradient (weak to strong signal)
Preparation	Practice problems	Build mental models
Communication	Optional (code speaks)	Required (thinking out loud)
Time pressure	Solve in 20-40 min	Discuss for 45-60 min
Depth vs breadth	Deep on one algorithm	Broad across many components
Seniority signal	Same bar for all levels	Bar shifts with your level
What fails you	Wrong solution	Right solution, wrong communication

That last row is the one I want you to remember. In coding interviews, you fail because your solution is wrong. In system design interviews, you can have the right solution and still fail because you communicated it poorly, or started at the wrong altitude, or couldn't articulate the tradeoffs.

I've watched candidates draw architectures that were technically excellent - better than what I would have drawn - and get a "no hire" because the interviewer couldn't follow what they were doing. The design was right. The performance was wrong.

Warning: The most dangerous mindset in system design: Treating it like a coding interview where you need to find "the answer." There is no single answer. The interview is the conversation, not the diagram.

The Anatomy of a 45-Minute Interview

Here's a rough timeline of how a well-run system design interview flows. Not every interview follows this exactly, but this is the pattern you should aim for.

gantt
    title System Design Interview Timeline
    dateFormat mm
    axisFormat %M min

    section Phase 1
    Problem Statement & Clarification : 00, 05
    
    section Phase 2
    Requirements & Estimation         : 05, 10
    
    section Phase 3
    High-Level Design                  : 10, 20
    
    section Phase 4
    Deep Dives (2-3 components)        : 20, 40
    
    section Phase 5
    Wrap-Up & Questions                : 40, 45

This Gantt chart shows the timeline of a 45-minute system design interview. The first five minutes cover the problem statement and clarification. Minutes five through ten cover requirements and estimation. Minutes ten through twenty cover the high-level design. Minutes twenty through forty are deep dives into two or three components. The last five minutes are for wrap-up and candidate questions.

Phase 1: Problem Statement and Clarification (0–5 minutes)

The interviewer gives you the prompt. You ask clarifying questions. This is where you scope.

Phase 2: Requirements and Estimation (5–10 minutes)

You list functional requirements, non-functional requirements, and do back-of-the-envelope math.

Phase 3: High-Level Design (10–20 minutes)

You draw the major components - clients, servers, databases, caches, queues, load balancers - and show how they connect. This is the architecture at 30,000 feet.

Phase 4: Deep Dives (20–40 minutes)

This is the heart of the interview. The interviewer picks two or three components from your high-level design and asks you to go deeper. "How would you shard this database?" "What happens when this cache goes down?" "How does the notification delivery actually work?"

This is where senior engineers differentiate themselves from junior engineers. A junior engineer shrugs. A senior engineer has three options ready and can articulate the tradeoffs between them.

Phase 5: Wrap-Up and Questions (40–45 minutes)

You summarize what you designed, mention things you'd improve with more time, and ask your own questions about the team.

Tip: Time management is a signal. If you spend 25 minutes on requirements and estimation, you've burned more than half the interview on setup. The interviewer will think you can't prioritize. Aim for 10 minutes on Phase 1 + 2, then spend the remaining 30+ minutes on design and deep dives. That's where the points are.

Why Most People Fail

I've been a Bar Raiser at Amazon for six years. I've seen hundreds of candidates, and the failure modes cluster into a few predictable patterns.

Failure mode 1: The Knowledge Dump. The candidate knows a lot and tries to prove it by mentioning every technology they've ever heard of. "We could use Kafka, or RabbitMQ, or Amazon SQS, or Redis Pub/Sub, or NATS, or..." This reads as a lack of judgment. The interviewer doesn't want a list. They want a decision and a reason.

Failure mode 2: The Silent Architect. The candidate draws an excellent architecture - quietly, head down, marker moving. After 10 minutes of silence, they look up and say, "Here's my design." The interviewer has no idea how they got there. The design might be great, but the interview is about the process, not the product.

Failure mode 3: The Premature Optimizer. The candidate jumps straight into "How would we handle 10 million concurrent users?" before establishing the basic architecture. You need to walk before you can run. Design the system for 1,000 users first. Then scale it.

Failure mode 4: The Consensus Seeker. The candidate asks the interviewer, "Should I use SQL or NoSQL here?" - effectively asking the interviewer to make the design decision. This is a miss. The interviewer wants your judgment. Make the call, state the tradeoff, and move on.

Failure mode 5: The Single-Track Mind. The candidate gets stuck on one component and spends 20 minutes perfecting the database schema while the load balancer, caching layer, and message queue are empty boxes on the board. Breadth before depth - always.

Important: The single most important principle in this entire course: System design interviews test your ability to communicate a design, not just to have a design. The interviewer is evaluating your thought process. If they can't follow it, they can't score it. If they can't score it, you fail.

What This Course Will Teach You

Interactive animation: What the course teaches across modules 2 to 5: must-know topics, concept deep dives, then two pattern sets.

This course is not "System Design 101." If you need to learn what a load balancer is, what database replication means, or how message queues work, take our System Design Fundamentals course first. By the time you're here, you should already have the knowledge.

What you probably don't have - what most candidates don't have - is the ability to perform that knowledge under interview conditions. That's what we teach.

Over the next five modules, you'll learn:

Module 2: Must-Know Topics - A rapid-fire review of concepts, technologies, tradeoffs, and data structures you must know cold. Not deep explanations - just the interview checklist.
Module 3: Concept Deep Dives - The major topic areas (networking, caching, APIs, databases, distributed systems) reframed specifically for how they show up in interviews.
Module 4: Real-Time and High Traffic Patterns - The first pattern set: real-time updates, fanout, high read/write traffic, hot keys. These are the building blocks for designing social media feeds, messaging systems, and real-time dashboards.
Module 5: Scale and Reliability Patterns - The second pattern set: traffic spikes, large files, media streaming, location data, unique IDs. These are the building blocks for designing file storage systems, video platforms, and location-based services.

Each pattern is a reusable tool. You'll learn when to apply it, how to talk about it in an interview, and what tradeoffs to name. By the end, you'll have a toolkit of twenty patterns that can construct an answer to almost any system design question.

Tip: How to use this course: Don't read it like a textbook. Read it like a playbook. Before each mock interview or real interview, review the relevant patterns. Practice narrating your designs out loud - to a friend, to a rubber duck, to your bathroom mirror. The narration is the skill. The patterns are just the vocabulary.

Interactive animation: Practise narrating out loud, then let the practice portals interview you, score you and say what to fix.

Six Key Takeaways

System design interviews test thinking and communication, not just knowledge. Having the right answer is necessary but not sufficient.
The interview flows top-down: scope the problem, estimate scale, draw the high-level architecture, then go deep only where the interviewer directs.
Every design decision is a tradeoff. Name it explicitly. "The tradeoff here is..." is your most powerful phrase.
Communication is non-negotiable. Narrate as you draw. Silent design is invisible design.
Time management matters. Ten minutes on setup, thirty-plus minutes on design and deep dives.
The bar shifts with your level. What's impressive from a new grad is expected from a senior. What's impressive from a senior is expected from a staff engineer.

Exercises

Exercise: Exercise 1: Set a 5-minute timer. Without any prep, try to verbally explain the high-level architecture of any application you use daily (Instagram, Uber, Spotify). Record yourself. Listen back. How much dead air did you have? How often did you name a tradeoff?

Exercise 2: Pick any system you've worked on professionally. Write down three design decisions that were made and the tradeoff involved in each. Practice saying "The tradeoff here is..." for each one.

Exercise 3: Ask a friend to give you a random "Design X" prompt. Spend exactly 5 minutes scoping and estimating - no drawing allowed. Then assess: do you have enough constraints to start designing?

Resources

System Design Interview - An Insider's Guide (Alex Xu) - The standard reference book for system design interview preparation
Designing Data-Intensive Applications (Martin Kleppmann) - The deep technical foundation for distributed systems concepts
Amazon Bar Raiser Program Overview - Understanding how Amazon's interview process works from the inside
Grokking the System Design Interview (Educative) - A structured course with case studies and practice problems

Back to System Design Interviews