System design interviews have a brutal pass rate at top tech companies — roughly 30-40% even among experienced engineers. The failure mode is almost always the same: candidates skip straight to drawing boxes. They hear "Design Twitter" and immediately start talking about microservices, Kafka, and sharding — before understanding what they're actually building.

Consider what the interviewer sees from the other side of the table. When a candidate jumps straight to solution mode, it signals a critical engineering weakness: they can't gather requirements. In real engineering, requirements gathering is the most important skill. A system built for the wrong requirements is worthless, regardless of how technically sophisticated it is.

The second most common failure is poor time management. Candidates spend 30 minutes on requirements and run out of time before drawing a single diagram. Or they over-engineer one component — spending 20 minutes designing the perfect database schema — while never discussing the hard parts: caching, sharding, failure modes.

The third failure is forgetting that system design interviews are collaborative. They're not a test where you write an answer and hand it in. The interviewer wants to have a technical conversation. They'll drop hints. They'll push back. Candidates who ignore this and monologue for 45 minutes miss the collaborative signal entirely.

The good news: system design interviews are learnable. Unlike coding interviews where you either know the algorithm or you don't, system design follows a repeatable process. Learn the 4-step framework and the time budget, and you can design any system competently — even systems you've never built.

The most valuable thing you can do in the first 5-10 minutes of a system design interview is ask questions. Not design questions — requirements questions. You need to understand what you're building before you can design it.

There are two types of requirements you need to uncover: functional requirements (what the system does) and non-functional requirements (how well it does it). Most candidates only ask about functional requirements. Senior engineers ask both.

For a concrete example, let's say the interviewer asks "Design a news feed system like Facebook." Before drawing anything, you should ask:

A good requirements conversation might take 8 minutes. The interviewer is watching you closely during this time. They want to see: Do you think systematically? Do you cover both functional and non-functional? Do you set scope before designing?

The number you absolutely must establish before moving on: DAU (daily active users) or MAU (monthly active users). This single number drives every capacity estimate. If you don't get this number, make an assumption and state it clearly: "I'll assume 10M DAU — is that in the right ballpark?"

One of the clearest signals that separates L5+ candidates from L4 candidates at FAANG is understanding the difference between functional and non-functional requirements — and spending as much time on non-functional as functional.

Functional requirements answer: What does the system do? Non-functional requirements answer: How well does it do it, and under what constraints? Non-functional requirements are often more important for architecture because they determine which trade-offs to make.

Availability is frequently misunderstood. "99% availability" sounds great until you realize that's 3.65 days of downtime per year. "99.9%" is 8.76 hours. "99.99%" is 52 minutes. "99.999%" (five nines) is 5 minutes. The difference between 99.9% and 99.99% is an order of magnitude more complexity and cost.

Consistency requirements determine your database choice more than anything else. If the interviewer says "users can see slightly stale data" — you have enormous flexibility: Redis, Cassandra, DynamoDB with eventual consistency. If they say "never show stale data, every user must see the same thing" — you need strong consistency, which means distributed coordination, which is expensive and slow.

graph TD
    A[Non-Functional Requirements] --> B[Availability SLA]
    A --> C[Consistency Model]
    A --> D[Latency Targets]
    A --> E[Scale Requirements]
    B --> F{99.99%?}
    F -->|Yes| G[Multi-AZ, Auto-failover]
    F -->|No| H[Single region OK]
    C --> I{Strong consistency?}
    I -->|Yes| J[PostgreSQL, MySQL with sync replication]
    I -->|No| K[DynamoDB, Cassandra, Redis]
    D --> L{Sub-100ms p99?}
    L -->|Yes| M[Cache everything, CDN at edge]
    L -->|No| N[Standard caching OK]
    E --> O{> 100K QPS?}
    O -->|Yes| P[Horizontal scaling, sharding]
    O -->|No| Q[Vertical scaling, read replicas]

Capacity estimation is where most candidates either impress or fall flat. The goal isn't to get exact numbers — it's to get numbers in the right order of magnitude, fast, while showing your reasoning. A ±2x error is fine. A ±10x error will lead you to design the wrong system.

The formula is always the same: DAU × Requests/User/Day ÷ 86,400 seconds = average QPS. Then multiply by 2-3x for peak. Let's walk through it for a Twitter-like system.

For a Twitter-like system at 100M DAU:

These numbers immediately tell you architectural things: 700K reads/sec is far beyond what a single database can handle (a well-tuned Postgres tops out around 50K QPS). You need caching, read replicas, or a NoSQL database. 6TB/day of images means you need CDN and object storage (S3), not local disk.

After requirements and estimation, you draw the boxes. The goal of the high-level design isn't to draw every component — it's to draw the critical data flows clearly and show that you understand which components need to exist and why.

Start with the client. Work your way to the data store. Draw every component your system absolutely needs: the client, the load balancer, the application servers, the cache layer, and the database. Label the connections. Show the direction of data flow with arrows.

graph LR
    C[Client
Mobile/Web] --> LB[Load Balancer]
    LB --> A1[App Server 1]
    LB --> A2[App Server 2]
    LB --> A3[App Server N]
    A1 --> CH[Cache Layer
Redis Cluster]
    A2 --> CH
    A3 --> CH
    CH --> DB[(Primary DB
Postgres)]
    DB --> R1[(Read Replica 1)]
    DB --> R2[(Read Replica 2)]
    A1 --> Q[Message Queue
Kafka]
    Q --> W[Worker Services
Async Processing]
    W --> OS[Object Storage
S3]
    OS --> CDN[CDN
CloudFront]
    CDN --> C

