Chapter 6 System Design Interviews (Part II) - The Complete Guide to Google Interview Preparation

Chapter 6 System Design Interviews (Part II) - The Complete Guide to Google Interview Preparation This is the sixth chapter of our The Complete Guide to Google Interview Preparation series. Well continue our discussion about system design interviews from last chapter. In this post, well mainly focus on some practical on-site strategies. Assuming youve already had a somewhat reasonable design (if not, check our previous chapter), the idea here is how to maximize the results in a system design interview. How to clearly communicate your approach is both a science and an art. Also, many candidates are too eager to show off their knowledge and tend to use some buzzwords that make no sense in the current scenario. Well address all these problems and red flags in this chapter. Simple, High-level solution Systems that are simple, straightforward and efficient really win. One good example is Unix that is built from small components, each of which does only one thing but makes it perfect. Im always a big fan of systems like this and from the system design interviews perspective, it also makes your life easier. Some people really want to show off that he can design something complicated and would just start with an overly complicated system. This is the completely wrong mindset. What interviewer cares is not what cool technology youre using, but whether you can design a system that works. Ive seen so many candidates that kept saying all kinds of buzzwords without thinking about the question for seconds. You know what, I think those buzzwords are just bullshit and please forget about it in interviews. The recommended approach is to start with something as simple as possible and try to design a high-level solution. If you are asked to design Google autocompletion system, you can just start from suggesting the most common queries with the given prefix so that all you need is a log processor and a suggest server. Of course, the solution wont work in many cases like sometimes we need personalization and the data may exceed memory limit. Then we can prioritize the problems and address one by one. Never shoot yourself in the foot by over-complicating the problem. Dont Rush A common pitfall in coding interviews is to start coding without much consideration and discussion. The same problem happens in system design interview as well. Remember that no one would expect you to come up with a design within seconds. See the whole interview process as a discussion rather than an exam. If its a discussion, you are encouraged to think loudly. You dont need to point out a solution quickly, but you can talk about how you think about the problem, what you are trying to solve at the moment and what you are stuck with. As an interviewer, candidates that I would give strong hire usually make the whole interview process very comfortable. Its completely a discussion process and its like we are working on the problem together. They wont pretend to know everything. Instead, they will always tell me what they are stuck with and how they are approaching the problem. Trade-offs Theres no one solution that works perfectly in all scenarios, which means you should be very clear about pros and cons of your design. Remember that your solution highly relies on the restriction, which can be both explicit and implicit. Explicit restrictions are ones set by the interviewer like you have only one machine. However, most people dont pay attention to implicit restrictions. A lot of times we are just making assumptions without knowing. Uncovering those hidden assumptions can help you better understand your solution. For example, time and space trade-off is a common theme in design problem. At some point, its okay to be a little bit slow but you can save a lot of memory. If you have a clear reason that speed is not important in particular circumstances, your design is reasonable. A good practice is to think about what alternative approaches are and why the approach you picked is better. Usually, the reason its better is due to some constraints and assumptions. So its important to validate those assumptions. Changing your mind during the interview is completely okay. In fact, its a good sign that you are considering all scenarios. Numbers Many people are confused about whether to consider scalability and whether to distribute the data to multiple machines. Sometimes you wont know if a single machine is enough unless you do some math. For example, in the previous question (Google autocompletion), if you have the rough number of all the search queries, you should be able to tell how much memory you need and if its feasible to put all indexes in memory. In other words, sometimes whether to scale or not is not told by the interviewer. You can get the answer by making reasonable assumptions and do the calculation. This is a very important point because in real projects, good engineers are making a lot of decisions in this way. And this certainly needs some practices. “There are some libraries out there” One common pitfall is that many candidates like to tell me “there are some libraries to do this out there” as an excuse to not design this function in detail. Do interviewers know there are existing libraries? Of course. But there are many reasons why it makes sense to ask candidates to design particular functions as well: Existing libraries might not do a good job. For example, a lot of libraries are able to extract date information from web pages, but none of them does it perfectly. In fact, just this feature itself can be a big team in many companies. There might be better solutions given the particular problem with constraints. In the end, there are existing systems for every design questions but it still makes sense to discuss the problem. However, Im not suggesting that you should never use any existing tools in system design interviews. What the design question is focused on matters. If its a common tool or something trivial comparing to the overall question, its completely fine to use existing tools. Summary Again, in system design interviews, the experience just beats everything. Its not easy to come up with reasonable designs if you have zero experience with the problem. As I said earlier, if you have enough time, I would encourage you to build something in spare time. Also, discussing with experienced engineers is also recommended. If youve never done this kind of discussion, how can you expect yourself to perform well in an interview? Even for tips in this chapter, you certainly need a lot of practice and dont expect to grasp all of them in your first system design interview. Also, if you want to have more guidance from experienced interviewers, you can check Gainlo that allows you to have mock interviews (both system design and general coding interviews) with engineers from Google, Facebook etc..