The Modern System Design Interview Guide

01Introduction

The system design interview format has barely changed in five years. The bar for passing has changed dramatically.

If you're prepping with material written before 2024, you're prepping for the wrong rubric. The questions look familiar. The grading does not. Cost reasoning, operational maturity, and AI-aware design have moved from "nice to have" to table stakes. Most prep guides haven't caught up. This one starts there.

What you'll find in this guide:

• What system design interviews actually look like in 2026, and what's different from three years ago
• A four-step framework for working through any system design problem under time pressure
• Deep treatments of the technical concepts that show up over and over
• The question patterns currently in rotation at FAANG and FAANG-tier companies
• An explicit breakdown of what interviewers grade and what they don't

This guide is written for senior and staff engineers preparing for FAANG-tier loops, mid-level engineers stepping up to senior, and engineers returning to interviews after a few years away. It is not for absolute beginners. If you're starting from zero, our companion guide on learning system design will serve you better.

Use the table of contents below to jump in. Read straight through if you have eight weeks. Skim the framework and FAQ if you have one weekend.

If you're prepping with material from before 2024, you're prepping for the wrong rubric.

03Who This Guide Is For

System design interview preparation is not one-size-fits-all. The depth you need, the topics you'll be tested on, and even the framework you'll use shift depending on the level you're targeting and the experience you bring in. This section is here to help you self-qualify before you commit eight weeks to the rest of the guide.

If you recognize yourself in any of the four profiles below, this guide is built for you.

Senior engineers preparing for FAANG-tier loops

This is the primary audience. If you have roughly five to ten years of professional experience and you're targeting senior-level roles (Meta E5, Google L5, Amazon SDE 3, equivalents at Stripe, Airbnb, Netflix, Uber), the entire guide is calibrated for you. The framework, the concept depth, the question patterns, the rubric breakdown: all of it assumes you'll be evaluated against the senior bar.

You should expect one or two system design rounds in your loop, with a meaningful weighting toward your overall packet. At this level, system design performance often determines whether you get an offer at all, regardless of how well your coding rounds went.

Mid-level engineers stepping up to senior

If you're in a mid-level role (three to five years of experience) and interviewing for a senior position at a level above your current one, this guide will work but you'll need to read with extra attention to the operational and judgment sections. The technical-depth bar may be familiar to you. The communication, tradeoff defense, and operational maturity expectations are usually what trip up engineers stepping up.

Specifically, expect interviewers to test whether you can drive a 45-minute conversation rather than just answer it. That's the senior signal they're looking for, and it's the one most level-up candidates underestimate.

Engineers returning to interviews after a few years away

