A Framework for System Design Interviews

System design interviews simulate real-life collaborative problem-solving. Questions are open-ended — no single right answer. The final design matters less than the process. The interviewer assesses: technical design skills, collaboration, working under pressure, resolving ambiguity, and asking good questions.

Red flags: Over-engineering, narrow-mindedness, stubbornness.

A 4-step process #

Step 1 — Understand the problem and establish design scope (3–10 min) #

Ask clarification questions before proposing solutions. Key questions:

• What specific features are we building?
• How many users? Anticipated scale in 3/6/12 months?
• Company's technology stack? Existing services to leverage?

Example (news feed system):

• Both mobile and web app
• Core features: make a post, see friends' news feed
• Feed sorted by reverse chronological order
• Max 5,000 friends per user
• 10 million DAU
• Feed can contain media (images, videos)

Step 2 — Propose high-level design and get buy-in (10–15 min) #

• Sketch initial blueprint, ask for feedback
• Draw box diagrams: clients, APIs, web servers, data stores, cache, CDN, message queue, etc.
• Do back-of-the-envelope calculations to validate against scale constraints
• Walk through concrete use cases to discover edge cases

Example (news feed): Two flows — feed publishing (post → cache/DB → populate friends' feeds) and newsfeed building (aggregate friends' posts in reverse chronological order).

Step 3 — Design deep dive (10–25 min) #

With interviewer, identify and prioritize components. Focus varies: senior candidates may discuss bottlenecks/resource estimation, others dive into specific components (hash function for URL shortener, latency for chat system).

Avoid: Getting lost in minute details. Time management is critical.

Example (news feed): Deep dive into feed publishing and news feed retrieval.

Step 4 — Wrap up (3–5 min) #

• Identify system bottlenecks and potential improvements (never say design is perfect)
• Recap your design
• Discuss error cases (server failure, network loss)
• Operation issues: monitoring metrics, error logs, rollout strategy
• Next scale curve (1M → 10M users)
• Propose refinements given more time

Dos and Don'ts #

Dos:

• Always ask for clarification — don't assume
• Understand requirements
• Let the interviewer know what you're thinking
• Suggest multiple approaches if possible
• Design critical components first after agreeing on blueprint
• Bounce ideas off the interviewer
• Never give up

Don'ts:

• Don't be unprepared for typical interview questions
• Don't jump into solution without clarifying requirements
• Don't go deep on one component initially — high-level first
• Don't hesitate to ask for hints if stuck
• Don't think in silence
• Don't think you're done once design is given — ask for feedback early and often

Time allocation (45-minute interview) #