Liu - System Design Interview Fundamentals

We are writing this book because we want to help people prepare for a system design interview. Studying for a system design interview is difficult because software engineering is deep and complex. There are a lot of engineering resources, but you only have so much time to prepare. Sometimes even if you understand one component deeply, the interviewer is more interested in something else.

We will not distract you with information that doesn't matter. For example, we will not copy and paste "Numbers Everyone Should Know" from Jeff Dean directly because, in a generalist interview, no one will ask about L1 cache reference being 0.5 ns, since that is on the microprocessor level. However, 150 ms for sending a packet halfway around the world is essential when youre designing a latency-sensitive globally distributed application.

In a system design interview, youre not looking to retell a design that you watched on a tech talk and read about on an engineering blog. Passing a system design interview is about having a solid understanding of the fundamentals of the building blocks and piecing them together using problem-solving skills.

When putting together the building blocks, you may have to dig deeper to address the critical bottlenecks. When you come up with a solution to a bottleneck, you may have made another component worse. Then you need to talk about options and trade-offs. And ultimately, you need to show leadership by making a final recommendation. System design is about understanding the problem youre trying to solve before coming up with a solution. It is not about coming up with a solution and finding a problem to fit into that solution.

Because of that, this book will focus intensely on the system design framework and the fundamental building blocks for system design interviews. We will present how to relate them to system interview questions for each of the fundamental building blocks. For example, instead of telling you an exact clarifying question you should ask the interviewer, we will provide information on the fundamentals of asking good questions. Instead of telling you about how a piece of technology works (you can just search it online), we will focus more on when, where, and why you can apply that technology. Knowing when and why to use the building block comes from experience and is harder to find online, and thats something we will be focusing on.

The system design interview framework will be long and detailed because its essential to get it right in a short 45-minute interview. In a 45-minute interview, you spend 5 minutes on the introduction and the last 5 minutes on questions and answers. You have approximately 35 minutes to demonstrate your design ability. It is important to ask the right questions and focus on the right things in such a short amount of time.

Instead of giving you a bunch of cookie-cutter responses to a system design interview question, we will focus more on the building blocks of the system design. So, instead of telling you how CDNs work, we will try to discuss what situations you should mention and what follow-ups you can talk about with CDNs. That way, you have a better fundamental understanding of the components. In addition, you will be more flexible in applying the fundamentals in similar situations for different problems.

On top of the fundamentals, we understand it is helpful to provide some guidance on what you can talk about for a given question. Please remember that this isnt the only path you can take in a system design interview. The more important takeaway is discovering the vital discussion points and structuring your answer to impress the interviewer. You should understand how the problems are solved instead of taking the solution to the perfect answer.

It is self-evident when a candidate has memorized a cookie-cutter solution without even identifying the problem. Whenever a candidate proposes a solution before the problem, the interviewers know theyve memorized the solution rather than thinking about the problem, and it doesnt help the interviewers to provide positive data points. When the interviewers dig deeper into the problem theyre trying to solve, the candidates fumble to find the problem and discover there wasnt a problem to be solved after all.

You are probably reading this book because you have a system design interview coming up, and you want to get the job. Before getting discouraged about the amount of information necessary to do well in a system design interview, it is important to keep in mind why you should care about system design.

The more senior you are in software engineering, the more system design matters for an interview and for your job. Even if you are an efficient coding ninja, coding to the wrong architecture will cost the company more money than if you hadnt code. System design interviews are weighted much more heavily the more senior you become. For most well-known companies, staff-level positions require multiple rounds of system designs.

Being good at system design helps you continue to climb the ladder as youre making a more significant impact on the overall business. Being more senior in an organization has a considerable bump in compensation as well. The annual total compensation difference between a senior engineer and a staff engineer can be between 150k and 200k US dollars. That requires you to do well in a system design interview.

Being good at system design allows you to see the overall picture of your companys architecture better. Remember when you were an entry-level engineer confused about some of the technical terms and wondering about the whys of technical decisions? It can be pretty frustrating. Having the proper fundamentals allows you to better connect the dots and gives you a sense of satisfaction. So invest in yourself now to pass the interview and become a better architect.

Before we jump into the perspective of an interviewer, we would like to step back and think about what the purpose of a system design interview is. Companies need to hire experienced engineers and experienced engineers provide value by coming up with reliable architectures.

To come up with reliable architectures, interviewers need to judge if youre able to take a well-defined set of requirements, find solutions, and make difficult decisions when faced with challenging trade-offs. This corresponds to a real-life situation at work where, for example, the product manager may give you some requirements and expect you to clarify the requirements and come up with an architecture to satisfy that product proposal.

The interviewer isnt looking for your ability to recall an architecture you read in a blog. What if the current company wants to offer an Instagram-like feature that is different from Facebooks Instagram with a different user base and query patterns? Doing well requires strong problem-solving skills, technical knowledge, and communication skills.