If you last interviewed in 2021 or earlier, the field has moved meaningfully. The framework is similar. The graded rubric is not. Section 5 (What's Changed in 2026) is the most important section for you to read carefully. Skim everything else, but read that section twice.

The most common failure mode for returning candidates is preparing using the same material that worked the last time and walking in technically prepared but rubric-mismatched.

Staff and principal candidates

If you're targeting staff (Meta E6, Google L6, equivalents) or principal-level roles, this guide is a useful foundation but not sufficient on its own. Staff-level system design rounds expect you to surface non-obvious constraints, reason about cross-system implications, identify risks the interviewer didn't think of, and demonstrate the kind of operational fluency that comes from running production systems at scale.

Use this guide to build the foundation, then go deeper through case studies of real production systems and through mock interviews specifically with staff-level interviewers. The framework here scales up; the depth expectations do not stop where this guide stops.

04What a System Design Interview Actually Is

Every guide on this topic starts with a paragraph defining the system design interview. Most are vague. Here is what one actually looks like in 2026, in concrete terms.

The format

A system design interview is a 45 to 60 minute conversation in which an interviewer asks you an open-ended question ("Design Twitter," "Design a rate limiter," "Design a vector search service for a RAG application") and watches you work through it. There is no single right answer. There are better and worse approaches, and the interviewer's job is to evaluate yours.

The format is almost universally remote in 2026, conducted over video with a shared whiteboard. The most common tools are Excalidraw, Miro, in-platform whiteboards built into interviewing services like CodeSignal or HackerRank, and increasingly Google's own internal tools for Google loops. You will rarely use pen and paper. You should be comfortable diagramming with a mouse or trackpad before your first real interview.

AI assistants are not permitted during the interview itself. This is enforced inconsistently but assume it is enforced strictly. The systems you design, however, are increasingly assumed to include AI components. The contradiction is real.

What you do during the hour

Every interview has a rough shape. The exact timing varies, but the structure is consistent across companies:

• Minutes 0-5: Clarification. The interviewer poses the question. You ask follow-ups. You're trying to scope the problem: what features matter, what scale, what constraints. Strong candidates spend more time here than weak candidates.
• Minutes 5-10: Estimation and API. Back-of-the-envelope calculations for QPS, storage, bandwidth. Sketching the API surface. This step grounds the rest of the conversation.
• Minutes 10-25: High-level design. Boxes and arrows. Five to seven major components. The interviewer is watching your pattern recognition and your willingness to commit to a structure.
• Minutes 25-45: Deep dives. The interviewer picks two or three components and asks you to go deeper. This is where most loops are won or lost. Senior candidates volunteer the deep-dive areas; junior candidates wait to be prompted.
• Minutes 45-55: Stress testing and tradeoffs. What happens at 10x scale? What if a region goes dark? What's the cost? What's the operational burden? In 2026, this section is heavier than it was three years ago.
• Final 5 minutes: Your questions. Use them well. The questions you ask reveal as much as the design you drew.

What's drawn versus what's spoken

You will draw constantly. Boxes for components, arrows for data flow, labels for protocols and message types. The interviewer evaluates the diagram and the verbal narration together. Neither alone is sufficient.

What gets drawn: components, connections, data flow direction, deployment regions, replication topology, occasionally pseudocode for a critical algorithm. What stays verbal: tradeoff explanations, alternatives you considered, why you committed to a particular choice, what would change at different scale points.

The biggest mistake candidates make: spending too much time polishing the diagram. The interviewer does not care that your boxes are aligned or your arrows are straight. They care that the diagram communicates the design clearly. Rough is fine. Slow is not.

What the interviewer is doing

While you design, the interviewer is doing three things in parallel: tracking your decisions against an internal rubric, identifying areas to probe deeper on, and calibrating their feedback to push you toward the parts of the problem they want to evaluate. They are not silent observers. They will interrupt with questions, push back on choices, occasionally hint when you're stuck. Their interruptions are signal, not noise.

Specifically, when an interviewer says "tell me more about how you'd shard this," they're not asking out of curiosity. They've decided that sharding is the area where they want to test your depth. The fastest way to lose a loop is to deflect that question or answer it shallowly. The fastest way to do well is to recognize the question as a depth invitation and accept it.

What gets evaluated

The interviewer is not evaluating whether you got the "right" answer. They're evaluating four things: your judgment under ambiguity, the depth of your technical understanding, your communication clarity, and your operational maturity. Section 9 (What Interviewers Actually Grade) goes into detail on each.

Importantly, they are also evaluating things that are not technical at all: how you handle being wrong, how you incorporate feedback, whether you can disagree productively, whether you panic under pressure. These signals matter as much as the technical content. A technically perfect design delivered defensively will lose to a technically imperfect design delivered collaboratively. Companies hire for the latter.

05What's Changed in 2026

Three things shifted between 2023 and 2026. Each one is small on its own. Together, they raised the depth bar enough that a candidate prepping with a 2022 playbook will walk into a 2026 loop, design a technically correct system, and still get a "lean no hire" two days later with no idea why.

Here is what changed.

The cost-reasoning shift

A few years ago, you could propose any architecture and as long as it scaled in theory, you were fine. "We'd add more servers" was an acceptable answer to capacity questions. In 2026, senior loops at Meta, Google, Amazon, and Stripe grade cost reasoning explicitly. If you propose a multi-region active-active deployment for a small consumer app and don't acknowledge the cost implications, you've revealed something about your judgment that the interviewer will mark down. Right-sizing matters. So does knowing when not to scale.

The operational-maturity shift

Observability. Deployment strategy. On-call burden. Rollback paths. These were nice-to-have bonus topics for staff candidates two or three years ago. They are now graded explicitly at senior level. If you finish a 45-minute design loop and never said the words monitoring, deployment, or rollback, you left points on the table whether or not your architecture was correct.

This shift comes from inside the calibration meetings hiring managers run. Companies got tired of hiring engineers who designed clean systems but couldn't operate them. The rubric updated to filter for both. You won't find this shift documented in older guides because it postdates them.

The AI-aware design shift

This is the biggest shift, and the one most prep material is silent on. "Design a recommendation system" used to mean collaborative filtering, ranking models, and a feature store. In 2026, it often means embedding pipelines, vector stores, RAG flows, and serving an LLM-generated layer on top. "Design a chat application" used to be about WebSockets and message ordering. It now often includes "and a generative summary feature for missed conversations."

If you don't bring up the AI layer, the interviewer will. Your silence is the answer.

Newly mainstream topics on the rubric include vector databases (pgvector, Pinecone, Weaviate), embedding pipelines, LLM gateways and rate limiting, retrieval-augmented generation patterns, semantic caching, prompt-templating infrastructure, and the operational concerns that come with all of this: token costs, latency budgets for LLM calls, fallback strategies when the model is degraded.

The bottom line

If you're prepping with material from before 2024, you're prepping for the wrong rubric. The good news is that the shifts are recoverable. The bar moved up, but it didn't move away. If you understand what changed, you can prep for it. The rest of this guide is built around what's actually true now.

06The Four-Step Framework

Every strong system design candidate has an internal framework. Not because frameworks are clever, but because 45 minutes is not enough time to figure out the structure of the conversation while also designing the system. The framework runs in the background. It keeps you from freezing.

What follows is a four-step framework that maps to how interviewers actually think about the conversation arc. You will see other versions of this framework with three steps, five steps, even seven. They are not wrong. They are reorganizations of the same underlying moves. Pick one. Practice it until it's automatic. Then forget you're using it.

Overview

The four steps, in the order you'll use them:

1. Clarify and scope. Functional requirements, non-functional requirements, scale estimates. The first 5 to 10 minutes.
2. Data and API. What gets stored, what gets sent over the wire. The next 5 to 10 minutes.
3. High-level design. Boxes and arrows for the major components. The middle 15 to 20 minutes.
4. Deep dive and stress test. Two or three components in depth, then walk the design through failure modes. The final 15 to 20 minutes.

Each step below covers what to do, why it matters, and the most common mistakes at that step. For worked examples that walk a real question through all four steps end-to-end, see the full framework page.

Why this framework works

The framework is not magical. It works because it matches the conversational arc the interviewer is already running internally. They are checking, in this order: did the candidate scope the problem (Step 1), did they ground the design in concrete data and APIs (Step 2), did they commit to a high-level structure with defensible choices (Step 3), and could they go deep without breaking down (Step 4).

If you run the framework, the interviewer's evaluation tracks alongside your work. If you skip steps or run them in a different order, the interviewer has to mentally reconstruct what step you're on, which costs them attention they could be spending on the actual content.

The framework is the boring part. The framework keeps you from freezing. What gets you hired is what you do inside each step.

What's different about running this framework in 2026

Two adjustments compared to how the framework was taught two or three years ago.

First, in Step 1 (Clarify), the questions you ask should now include AI considerations when the question allows. "Is generative content in scope? Are we serving an LLM-powered feature on top of this? What's our latency budget if there's a model call in the hot path?" These are 2026-native clarifying questions. Asking them signals current-era awareness.

Second, in Step 4 (Stress Test), cost reasoning is now expected at senior bar. After walking through failure modes, walk through cost. "At this scale, the dominant cost is X. If we wanted to cut that by half, the lever I'd pull is Y." That sentence used to be optional. It is now part of the rubric. See Section 5 for the full picture of what changed.

07Technical Concepts You Need

System design interviews test breadth and depth at the same time. You need to recognize roughly ten concept families on sight and be able to go deep on three or four of them under pressure. The list below is not encyclopedic. It's the set of concepts that show up over and over in 2026 loops, organized by where they sit in a typical architecture.

Each concept gets a brief introduction here. For the deep treatments (when to use each option, the failure modes, the math, the anti-patterns), follow the link into the corresponding page in the concept library.

How these concepts map onto a typical interview

Most 45-minute loops will touch four or five of the concepts above. The traffic tier (load balancing, caching) and at least one data tier concept (databases, sharding, or replication) appear in nearly every loop. The modern tier increasingly appears whether the question mentions AI explicitly or not, because interviewers are now coached to probe AI-readiness.

If you study these ten and go deep on any three, you'll have something useful to say about almost any question. If you only memorize names without going deep, you will be exposed in the deep-dive phase, which is where most loops are decided. Step 4 of the framework is where this depth shows up under evaluation.

Two concepts understood deeply beats five concepts mentioned shallowly. Always.

08Common Question Patterns

System design questions look infinite from the outside but reduce to a small number of patterns. Once you've worked through one of each pattern, the rest become recognizable variations. The goal of this section is to map the patterns, not to enumerate every possible question.

Most questions you'll see in 2026 fall into one of four categories. Two are classics that have been on the SERP for a decade. Two grew significantly in weight over the past two years and now appear in nearly every senior loop, regardless of role. Each card below names the pattern, lists representative questions, and tells you what the question is actually testing.

How to use these patterns in your prep

If you're prepping from scratch, work through one question from each of the four categories rather than five from the same category. Pattern recognition forms across categories, not within them. The candidate who has done four different patterns once each will outperform the candidate who has done one pattern eight times.

If you have a target company, look up their typical question types (these vary somewhat by company) and weight your prep accordingly. Meta and Google both lean heavily on classic product designs at senior level. Stripe and Uber tend toward correctness and operational questions. AI-first companies (OpenAI, Anthropic, Mistral) are now using AI-adjacent questions as the primary system design round, with the classics as warm-ups.

Whatever you study, study out loud, in 45-minute timeboxes, against a real or simulated whiteboard. Section 4 covers the format expectations; Section 6 covers the framework you should run through every question regardless of category.

The candidate who has done four different patterns once each will outperform the candidate who has done one pattern eight times.

09What Interviewers Actually Grade

This is the section most candidates skip and most interviewers wish more candidates had read. The rubric is not what most prep material implies it is. The interviewer is not grading whether you got the "right" answer. They are grading four specific things, and the weight of each shifts depending on the level you're targeting.

Once you internalize the rubric, your prep changes. You stop optimizing for the wrong things. You stop spending hours memorizing classic designs and start spending hours practicing tradeoff defense out loud. The shift is not subtle. It often determines whether the candidate passes.

The four buckets

Every modern rubric I've seen, across FAANG, FAANG-tier, and most well-run startups, decomposes into four buckets: judgment, depth, operational maturity, and communication. The labels vary slightly by company. The substance is consistent.

What changes between levels is the weighting, not the buckets. Senior loops weight judgment and depth heavily; operational maturity is graded but not as central. Staff loops shift the weight toward operational maturity and communication, because at staff level, technical depth is assumed and what differentiates is the ability to drive cross-system reasoning. Principal loops weight communication and operational maturity even higher, because principal candidates are expected to influence direction, not just answer questions.

Each bucket below covers what's being evaluated, what strong candidates do, and what weak candidates do. If you internalize one section of this guide deeply, internalize this one.

What's not graded

This is the part of the rubric most candidates get wrong. The following list is not exhaustive but covers the most common over-prepped areas that have surprisingly little weight in actual grading:

• Memorizing classic designs. Knowing how Twitter or Uber actually works is helpful for pattern recognition. Knowing it well enough to recite is wasted prep. The interviewer is not checking your memory.
• Knowing every NoSQL database. You should be able to pick one, defend the choice, and discuss tradeoffs. You do not need to enumerate Cassandra versus DynamoDB versus ScyllaDB versus FoundationDB versus CockroachDB. Encyclopedic recall is not the rubric.
• Drawing pretty diagrams. The diagram needs to be readable. It does not need to be aligned, color-coded, or symmetrical. Time spent polishing is time not spent on content.
• Estimating with perfect math. Rough numbers, defensible orders of magnitude, and explicit assumptions matter. Exact calculations to three decimal places do not. "About 100K QPS" is fine. "Approximately 97,432 QPS" is performative.
• Naming every technology you've heard of. Vocabulary is not depth. Three concepts you can defend in detail beats fifteen concepts you can spell.
• Following the framework rigidly. The framework is scaffolding. If the interviewer takes the conversation in an unexpected direction, follow them. Sticking dogmatically to "but we haven't done estimation yet" when the interviewer wants to dig into a specific component is a flexibility failure.

Most candidates over-prep on these and under-prep on judgment, operational maturity, and communication. The shift in prep weight is the single highest-leverage change you can make this week.

How this maps to your prep

If you take the rubric seriously, your prep starts to look different from what most guides recommend. Less time on memorizing reference architectures. More time on tradeoff defense out loud. Less time on listing technologies. More time on going three layers deep on three specific components. Less time on watching mock interview videos passively. More time on running mock interviews actively, with someone pushing back on your choices.

If you have eight weeks, allocate roughly: 30% on building conceptual depth, 30% on framework practice with the four buckets in mind, 30% on mock interviews, 10% on reading other people's worked solutions. If you're spending more than 20% of your time reading and less than 25% practicing out loud, your prep is misweighted relative to the rubric.

The rubric is not what most prep material implies it is. Once you internalize what's actually being graded, your prep changes.

10How to Use This Guide

This guide is long. It's not meant to be read in one sitting unless you're cramming. Below are four reading paths based on how much time you have and what you're trying to accomplish. Pick the one that matches your situation.

Each path lists the sections to read in order, with rough time estimates. Stop when you're out of time, but make sure you've at least covered the sections marked as essential.

If you're not sure which path to use

Default to the path closest to your timeline, then adjust based on three factors. First, your prior experience: if you've done system design interviews recently, you can compress the conceptual sections. If you haven't, give them more time. Second, your target level: senior loops weight judgment and depth, so prioritize Section 6 and Section 7. Staff and above weight operational maturity and communication, so give extra time to Section 9. Third, your weak areas: if you know where you're weak, weight your prep there rather than re-strengthening what's already strong.

Whatever path you choose, the highest-leverage activity in any of them is mock interviews with another engineer. Reading guides without practice is the most common failure mode. The FAQ covers more on prep strategy.

The single highest-leverage activity in any prep path is mock interviews with someone who currently interviews at your target level. Reading guides without practice is the most common failure mode.

11Common Mistakes to Avoid

The five mistakes below sink more otherwise-strong candidates than any technical knowledge gap. They are not depth failures. They are pattern failures, and they show up across loops at every company we've talked to about this. None of them require new prep to fix. They require attention to behavior under pressure.

If you read no other section the morning of your interview, read this one.

The pattern underneath these mistakes

If you read these five mistakes carefully, you'll notice they share a structure. Each one represents a candidate optimizing for the wrong signal. Speed instead of judgment. Sophistication instead of right-sizing. Safety instead of commitment. Coverage instead of depth. Cleanliness instead of operational reality.

The fix for all five is the same: stop optimizing for what feels like the right signal and start optimizing for what's actually being graded. Section 9 covers what's actually being graded. The mistakes above are the most common ways candidates miss it.

Each of these mistakes represents a candidate optimizing for the wrong signal. The fix is the same: stop optimizing for what feels like the right signal and start optimizing for what's actually being graded.

12Frequently Asked Questions

Quick answers to the questions engineers most often ask before their loop. For deeper treatment of any of these, follow the links into the relevant sections.

13Next Steps

You've reached the end of the hub. The page covers what's true about system design interviews in 2026, the framework you'll run on every question, the concepts and patterns you'll be tested on, and what's actually graded. The rest of the work happens through the deep-dive pages and through your own practice.

Three places to go from here:

Whichever path you pick, the highest-leverage activity in any of them is mock interviews with another engineer. Reading is preparation. Speaking is practice. The two are not interchangeable, and most candidates spend too much of their prep time on the first.

If you'd rather follow a structured course

This guide and its deep-dive pages are sufficient for self-directed prep. Some engineers learn better through structured courses with built-in practice problems and graded solutions. If that's you, one option worth considering is Grokking the System Design Interview, which covers the same conceptual ground as this guide with worked solutions to classic questions and a pattern-based teaching approach.

It is not required. The guide here covers what you need to know. But if you've tried self-directed prep before and bounced off, structured material with built-in practice loops is worth the investment for some learners.

One last thing

The framework, the concepts, the rubric, the mistakes. All of it matters. None of it matters as much as practice. The candidates who pass system design interviews are not the ones who read the most. They are the ones who designed out loud, under time pressure, against pushback, until pattern recognition formed. Reading prepares you. Speaking gets you hired.

Now go practice.

The candidates who pass are not the ones who read the most. They are the ones who practiced out loud until pattern recognition formed.