There are five components that should appear in almost every system design:

Once you have the basic components drawn, add the component that's specific to the problem. For a news feed: fan-out service. For a URL shortener: hash generation service. For a payment system: idempotency layer. This is where you demonstrate domain knowledge.

After drawing the diagram, narrate the main user request flow. Walk the interviewer through a typical request: "A user opens the app. The request hits the CDN first — if the static assets are cached, they're served from the edge. The feed request goes to the load balancer, which routes it to any available app server. The app server checks Redis for the user's pre-computed feed. Cache hit: return the feed in ~5ms. Cache miss: query the feed service, which aggregates posts from the user's follows, writes back to Redis, and returns the result in ~100ms."

sequenceDiagram
    participant U as User
    participant CDN as CDN
    participant LB as Load Balancer
    participant App as App Server
    participant Redis as Redis Cache
    participant DB as Database

    U->>CDN: GET /feed (static assets cached)
    CDN-->>U: Static assets (5ms)
    U->>LB: GET /api/v1/feed
    LB->>App: Route to available server
    App->>Redis: GET feed:user_123
    alt Cache Hit
        Redis-->>App: Return cached feed (1ms)
        App-->>U: 200 OK + feed (~10ms total)
    else Cache Miss
        App->>DB: SELECT posts FROM follows (complex JOIN)
        DB-->>App: Raw posts (50ms)
        App->>Redis: SET feed:user_123 TTL=5min
        App-->>U: 200 OK + feed (~80ms total)
    end

The deep dive is where you earn the offer at senior levels. This is where you pick the hardest part of your design and explain exactly how it works, including the failure modes and trade-offs. Most candidates skip this or do it superficially.

Before diving in, ask the interviewer: "What would you like me to deep-dive on?" They usually have something specific in mind. If they say "it's up to you," pick the bottleneck that will cause the most pain at scale — usually the database, the cache invalidation strategy, or the most write-heavy component.

For a news feed, the deep dive target is usually fan-out: how does a tweet from a celebrity with 10M followers get delivered to all their followers' feeds without killing your system?

A strong deep dive doesn't just describe what you'd do — it describes the failure modes and how you handle them. For fan-out on write: what happens when Elon Musk tweets? 130M followers × write operation = massive write spike. The hybrid approach handles this, but you need to define the threshold for "celebrity" and handle the edge case where a user becomes a celebrity mid-session.

Time management is the most underrated skill in system design interviews. A 45-minute interview can feel like forever and vanish in seconds. Without an explicit time budget, most candidates accidentally spend 20 minutes on requirements and never finish the design — or race through requirements in 2 minutes and design the wrong system.

Here is the exact time allocation used by candidates who consistently pass FAANG system design interviews:

Interviewer signals to watch for during the interview: If the interviewer says "interesting, tell me more about that" — they want you to deep-dive into that component. If they say "let's move on" or "I think we have enough there" — they want to cover more ground. If they say "what would happen if..." — that's a failure mode question, answer it directly.

One more time tip: narrate your thinking out loud during transitions. When you switch from requirements to estimation, say "Okay, I have enough context — let me now estimate the scale." This signals to the interviewer that you're intentionally moving between phases, not wandering.

FAANG system design interviews aren't graded on a binary pass/fail — they're scored on multiple dimensions, and the hiring committee calibrates them against level expectations. Understanding the rubric changes how you should approach the interview.

Amazon, Meta, Google, and Apple all use roughly similar evaluation criteria, though the exact language differs. Here are the four core dimensions and what each looks like at different levels:

The most important signal at L6 is proactive trade-off discussion. L4 candidates wait to be asked "what are the trade-offs?" L6 candidates say "I'm choosing fan-out on write for normal users because the 5ms read latency benefit outweighs the write amplification for the 99th percentile user — but I'm consciously accepting that celebrity accounts will need special handling, and here's how I'd do it."

One more thing: FAANG interviewers write a detailed write-up after your interview that goes to the hiring committee. They're evaluating not just whether your design was correct, but how you'd behave as an engineering partner. Were you collaborative? Did you listen? Did you handle pushback gracefully? Would they want to work with you on a design review?

After analyzing hundreds of system design interviews, the same anti-patterns appear over and over in candidates who get rejected. These aren't obscure gotchas — they're patterns that experienced engineers recognize immediately as signals of junior thinking.

The counter-signal FAANG interviewers love: "For this scale, a single PostgreSQL instance with proper indexing will handle the QPS with headroom. I'll add Redis for the hot-path reads. I'd move to a distributed solution if we hit 10x this scale, but I'd design for what we need today and make migration straightforward."

The most important meta-lesson: system design interviews test engineering judgment, not trivia. Interviewers aren't looking for the one perfect answer. They're looking for an engineer who thinks systematically, quantifies their decisions, acknowledges trade-offs honestly, and would be a good partner on a design review. That's a learnable set of behaviors — not innate talent.

graph TD
    Start[Hear the Problem] --> R[Clarify Requirements
5-10 min]
    R --> E[Capacity Estimation
5-10 min]
    E --> H[High-Level Design
10-15 min]
    H --> D[Deep Dive
15-20 min]
    D --> W[Wrap-Up
3 min]

    R --> R1[Functional Requirements]
    R --> R2[Non-Functional: CALS]
    E --> E1[DAU → QPS formula]
    E --> E2[Storage calculation]
    H --> H1[Draw 5 universal components]
    H --> H2[Narrate request flow]
    D --> D1[Pick the bottleneck]
    D --> D2[Mechanism + failure mode]
    W --> W1[Key decisions made]
    W --> W2[Trade-offs acknowledged]