What Is a System Design Interview?
In a system design interview, a candidate designs a large software system from a short, open question like "Design YouTube" or "Design a rate limiter." The candidate turns that question into a design. It covers the components, how data moves between them, where data is stored, and how the system behaves when it grows or fails. The interview usually lasts 45 to 60 minutes and has no single correct answer.
How It Differs from Other Interviews
A coding interview tests whether a candidate can write a correct, efficient function. An object-oriented design interview tests whether a candidate can structure classes for one program. A system design interview operates at a larger scale where the units are services, databases, caches, and queues rather than functions and classes.
| Coding | Object-oriented design | System design | |
|---|---|---|---|
| Example question | Merge k sorted lists | Design a parking lot | Design WhatsApp |
| Unit of design | Function | Class | Service, database, queue |
| What is tested | Correctness, complexity | Class structure, interfaces | Architecture, data flow, scale, trade-offs |
| Output | Code | Class diagram and code | Architecture diagram and discussion |
The system design question is intentionally open because part of the test is figuring out what to build before building it.
What the Interviewer Evaluates
The interviewer evaluates how the candidate thinks rather than checking for a memorized diagram. Most rubrics cover five areas:
- Requirements: the candidate asks questions to define the scope before designing.
- Design: the chosen components are reasonable and each one serves a clear purpose.
- Scale: the candidate identifies what breaks as load grows and updates the design to handle it.
- Trade-offs: the candidate compares options and accounts for the cost of each choice.
- Communication: the candidate explains the design clearly and responds to hints.
Expected depth depends on seniority. A mid-level candidate must produce a working design that scales. A senior candidate must also identify the hardest part of the problem and examine it in depth. A staff candidate must reason about failure modes, operations, and alternatives across the entire system.
The table below shows how expectations in each area grow with level. It serves as a general guide, since each company defines its own rubric and level names.
| Area | Mid-level | Senior | Staff |
|---|---|---|---|
| Requirements | Asks questions and agrees on a short feature list | Also finds the constraints that change the design, such as the read-to-write ratio | Also finds which requirement makes the problem hard, and defines a very open problem |
| Design | Reaches a working design; each component serves a requirement | Also finds the hard part of the problem and designs for it | Also keeps the design simple to build and to operate |
| Scale | Finds the main bottleneck and fixes it, sometimes with a hint | Finds bottlenecks without hints and goes deep on one or two | Also reasons about failure modes across the whole system |
| Trade-offs | Names the cost of each main choice | Compares options and picks one for the requirements | Also defends the choice when a requirement changes |
| Communication | Explains each step and responds to hints | Drives most of the discussion | Leads the discussion and works with the interviewer as a peer |
The Steps of an Interview
Most interviews follow the same sequence. The candidate defines the requirements, estimates the load, specifies the interface, draws an initial design, and refines the parts that fail at scale.
Most of the evaluation happens during the deep dives. A high-level design that works for a few users is the starting point, not the result. The Interview Template lesson explains each step and its timing.
What a Design Contains
A design answers three questions about the system:
- Services: which programs handle requests and what each one owns.
- Data flow: how a request moves through the services, including which steps happen at once or later.
- Storage: where each kind of data lives—such as a database, cache, or object storage—and why.
The diagram below shows these three parts in a small system, with dashed lines indicating the requirements that add a part.
Non-functional requirements drive most of these choices. A system that must stay available during failures needs copies of each part, while a system that must answer fast needs a cache. The Non-functional Requirements lesson covers these in detail.
Why It Is Hard to Prepare
Few engineers build systems at this scale in their daily work, and few university courses teach it. Public material often lists components without explaining the reasons behind them. This leads candidates to memorize designs and technology names, which fails on a question they have not seen.
A better method is to learn why each component exists. Each part of a large system addresses a specific failure: a cache speeds up repeated reads, a queue absorbs slow writes, and a shard splits data that exceeds one machine. A candidate who understands the failure can select the right fix for a new problem.
How This Course Is Organized
This course builds the design vocabulary first and then applies it to full problems in the solutions.
| Section | What it teaches |
|---|---|
| Introduction | The interview, the core challenges of large systems, the master template, estimation, API design, and availability |
| Microservices and Data Flow | How services call each other, and how they handle failures and slow work |
| Scaling Services | Load balancing, caching, and read and write paths |
| Data Storage | How databases store data, and how to choose one |
| Scaling Data Storage | Replication and partitioning |
| Big Data | Batch and stream processing |
| Patterns and Templates | Reusable designs that appear across many problems |
The lessons use interactive widgets to show mechanisms that change over time, such as a queue filling during a traffic burst. Change the inputs and watch the system fail, then apply the fix. The solutions then show how these building blocks combine into complete designs.
Key idea. Each component in a design fixes a specific failure. A cache fixes slow repeated reads, a queue fixes slow writes, and a shard fixes data that does not fit on one machine. Because non-functional requirements determine which failures matter, they drive most of the choices in a design.