System design prep
Shared engineering interview prep. Treat this as a spoken word-problem plus whiteboard, not a FAANG “design Twitter at 100M QPS” exam. The interviewer is screening how you think out loud: what you notice, what you ask, what you refuse to guess, and whether you can draw a design that still holds when correctness matters.
For an Engineering Manager loop, they also want whether you can staff, sequence, and measure that design.
System Design School is useful as a vocabulary and method source. Their default problem set is consumer-scale. Use SDS to stay fluent; practice correctness-heavy boards as well as SDS problems by difficulty.
This site stays generic in System design. Company and market language lives in Domain.
How to run a mock
- Candidate opens only the problem’s prompt page.
- Interviewer uses only that problem’s interviewer page (plus Method if they need the clock).
- 45–60 minutes. Whiteboard or paper. Out loud.
Do not read the interviewer guide before you sit as the candidate, or you will recite boxes instead of discovering them.
| Problem | Kind | Notes |
|---|---|---|
| Webhook | SDS easy | Ack vs apply, event_id, HMAC |
| Rate limiter | SDS medium | Multi-tenant APIs, fail-open vs closed |
| Payment system | SDS hard | Provider cannot join your txn |
| Robinhood | SDS hard | Lossy quotes vs exactly-once ledger |
| Loan voting | Domain | Eligibility snapshot vs live progress |
| Reconciliation | Domain | Two ledgers; break is the product |
| Agent ingest | Domain | Golden source, adapters, honest lag |
Practice one full correctness board and a short ingest or webhook. Warm up on SDS webhook, then rate limiter, then payment/Robinhood if the real prompt might be generic. Do not draw two full systems in one hour.
Prep notes
| Page | Use |
|---|---|
| Cheatsheet | One-page SDS method + EM questions |
| Method | Primer, EM overlay, interview clock |
| Memorize | Small set to know cold |
| SDS | What to do (and skip) on System Design School |
| Practice | Drills and session loop |
| Ready | What “ready” feels like |
| Domain | Market, vocabulary, NFR defaults, proof stories |
What they are actually testing
| Surface | What “good” looks like |
|---|---|
| Word problem | You restate the outcome, name actors, ask what’s worse (stale / wrong / down / leaked), and write NFRs before boxes |
| Think-aloud | Every box is forced by a constraint. You say “I am not adding Kafka until we have a burst or a slow producer” |
| Whiteboard | 6–10 boxes, readable names, arrows with meaning (at-least-once, snapshot, authz on every read) |
| EM overlay | Who owns which box; v1 vs platform; definition of done; 2–3 KPIs; exec one-liner |
If you only draw a beautiful architecture, you look like a tech lead. If you only talk people and process, you look like a non-technical manager. Draw, then staff and measure.