System design interviews are rarely about “the right architecture.”
They’re about whether you can make good decisions with incomplete information and communicate them clearly.
Use this checklist to make sure you hit the signals interviewers are grading: scope, assumptions, numbers, trade-offs, and iterative refinement.
Before the interview (prep checklist)
- Pick 10 canonical prompts you can reuse (feed, chat, URL shortener, search, storage, rate limiter, etc.).
- Create a one-page template you’ll follow every time (more on that below).
- Practice out loud at least 6–8 times. Reading isn’t practice.
- Time your first 2 minutes. Most candidates lose the room early by rambling.
- Memorize a few “default numbers”:
- seconds/minute/hour/day
- rough QPS conversions (daily users → QPS)
- typical latencies (cache vs DB vs network)
- Prepare 3 trade-off pairs you can explain cleanly:
- Postgres vs DynamoDB (simplicity vs horizontal scalability)
- REST vs async queue (simplicity vs decoupling)
- Strong consistency vs availability (user experience vs failure tolerance)
In the interview (live execution checklist)
1) Start with clarifying questions (do not skip)
Ask 2–4 questions before you draw anything:
- Users/scale: “What scale are we targeting: 10k DAU or 100M DAU?”
- Workload shape: “Read-heavy, write-heavy, or mixed?”
- Latency goals: “Do we have a hard latency budget?”
- Consistency: “Is it okay if users see stale data for a few seconds?”
- Features: “What’s in scope for MVP vs stretch goals?”
If the interviewer won’t answer, state assumptions and move on.
2) State assumptions explicitly (and keep them editable)
Say it out loud:
“I’ll assume 1M DAU, peak 5k QPS reads, 1k QPS writes, and a 200ms p95 target. If that’s off, we can adjust.”
This is one of the strongest senior signals you can send.
3) Do a back-of-the-envelope estimate (rough is fine)
You’re not being tested on math. You’re being tested on whether you can reason about constraints.
Checklist:
- QPS (peak vs average)
- Data size (per record + growth)
- Bandwidth (request/response sizes)
- Storage (hot vs cold)
4) Define the core entities and APIs
Before components, define the “shape”:
- Core objects (User, Item, Message, Post, Order…)
- Primary API calls (create, read timeline, search, update)
- Key indexes / query patterns
This prevents an architecture that can’t answer the actual question.
5) Draw the high-level architecture (one clean diagram)
Keep it minimal:
- Client → API Gateway / Load Balancer
- App service(s)
- Primary datastore(s)
- Cache
- Queue/stream (if needed)
- Background workers
Label each box with what it does (not just the name of the technology).
6) Walk the happy path end-to-end
Pick one critical flow and narrate it:
- request comes in
- auth/validation
- read/write path
- cache behavior
- response
If you can’t walk it, the diagram is not real yet.
7) Identify bottlenecks and failure modes
Checklist:
- Cache stampede (many misses)
- Hot keys / uneven load distribution
- DB contention (locks, slow queries)
- Queue backlog
- Partial outages (one dependency down)
- Rebuild scenarios (cache warm-up, replay)
Say:
“Here’s what breaks first, and here’s what I’d do next.”
8) Name trade-offs (explicitly)
Most candidates describe one design. Strong candidates compare.
Checklist:
- Option A vs Option B
- What you gain
- What you lose
- What would make you switch later
Example:
“I’d start with Postgres for speed of iteration and correctness. If write volume or partitioning becomes painful, I’d move the write path to a sharded store and keep Postgres for relational queries.”
9) Iterate with the interviewer
Invite pushback:
- “If we need 10x scale, I’d change X first.”
- “If we need stronger consistency, I’d accept Y cost.”
- “If the requirement is offline support, we’d add Z.”
This turns the interview into a collaborative design review.
10) Close with a summary (30 seconds)
Checklist:
- restate the goal
- restate assumptions
- final architecture in one sentence
- next 2 improvements you’d do with more time
Common failure modes (quick self-audit)
- You didn’t ask questions → you solved the wrong problem.
- No numbers → you can’t justify choices.
- No trade-offs → you sound junior, even with senior knowledge.
- Overbuilding → you designed for 10 years instead of 6 months.
- Diagram without a walkthrough → it’s not grounded in reality.
- You never adapted → you’re defending a plan, not solving a problem.
The “one page” system design template (copy/paste)
- Goal + success metric
- Assumptions (scale, latency, consistency)
- Rough estimates (QPS, storage, bandwidth)
- Entities + APIs
- Architecture diagram (minimal)
- Happy path walkthrough
- Bottlenecks + failure modes
- Trade-offs + why this design
- Scaling plan (next steps)
- Summary
If you follow this every time, you’ll stop losing points to missing structure—and you’ll start sounding like someone who has actually designed systems in production.
Explore Related Topics
- Agentic Workflows System Design Interview Guide
- Complete Guide to Uber Software Engineer Interviews (2026)
- Palantir Advanced Interview: From Gotham to Metropolis