Interview playbook
The structure every practice session follows, the questions to open with, and the mistakes that cost people offers.
The 45-minute structure
| Stage | Time | Goal |
|---|---|---|
| Requirements | 5 min | Clarify functional requirements (what the system must do) and non-functional ones (scale, latency, availability, consistency). State what is out of scope. |
| Back-of-envelope estimates | 5 min | Estimate QPS (read and write), storage over 5 years, bandwidth and cache size. Show the arithmetic. |
| API design | 5 min | Define the core endpoints, their inputs, outputs and error cases. |
| Data model | 5 min | Define the main entities, keys, indexes, and pick a storage technology with a reason. |
| High-level design | 10 min | Draw the main components and the request flow for reads and writes. Keep it simple first. |
| Deep dives | 10 min | Pick the 2–3 hardest parts (bottlenecks, hot paths, failure modes) and go deep. |
| Trade-offs & wrap-up | 5 min | Summarise the key decisions, what you gave up, and what you would do with more time. |
Questions to open with
- Who are the users and what are the top 2–3 actions they take?
- What is the expected scale: DAU, requests per second, data volume?
- Read-heavy or write-heavy? What is the ratio?
- Latency and availability targets? Is eventual consistency acceptable anywhere?
- What is explicitly out of scope for this session?
Common pitfalls
- Jumping to components before clarifying requirements. Spend the first five minutes asking questions.
- Designing for 1B users when the interviewer said 10K. Scale the design to the numbers you agreed on.
- Naming technologies ("use Kafka") without saying what problem they solve. Say the property you need first.
- Staying silent while drawing. Narrate every box and arrow; the conversation is the assessment.
- Avoiding trade-offs. Every choice has a cost; say what you gave up and why that is acceptable.
- Ignoring failure. Ask yourself "what breaks first?" for every component on the hot path.
- Treating estimates as a formality. They should change your design (e.g. 3 TB fits a single sharded DB).
What separates levels
- Mid: produces a working design with a cache, a database and a load balancer, and can explain the request flow.
- Senior: drives the conversation, identifies the bottleneck without prompting, compares options and commits with reasons, and handles failure modes.
- Staff: reasons about evolution over time, operational cost, migrations and organisational constraints, and knows when the simple answer is the right one.