Since 2015, I am attending interviews as an interviewer for recruiting new talents, for the selection of new partner companies etc. And since 2019 I am conducting interviews for my current company. The topics I interview for are usually General Tech and Culture Fit. I enjoy also system design and thought I can also help our company by taking over a few System Design Interviews hence I started to prepare myself for the next step. I saw “System Desing Interview: An Insider’s Guide” by Alex Xu is suggested for interviewees to prepare for upcoming challenges so I thought I should give it a shot to sharpen my skills and understanding of the system design domain.

The book starts with the basics like designing for scaling, back of the envelope calculations then suggests a framework for system design and provides 12 different system design examples. I took some notes and also recorded some resources to read further.

Let’s look into the suggested framework for system design. It’s a four-step framework and actually, I found it quite useful to have such a structure.

1. Understand the problem and establish design scope
2. Propose a high-level design and get buy-in
3. Design deep dive
4. Wrap-up

Time allocation suggested by the author per step is

1. 3 – 10 minutes
2. 10 – 15 minutes
3. 10 – 25 minutes
4. 3 – 5 minutes

This time allocation would allow a candidate to complete a design in around 50 minutes and would provide some additional time for Q&A in a 60 minutes interview. From my perspective suggested framework and time allocations would work in an interview setup.

Let me summarize each step with one paragraph, then I can provide my thoughts, notes and feedback about the book.

Understand the problem and establish design scope

Nobody would expect you to design the new Facebook or Netflix in the short time of an interview. So asking clarifying questions, setting up the boundaries of design and noting down the assumptions are the way to start the design. All those steps should be discussed with the interviewer, get their ideas about the important parts of the system to design and get their approval on the assumptions.

Propose a high-level design and get buy-in

This is the step where the interviewee should lay the foundations of the system and provide a blueprint with the collaboration of the interviewer. Doing some back of the envelope calculations and depending on those calculations system size and components should appear on the design. This step should not include details like data format yet but should have a storage layer for example.

Design deep dive

This is the time to think about handling the load, choosing the correct data store, scaling the API servers etc. Depending on the discussion with the interviewer, you should focus on a few key areas and deliver a detailed design and even a few implementation details if required.

Wrap up

In this last step, you should go the extra mile and tell about the flaws in your design and how it may be improved, what can be expected to change in the business in the future and how the design can evolve to cope with those changes.

My notes and thoughts about the book

• There are some mistakes or not so best-practices in the book e.g.
  • Author claims NoSQL should be chosen to store massive amount of data, this is open for discussion. A technology selection should not be justified only by data size but also use cases and requirements.
  • In one of the API design sections, author does not follow the REST best practices and uses verb in the URL
  • Author claims a scale-up would not help with the load, in my experience it helps.
• Back of the envelope numbers are great shortcuts during the design time.
• There is an unfortunate use of magic number in the book while calculating peak system load. There is no explanation of why we use this factor to multiply our assumption.
• 12 different system design examples backed by real life resources are really handy and informative.
• There are some missing information, for example author says “token bucket is memory efficient” but does not explain why and how. Or while discussing quorum of a distributed system author overlooks possibility of a Byzantine Fault.
• Reference materials are useful, almost every section I noted down some of the reference materials to read further.
• In some designs there are security flaws which may cause data leak, which have been overseen. Though this can be defended as security is not in the scope and time is short. Still I believe security should start in the design phase.
• Also in some designs sections, author does not follow the framework they suggested.

All in all, I got some fresh ideas and a good framework for system design interviews from the book. I would consider recommending this book to mid-level engineers who are looking for different aspects of system design and would use a few real-life examples. For me, a 10+ year engineer, the advantages of reading this book was limited.

Thanks to Alex Xu for putting all the effort and collecting those examples in a well-structured format. And thank you for reading this blog post, feel free to comment or share this post if you find it useful.