FAANG System Design Interview Checklist (Senior Edition)

What and Why

The system design interview at senior level is not about the right answer. It is about how you frame an ambiguous problem, drive a discussion under constraints, surface trade-offs the interviewer cares about, and make decisions that hold up to follow-up questions. Junior candidates explain how Kafka works. Senior candidates decide whether Kafka is the right call given the workload.

This checklist is what I use when coaching engineers, and what I look for when conducting interviews.

Mental Model

A 45-minute interview is a budget. You spend it across five phases, in roughly fixed proportions. The mistake new candidates make is to spend 30 minutes on requirements and run out of time for the interesting design. The mistake mid-level candidates make is to start drawing boxes in minute three. Senior candidates pace themselves.

0          5             15                    30                40        45
|          |              |                     |                  |        |
| Reqs &   | Estimations  | High-level Design   | Deep Dive +      | Wrap   |
| Scope    | & Constraints| (boxes, data flow,  | Trade-offs       | + Q&A  |
|          |              |  API)               | (1-2 components) |        |
+----------+--------------+---------------------+------------------+--------+

Architecture

The phases:

1. Requirements and scope (5 min). Functional and non-functional. Read users, write users, latency targets, consistency, geographic distribution. Ask: what is in scope, what is explicitly out. Write the constraints in a corner of the board; they anchor every decision later.
2. Estimations (5-10 min). QPS, data volume, storage growth, bandwidth. Two significant figures, justified out loud. The interviewer cares less about the exact number than about whether your design fits the order of magnitude.
3. High-level design (10-15 min). Boxes and arrows. Clients, edge, services, data stores, async pipelines. Define the data model in a sentence. Sketch the API (3-5 endpoints). This is the moment to commit to a topology.
4. Deep dive and trade-offs (10-15 min). Pick one or two components and go deep. Show the interviewer how you think when constraints meet reality. This is where senior signal lives.
5. Wrap-up and Q&A (5 min). Summarize the design, call out what you did not have time for, propose what you would do next.

Trade-offs

The interview is a structured way of letting you display engineering judgment. The trade-offs you should be ready to discuss for almost any system:

• Consistency vs availability. Linearizable writes vs eventual consistency. Where in your design does each apply?
• Push vs pull. Fanout-on-write vs fanout-on-read. Polling vs websockets. Pre-compute vs on-demand.
• Caching layers. Where, what TTL, what invalidation strategy, what happens on cold cache.
• Sharding and partitioning. Key choice, hot keys, rebalancing strategy.
• Async vs sync. Where you cross the boundary, and what users experience when the async path lags.
• Read vs write optimization. Most consumer systems are 100:1 read-heavy. Most internal systems are not. Match the design to the ratio.
• Failure modes. What happens when each box dies. Not “we have monitoring.” How does the system degrade.

Anti-patterns to avoid:

• Naming a database without justifying why. “Postgres” is not a design choice; “Postgres because we need transactional consistency for billing and the volume is under 50TB” is.
• Skipping the data model. The schema is half the design.
• Ignoring the interviewer’s nudges. When they ask “what if you have ten million users”, that is not a quiz; that is a hint to deep-dive scaling.
• Drawing every microservice in your past job. Stay scoped to the problem.
• Quoting buzzwords without trade-offs. “We use Kafka” is half a sentence; the other half is “because we need replay and 100k events/sec, and we accept higher operational complexity.”

Practical Tips

1. Clarify before designing. “Is this a global product or a single region?” “Do users edit posts after publishing?” Five clarifying questions in the first three minutes save you ten minutes of redesign later.
2. Talk while you draw. The interviewer evaluates your reasoning, not your boxes. Narrate the choice as you make it.
3. Be opinionated, then concede. “I would use Kafka here because of replay needs. RabbitMQ would also work; I prefer Kafka given the scale we estimated.” Confidence with humility is the senior register.
4. Estimate at the right granularity. 100M DAU at 5 actions/day is 500M actions/day, ~6k actions/sec average, ~60k peak. Round numbers, justify in your head, write them down.
5. Cover the unhappy path. Failures, retries, idempotency, dead letters. Most candidates skip this; it is the easiest way to stand out.
6. Manage the clock visibly. “I want to deep-dive on the feed ranker; we have about 12 minutes left.” Shows the interviewer you are pacing.
7. Avoid premature optimization. Don’t shard the database in minute eight. Build the simple thing, then break it on purpose with growth.
8. Have a default stack. Know one good answer for each layer (CDN, gateway, async messaging, OLTP, OLAP, cache, search). You can deviate, but a default speeds you up.

A starter API sketch for any service:

POST /v1/{resource}    -> create (idempotent via Idempotency-Key)
GET  /v1/{resource}/{id} -> read
GET  /v1/{resource}?cursor=... -> list (cursor pagination, not offset)
PATCH /v1/{resource}/{id} -> partial update
DELETE /v1/{resource}/{id} -> soft delete

Brings cursor pagination, idempotency, and soft delete into the conversation without you having to mention them as afterthoughts.

Wrap-up

A senior system design interview is a conversation about engineering trade-offs disguised as a whiteboard exercise. The interviewer wants to see how you scope, estimate, choose, and defend. Budget your time, ask before drawing, be opinionated about choices, and walk through the failure modes. Practice with a clock. Practice talking out loud. Most candidates know the building blocks; what distinguishes seniors is the judgment about when to assemble which ones, and the calm to say “I would not do that here, and here is why.”