Books for software engineers and managers

System Design Interview

System Design Interview

An Insider's Guide

by Alex Xu

Tech Lead,
Star Engineer

How strongly do I recommend System Design Interview?
7 / 10

Review of System Design Interview

System Design Interview details how to design 16 real-world systems. I was amazed at how many of the systems covered in this book that my Engineering team at TrainHeroic has built and continuously scaled:

  • RESTful APIS
  • Notifications
  • Chat
  • Search autocomplete
  • News feed
  • Video processing

In other words, while interviewing is the obvious application of this book there are actually three use cases:

  1. Preparing to interview for Architect, Full-Stack, or Backend Engineering roles
  2. Building scalable systems in your current job
  3. Teaching your engineers how to document systems you’ve already built

Step 1: System design interview question intentionally open-ended. Ask clarifying questions to narrow the scope and align on  requirements.

Start by ensuring you understand the problem and expectations that the interviewer has for the system. Nothing is worse than making undocumented assumptions.

Step 2: Propose a high-level design and get  buy-in

You’ll be tempted to start diving into the details. Don’t do that.

Get buy-in on a high level design, then explore more details. By aligning on a high-level design you demonstrate your ability to manage stakeholders and shine light on assumptions.

The best way to use a high-level design is by walking through critical user flows. For instance, if you were designing YouTube, a critical user flow would be uploading video. Another would be serving video.

Step 3: Dive deep into the design, including rough calculations, system diagrams, and  tradeoffs

Break down your high level design into smaller components. Focus on diagramming the flow of data through the system.

Don’t worry much about specific technologies unless  asked

It’s okay to just mention and diagram the type of technology, not specific implementation details. For instance, you don’t need to say which specific key/value store you would use. That would probably be too granular for this interview.

Don’t spend much time on data models unless  asked

I’ve made this mistake before – spending too much time on data modeling and relationships. That’s what I thought system design was.

But system design is more about the components that come together to deliver a holistic solution to a technical problem. The reach goes beyond data modeling.

Document back of the envelope calculations around peak traffic, usage, and data  storage

Candidates would be served well to have their phone handy for calculations.

When making rough calculations, rather than averages try to focus on peaks: peak queries per second, peak users per minute, etc.

Do not assume everything needs to be built from  scratch

Some components like a CDN are super complex and you’d never build yourself. You can usually just draw a bubble around them and keep the implementation details out.

Suggest multiple approaches where possible and discuss  tradeoffs

By suggesting multiple approaches, you demonstrate creative thinking skills and a stronger understanding of the tradeoffs between areas like simplicity/complexity and performance.

Practice diagramming systems and subsystems  beforehand

For many engineers, diagramming may not feel comfortable. Our jobs don’t always require it of us. But in a system design interview diagramming is a primary means of communication and you should practice diagramming systems that you haven’t previously built.

One common tactical mistake is to diagram things so small that you don’t allow for new components to be added that would increase scalability, like caches and queues.

System Design Interview