Courses › System Design › Getting Started

Introduction

What system design interviews test, how they are scored, and how to use this guide.

System design interviews ask you to design a real-world system — a URL shortener, a chat app, a ride-sharing service — in about 45 minutes, out loud, with an interviewer who will push on every decision. There is no single right answer. What's being evaluated is how you think: whether you can turn a vague problem into a concrete design, make sensible trade-offs, and go deep where it matters.

This guide teaches you to do that reliably. It's organized so you can read it in order or jump to what you need.

What interviewers are evaluating

Most companies score system design on some variation of four dimensions:

[!INTERVIEW] The level you're interviewing for changes the bar Mid-level candidates are expected to produce a working design with some guidance. Senior candidates should drive the whole conversation and proactively identify bottlenecks. Staff candidates should go deep on two or three areas and discuss trade-offs a senior engineer would miss — operational concerns, evolution of the system, organizational impact.

Why candidates fail

Interviewers see the same failure modes again and again:

  • Jumping into boxes and arrows. Drawing a load balancer before you know what the system does is the most common mistake. It signals you're pattern-matching, not designing.
  • Over-engineering early. Adding Kafka, sharding and a cache to a system that handles 100 requests per second wastes your limited time and hides the actual design.
  • Shallow buzzwords. Saying "we'll use Cassandra because it scales" without explaining the data model or access pattern invites a follow-up you can't answer.
  • Running out of time. Spending 20 minutes on requirements leaves no time for the deep dives where senior candidates earn their level.
  • Not listening. When an interviewer asks "what happens if two users book the same seat?", they're pointing you to the deep dive they care about.

See Common Mistakes for the full list, and What Interviewers Look For for how you're graded at each level.

How this guide is organized

  • Getting Started — the Delivery Framework is the most important page in this guide. It gives you a structure for every 45-minute interview. What Interviewers Look For and Common Mistakes tell you how that time is judged.
  • Core Concepts — networking, APIs, data modeling, caching, sharding, replication, consistency, consensus, indexing, reliability, security, observability, estimation and the numbers you should know.
  • Key Technologies — the handful of technologies that show up in almost every interview: Redis, Kafka, Elasticsearch, PostgreSQL, Cassandra and DynamoDB, plus MongoDB, Spanner, ClickHouse, SQS and RabbitMQ, Flink, Spark, ZooKeeper, Memcached, time-series and vector databases, graph databases, Temporal, Kubernetes, S3, Nginx and Envoy, data warehouses, and Bigtable for the deep dives that call for them. You don't need to know dozens; you need to know a few deeply — start with Choosing a Technology.
  • Patterns — recurring problems (real-time updates, contention, scaling reads and writes, large files, long-running jobs, multi-tenancy, zero-downtime migrations) and the standard solutions for each.
  • Question Breakdowns — full walkthroughs of the most common questions, showing exactly how a strong candidate would approach them.

[!TIP] Read, then practice out loud Reading designs creates an illusion of competence. After each breakdown, close the page, set a 45-minute timer and design the system yourself on a blank whiteboard. Then use the question library for questions you haven't seen.