Prepare for Your Google Interview Systems Design
Today, we will cover communication, designing with scale in mind, concrete and quantitative solutions, how you manage trade-offs and compromises and overall best practices. But before we jump into the core focus areas of this interview, here are a few things to note: You will not be coding in this interview. There will also be significant time constraints. We’ll expect you to gather requirements and to develop an initial solution in the first 20 minutes. So please be sure to use your time wisely. Communication is incredibly important in the work we do at Google. And that’s because it’s key to how we approach developing and building our products. In your interview, it’s important to demonstrate those qualities. Understanding a problem and designing a solution are both valuable parts of the interview process. We want you to think out loud. We don't just want to see the final answer.
Furthermore, we want to understand how you arrived at it. Google is a collaborative workplace where projects are planned and executed by teams. Those teams have a mission to work together to solve big, often ambiguous problems. And those problems can have multiple valid solutions. So, tell us how you plan to solve those problems, and be sure to ask questions. And remember: we’re not looking for one specific answer. The problem you will solve during your interview will be deliberately underspecified. We leave those questions open-ended because real problems require you to dig deeper. You will need to ask clarifying questions. At Google, we deal with planet-scale data and compute systems every day. Our applications serve a global user base. Simply identifying a solution is just the beginning. A solution must be scalable enough to reach a wide audience, reliable enough to meet our users' needs, and still make efficient use of our resources. During this interview, we’ll be assessing you on your ability to design systems that scale. Questions you may want to keep in mind include: How can we tell that the system is working? Is there a bottleneck in the design? If there are multiple components, what are the APIs and how do they work together? How can we provide great service to users all around the planet? And long gone are the days when everything you design could easily fit onto a single machine. So, we may give you a large data set to work with and ask you to explain how it can be sharded among multiple worker machines. Or we may present you with a request which can be answered by any one of a pool of machines and ask you to identify the fastest machine and discard the rest. You should also be prepared to discuss system component properties such as latency, throughput, and storage. We want to see numeric estimates for these properties, such as how many requests per second the system can handle. Also be prepared to provide clear justification of how the design backs up these numbers. Our systems impact users across the globe. We need engineers who can solve real world problems concretely and quantitatively. So when designing, you should always consider reality and the laws of physics. You should also have a general idea of the costs and latencies of various operations such as: read from disk, read from memory, local area network round-trip, and cross-continental network.
During your interview, you will have access to a whiteboard. You can use this to estimate the resources needed to run your system or to diagram your proposed design. You should know industry solution patterns like sharing data, replication types, write-ahead logging, separating data and metadata storage, and basic kinds of load distribution. As a systems designer at Google, you will have to make trade-offs and compromises. In your interview, we’ll ask you to identify systematic shortcomings and describe how the system responds to various failures. We want you to lay out the trade-offs and compromises you made and explain your reasoning. Do you store data on a rotating disk and pay less money for the storage at the cost of increased latency? Or do you put the data on a flash drive where you’re able to retrieve it quickly but pay more money? These are questions that could come up during your interview. We’re looking for systems designers that can consider multiple solutions, commit to one, and then iterate on it. Now that you have the focus areas, here are some overall best practices to keep in mind for your actual interview day. We want to understand how you think, so it’s important to explain your thought process during the interview. We’re not only evaluating your technical ability but also how you solve problems. Many questions will be deliberately open-ended to give us an idea of how you solve technical problems. We encourage you to ask for clarification. And we all know that our first solution may not be the best one. So, once you’ve come up with an answer to a question, think about ways to improve upon it and let your interviewer know what you’re thinking. And lastly, practice on paper or a whiteboard. During the interview you may not have access to resources you normally use. And those are our tips to help you prepare for a systems design interview at Google!