This is the fifth chapter of our The Complete Guide to Google Interview Preparation series.
From Gainlo‘s survey, system design interview is the No.1 thing people are afraid of. It’s not unique to Google interview preparation, but all companies in general.
Part of the reason is that system design questions are usually open-ended so that there’s no such thing as a standard answer. In addition, this problem also makes preparation hard because you won’t know if your solution works.
Let’s address all these problems in this chapter. I’ll briefly explain how system design interview is evaluated first, then I’ll provide practical tips about both preparation and interview strategy.
What Is System Design Interview?
For people who are new to this topic, I’ll briefly explain this. For most top companies like Google, Facebook, Uber and so on, at least one of the onsite interviews will be system design interviews.
In this interview, you will be asked to design a particular system and have an intense discussion with interviewers about all the details. However, since the question is quite open-ended, interviewers can decide whatever direction the discussion will go to. With that in mind, even for the same question, you may have a completely different discussion with different interviewers.
That’s also the reason I never worry about if the interviewee has seen the question before. Let’s take the question “Design a web crawler” as an example. As an interviewer, I can make the interview focused on the overall crawler infrastructure, I can discuss how to dedup URLs in detail, and I can also ask how to detect if a page has been updated.
It’s also possible that you will be asked to write down some code in a system design interview. But I don’t see too much difference from general coding interviews and we won’t cover this part in this chapter as you can refer to our previous chapters.
How Is System Design Interview Evaluated?
I’m a strong believer that if you can’t measure it, you can’t improve it. Most people have no idea how system design interview is evaluated, how could they prepare for it? It’s like you are playing a game without knowing the rule.
Unlike coding interview, system design questions have no standard answers so that the evaluation process is more subjective. However, there are still certain things I will look for as an interviewer.
First and foremost, I’ll evaluate if the design actually works. Although there’s no implementation to verify that, based on work experience and some common sense, I would ask myself if I would try the proposed approach if given this problem. More often than not, it’s quite obvious to tell if the design is problematic and I’ll just use some examples to challenge the candidate. For example, if I ask him to check if an URL has been crawled before, I’ll see if the solution handles short URL like t.co/xyz or URLs with UTM params. This is the bare minimum requirement. If the candidate can’t make it work, I won’t go deeper or I may switch to a separate question.
Secondly, I would check feasibility. Some candidates will come up with solutions that only work in theory. It may require infinite memory or the system is unnecessarily complicated. In either case, I will ask him to fix it. A good way to verify this is to ask yourself how much time and how many engineers do you need to implement this design. Personally, I prefer designs with ease and simplicity. If you can’t make a prototype within one or two weeks, I might ask you to simplify it.
Sometimes, a candidate would come up with a complicated solution that requires a huge amount of data with a couple of ML components and pipelines. It’s hard to implement this in reality because it’s just risky. You don’t want to spend a year on this unverified idea that that potentially just won’t work.
Thirdly, I expect the candidate to be clear about what he’s talking about. More specifically, I want to make sure that he’s aware of why the system should be designed in a specific way, what the constraints are, and whether there’re any other solutions. Usually, the design questions are vaguely described. Good candidates are able to tell you what assumptions are made and how this design is compared to others. To make it even clearer, ask yourself what are alternative solutions and why you make the system in this way instead of others.
In the following sections, I’ll focus on some practical tips and start with tips for preparation.
How To Prepare System Design Interviews
We have to admit the fact that experience beats everything. That’s why some experienced engineers don’t need preparation at all. However, there’re still a lot of things you can do to make a big difference.
If you are far from your interview (at least 6 months), it’s absolutely worth to build something. The truth is that everyone can opine on the macro design, but only people who have really worked on the details are able to take everything into consideration.
You can take an internship if you are a student, you can also work on a side project that interests you. Contributing to some open source projects is also a good idea. What matters is not which project to work on, but start working on something.
The reason I think this is important is that you won’t know if your design would work without actually working on it. With some hands-on experience, you’ll soon realize that a lot of things are really hard to implement but seem reasonable at first glance. For example, if you want to check if a page’s content has been updated since the last time you crawled and rely on if the HTML content remains the same, you’ll notice that many pages have the same content but things like comments, sidebars have been changed. This is a design I don’t think it works, although it may sound reasonable.
It’s important to be generally curious about everything. One great practice is to pick whatever product you are using every day like Youtube and think about how would you design the system from scratch.
Sometimes the product can be really complicated, you can also just design one of its features like Facebook friends recommendation. If you have time, writing some code to implement a prototype would be a plus. But the point is that you should try to get down to the detail.
Although system design questions don’t have any standard answers, you can still search for how these products/features are implemented. Compare it with your own designs and understand the difference. High Scalability is highly recommended, but don’t spend too much time on the particular tools (see the point “What’s Not Important”).
NOTE: One trick is that a lot of interviewers like to ask design questions that are related to the company. For instance, you are more likely to design a Google product/feature in Google interviews. It’s not always the case, but it doesn’t hurt to pay a little more attention to products of this company or similar products.
Similar to coding questions, you also need to practice system design interviews. There are a couple of ways. You can do a little bit Google search to see how others would approach the same question and compare with your designs. For instance, System Design Interview Questions have a very detailed analysis of common questions.
A better approach is to practice with someone who is more experienced. If you have friends who have been in industry for a while, that’s great. Ask them for help. If you don’t want to bother them, you can have mock interviews from Gainlo. I would say it’s always better to practice interactively because the whole interview process is more like discussions than exams.
What’s not important
One common mistake is that many people pay too much attention to particular technique. For instance, they have spent a lot of time on how to use AWS, how to config Google cloud platform and how to use a specific web framework.
I’m not saying these are not useful, in fact, these are definitely good things to learn. However, from system design interview’s perspective, I would say interviewers care more about the understanding of knowledge than particular technique.
For example, when discussing processing large data, as an interviewer, what I would like to discuss is about how to distribute the data to multiple machines, how to aggregate them together later and how to equally distribute the load. If someone just tells me that he’ll use Hadoop on AWS, I’ll ask for more details and he would still end up answering all questions above.
The rule of thumb is to focus more on how each tool is designed than what tool to use.
It’s hard to fit all tips about system design interviews within a single chapter. We’ll talk about some on-site strategies in the next post.
If there’s only one thing you can get from this chapter, I hope that is start working on something. Most people spend too much time planning, but what they really need is to build things.
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..