CodePark/ questions / Approaching a design interview
START PRACTICINGPRACTICE
Backend question · System design & architecture › Approaching a design interview

You are given 45 minutes to "design a system". Walk through the steps you would follow and roughly how you would spend the time.

Follow a fixed order: requirements, estimates, API and data model, high-level design, deep dives, then trade-offs.

1. Clarify requirements (a few minutes). Ask about:

  • the core features in scope
  • who the users are
  • the non-functional needs: scale, latency, availability and consistency

Non-functional needs describe how well the system must work, not what it does.

2. Do a quick back-of-envelope estimate. This is a rough calculation on paper. Estimate traffic, storage and bandwidth. The numbers give you reasons for your design choices later.

3. Sketch the API and the data model. Do this before you draw boxes.

4. Draw a high-level design. Show these parts:

  • clients
  • a load balancer
  • services
  • data stores
  • caches
  • queues

5. Deep dives (the largest block of time). Go deep into the two or three hardest parts. These are usually the parts the interviewer steers you toward.

6. Finish with the weak spots. Name the bottlenecks, the failure modes and the trade-offs. Say what you would change at 10x scale.

Throughout the interview:

  • think aloud
  • state your assumptions
  • check in with the interviewer often, so you don't get lost in detail
  • Clarify the functional and non-functional requirements first.
  • Estimate the scale: QPS (queries per second), storage and bandwidth.
  • Define the API and data model before you draw boxes and arrows.
  • Draw the high-level design, then do deep dives on the hard parts.
  • Close with bottlenecks, trade-offs and how the system grows.