System Design Interview

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:

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

Top Ideas in This Book

Step 1: System design interview question intentionally open-ended. Ask clarifying questions to narrow the scope and align on requirements.
Step 2: Propose a high-level design and get buy-in
Step 3: Dive deep into the design, including rough calculations, system diagrams, and tradeoffs
Don’t worry much about specific technologies unless asked
Don’t spend much time on data models unless asked
Document back of the envelope calculations around peak traffic, usage, and data storage
Do not assume everything needs to be built from scratch
Suggest multiple approaches where possible and discuss tradeoffs
Practice diagramming systems and subsystems beforehand

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.