How NOT to design Netflix in your 45-minute System Design Interview?

Over the last two years, I’ve helped 100+ engineers prepare for interviews in tech companies. Last year, I also volunteered to conduct mock interviews for fresh graduates. Before founding my startup, I had interviewed hundreds of candidates at Facebook and Microsoft.

During these discussions, it was obvious that candidates are more nervous about the System Design Interviews than the coding interviews. I also noticed a recurring pattern of mistakes that a lot of candidates make. In this post, I’m going to identify some of those mistakes. (I plan to write more on what SHOULD you do during your interviews, but if you are looking for resources to prepare, I’ve mentioned some resources at the end of this post).

We, the engineers, dread system design interviews because we don’t get to design large systems during school projects and even during our jobs, we rarely get a chance to create a scalable system from scratch. Usually, we join an established team and are tasked with writing features for a specified component. We spend most of our time fixing bugs, optimizing code and writing tests. However, when you are asked to design a large scale distributed system in 45 minutes, you don’t want to spend time discussing how can you slash 20 milliseconds from the response time by avoiding a buffer copy. Instead, you need to identify high-level components and describe how these components will interact with each other.

Can you even design Netflix in 45 minutes?

You are typically asked to design Netflix (or another scalable service with hundreds of millions of users) in 45 minutes. It is a seemingly absurd question. 45 minutes is too short even to discuss the details of any one component. These services have been developed by hundreds or thousands of engineers over the span of many years. How can you compress all that work and sketch it on a 5x5 whiteboard?

The key here is to understand what your interviewer is looking for. He wants you to give him a 50,000 ft overview, identify high-level components and describe the interactions between components as succinctly as possible. Here are 3 ​phases of such a discussion.

1. Draw a big box that represents the system.
2. Zoom-in and break that big box into 5–6 components.
3. Briefly discuss the role of each component e.g. compute, storage, front-end, back-end, caching, queueing, networking, load-balancing, etc.

Your interviewer would want you to discuss 1–2 components in more depth and he is going to specify which one. You are rarely expected to write any code during these discussions.

Here are a few common mistakes that candidates make during their interviews.

I know 20 buzzwords so I should be fine

You might be thinking, if I have to design at an abstract level, I can probably bullshit my way during the design interview. Not so fast. Your interviewer is looking for teammates with whom he will be working every day — and someone who is trying to bullshit during the interview will be doing it time and again. Any experienced interviewer will be on the lookout for people who are trying to throw in buzzwords like “No-SQL”, “Mongo DB” and “Hadoop”. Always, always expect that your interviewer is going to ask for more details and justification. Only use buzzwords and in-fashion technologies e.g. “GraphQL” if you understand them well and can justify and defend your approach.

Rule 1: Reading High Scalability a night before your interview does not make you an expert in Distributed Systems.

I can pretend to be an expert

I’ve heard the stories of several very embarrassing situations where the candidate pretended to be an expert on something only to realize that the interviewer is the known industry expert in the said field. In addition to above stories (which I won’t be telling here), I’ve been in such situations myself a few times — on both sides of the table.

In 2006, I was being interviewed by Microsoft, and my interviewer asked whether I’ve implemented B-Trees (or maybe B+ Trees). I told him that I know what B-Trees are, and they are useful in databases but can’t remember anything else. He moved onto other topics. Later I found out that my interviewer was James Hamilton, a foremost expert in databases and distributed systems. Fast forward a few years, I got to implement B+ Trees (large B+ Trees containing TBs of data) for Microsoft’s Azure Storage, and now I know a thing or two about B+ trees. Even today, I would be scared to tell James Hamilton that I know what a B+ Tree is.

On the other side of the table, once an interviewee told me that he has implemented certain features in a certain codebase. Unknown to him was the fact that I used to work on that codebase before he joined that team. I probed a little and realized that he only implemented a client for that codebase but was claiming much more.

Incidents like above are obviously rare. Far more likely are two things:

1. Your interviewer might be working on the technologies that you are talking about and can easily distinguish​ between an imposter and an expert.
2. He has probably asked this question a 1000 times and is well versed in the possible solutions. He’ll quickly find out how much you actually understand.

Rule 2: Never pretend to be an expert. The person interviewing you almost always understands the domain better than you and can even be an industry expert.

This is really my domain. I’ll be done in 15 minutes

Good for you but slow down. Instead of jumping to the solution that you already know, do the following:

1. Gather requirements.
2. Ask Questions. Your interviewer is interested in understanding your thought processes.
3. Evaluate multiple solutions, discuss pros and cons and see where the discussion takes you.

In reality, it is a good idea to do this whether you know about the domain or not.

Rule 3: Don’t rush to a solution. Gather requirements, suggest multiple solutions and evaluate them. It is meant to be an open-ended discussion.

Bonus: Don’t be that Guy

(Disclaimer: Following is a hypothetical conversation and any resemblance to actual persons or actual events is purely coincidental.)

Interviewer: Let’s implement Twitter. How are you going to store all the tweets?Candidate: I’m going to use a NoSQL database like MongoDB.

Interviewer: Why not MySQL?Candidate: RDBMS doesn’t scale. We need a scalable database like MongoDB or BigTable.

Interviewer: But we at Twitter store all of our tweets in MySQL, and it scales very well.Candidate: Well, then I stand corrected. Perhaps your scale isn’t that huge. Services that need more scale like Facebook use NO-SQL solutions.

Interviewer: But Facebook uses MySQL as well.Candidate: I don’t know how can they scale. I’ll have to look it up. Perhaps they have a MySQL at the front-end backed by BigTable.

Interviewer: Nevermind. Where should we store our analytical data?Candidate: Obviously in MySQL.

Interviewer: But it’s too much for MySQL. We store it in HDFS.Candidate: You probably started building Twitter before MongoDB got mature. MongoDB can easily handle both your tweets and analytical data.

Interviewer: Alright, thanks for your time. It was great talking to you.

Resources for preparing for software engineering interviews

1. If you are looking for a resource to prepare for system design interviews, look at the newly released course Grokking the System Design Interview that covers the basics of distributed systems and has interactive lessons covering how to design Instagram, Dropbox, Twitter, Facebook Messenger, Youtube, Facebook Post Search, Typeahead, Web crawlers, Yelp and Uber/Lyft.
2. If you are preparing for coding interviews, take a look at Coderust 2.0: Faster Coding Interview Preparation using Visualizations. It has 80+ problems with code in Python, Java, Javascript, C++ and Ruby. Every problem has interactive visualizations to explain each step so that you are actually understanding the solutions instead of just memorizing them.
3. Think you are ready but need some practice? Try an AI Mock Interview.

Fahim is the co-founder of Educative. We are building the next generation learning platform for software engineers and instructors. Learners learn by going through interactive course. Instructors can create and publish interactive courses using our course builder. If you are interested in publishing courses or knowing more, feel free to reach out.

If you liked this post, click the heart sign below and follow me for more posts.