A method for system design interviews

What the interview tests

A system design interview checks how you think with an open, ambiguous problem: do you clarify, structure, make reasoned trade-offs, communicate and adapt when the interviewer pushes back. There is no single right answer; there are well-reasoned and poorly-reasoned ones.

The 45-minute plan

100%

Figure SDA-INT-01-1 · A time plan for the interview · © forcsguy.com

1. Clarify (functional and non-functional)

• Functional: what must the system do? Pick the top three to five features and say what you leave out.
• Non-functional: scale (users, requests), latency, availability, consistency needs, durability, security, cost, regions.
• Constraints: platforms, existing systems, deadlines.
• Write the agreed list where both of you can see it.

2. Estimate

Turn the scale into numbers: daily active users, actions per user, requests per second (average and peak, often 2 to 3 times average), read to write ratio, storage per day and over years, bandwidth. Use round numbers and show your arithmetic (see the estimation lesson). Say what the numbers imply: "about 5,000 reads per second means one database with a cache is plausible; 500,000 means we shard and use a CDN."

3. High-level design

Draw the main components and data flow for the core use cases: clients, load balancer, services, databases, caches, queues, storage. Define the APIs and the main data entities. Keep it simple and correct first; do not add Kafka because it sounds good.

4. Deep dive

Go deeper where it matters or where the interviewer points:

• Data model and storage choice and why (see the databases lessons).
• The hot path: how a request is served fast (caching, indexing, precomputation).
• Scaling a bottleneck: sharding key, replication, fan-out.
• Consistency and failure handling: what happens when a node, region or dependency fails; retries and idempotency.
• Specific algorithms if central (rate limiting, ranking, geospatial search, unique ids).

5. Wrap up

Name the bottlenecks and single points of failure, how you would monitor the system, security and privacy, cost, and what you would do next with more time. Summarise the trade-offs you chose.

Habits of strong answers

• Think aloud and check in: "Is this the direction you want?"
• Start simple, then scale: a working design first, evolve it as numbers demand.
• Justify each choice with a reason tied to a requirement; offer alternatives and why you did not choose them.
• Quantify: use your estimates to decide.
• Be explicit about trade-offs: consistency versus availability, latency versus cost, simplicity versus flexibility.
• Handle failure: every box can break; say what happens.
• Use the interviewer's hints; they are guiding you.

Common mistakes

Mistake	Better
Jumping to technology names	Start from requirements and numbers
Designing for imaginary scale	Design for stated scale, and say how you would grow
No estimates	Compute the key numbers and use them
One giant box labelled "backend"	Break into components with clear responsibilities
Ignoring failures and consistency	Discuss what breaks and what guarantees you need
Going shallow everywhere	Go deep on two or three important parts
Memorised answer for a different problem	Adapt to this problem's requirements
Silence	Talk through your reasoning

Low-level design interviews

The same spirit applies but at class level: clarify, find entities, assign responsibilities, relate them, apply patterns where useful, code the core flow and discuss extensions (see the Low-Level Design Practice course).

Preparing

1. Learn the building blocks (the foundations and core courses).
2. Study classic designs end to end (classic and real-world courses).
3. Practise out loud with a timer and a friend, or record yourself.
4. Read engineering blogs of the company you are interviewing with to learn their technology and concerns.
5. After each practice, write what you missed and revisit the lesson.

Real-world reading