This is the sixth chapter of our The Complete Guide to Google Interview Preparation series.
We’ll continue our discussion about system design interviews from last chapter. In this post, we’ll mainly focus on some practical on-site strategies.
Assuming you’ve 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. We’ll 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. I’m always a big fan of systems like this and from the system design interview’s 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 you’re using, but whether you can design a system that works. I’ve 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 won’t 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.
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 it’s a discussion, you are encouraged to think loudly. You don’t 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. It’s completely a discussion process and it’s like we are working on the problem together. They won’t pretend to know everything. Instead, they will always tell me what they are stuck with and how they are approaching the problem.
There’s 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 don’t 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, it’s 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 it’s better is due to some constraints and assumptions. So it’s important to validate those assumptions. Changing your mind during the interview is completely okay. In fact, it’s a good sign that you are considering all scenarios.
Many people are confused about whether to consider scalability and whether to distribute the data to multiple machines. Sometimes you won’t 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 it’s 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, I’m not suggesting that you should never use any existing tools in system design interviews. What the design question is focused on matters. If it’s a common tool or something trivial comparing to the overall question, it’s completely fine to use existing tools.
Again, in system design interviews, the experience just beats everything. It’s 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 you’ve 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 don’t 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..