Netflix in 45 Minutes: A Quick Story of a System Design Interview, What to Expect + A Selection of Useful Links

In our blog, we write a lot about building a career in IT in different countries, finding a job, differences in the process of interviewing large companies. In today’s article, we will go further and cover the topic of the so-called system design interviews – this is one of the stages of interviews with well-known technology companies, where many candidates are eliminated.

So what is system design and how do you get through this type of interview?

What it is

In today’s world, IT systems have become extremely complex. Each new “feature” in the product must meet many requirements, there are always constraints between which engineers have to balance. What looks super easy to the average user – like submitting a search query via Google or Yandex – actually carries a huge level of complexity.

The difference between system design interviews and regular technical interviews is that they expect the candidate to answer ambiguous questions about data structures and algorithms. As a rule, the tasks at this stage are such that for them there is no unambiguously correct or incorrect solution, they provoke the thought process – it is in it that the candidate is revealed.

Roughly speaking, a system design interview is something like a brainstorming session, where a person thinks out loud, goes through possible solutions and analyzes the flaws of each of them in real time. This is the difficulty, but also the main plus – the thought process is more important here than the result. As a rule, such interviews are conducted by large companies developing large-scale systems (FAANG and the like).

How do you get through a system design interview? Below are some practical tips.

To get to interviews at companies where engineers really design large-scale systems, use the @g-jobbot… This is a service that will find and send you directly to Telegram the vacancies that suit you best – including remote work, including relocation.

The most important thing is to clearly understand the problem.

Since in a system design interview, the most important thing is how you solve a problem, it is extremely important at the very first stage to clearly understand it for yourself. Former Microsoft and Facebook engineer in his article on a practical example shows the importance of this fact.

Typically, the task is something like “How would you design Netflix in 45 minutes?” At first glance, such questions are utter nonsense. Such large-scale systems have been designed and implemented by hundreds and thousands of engineers over the years. Forty-five minutes will not even be enough to start discussing at least one of the components of such a product!

This is where understanding the task is very important. You need to understand what the interviewer wants. And he obviously wants him to:

1. gave an answer in the format “helicopter view” of the entire system,
2. then decomposed it into components
3. described why each of them is needed (data center, data storage, frontend, backend, caching, working with queues, networking and load balancing, etc.)

Picture: system-design-primer

You can dwell on some of these components in more detail – they will point you to this, or you will need to ask. Usually, you don’t even need to write code in an interview on system design, and if you immediately delve into the technical jungle, without first discussing the entire system as a whole, this will be a disadvantage.

Ask clarifying questions

The main purpose of the systems design interview is to give the candidate the opportunity to demonstrate their knowledge and experience. As stated above, there are no right or wrong answers. It is much more important not to solve the problem as such – especially since it may simply be impossible in the allotted time – but to show your thought process in all its glory.

Therefore, it is extremely important to ask questions, even if it suddenly turned out that you clearly know the answer to the question posed. In such a situation, you don’t just need to write a solution to the problem, this is contrary to the purpose of the interview. You need to forget the known solution, and start looking for a new one, asking questions along the way.

This will allow the interviewer to understand several things at once:

• how does the candidate approach the assessment of the problem?
• Does he immediately assess possible limitations and bottlenecks of the system?
• Does it immediately think through optimization of solutions and circumvention of restrictions?

In this article Twitter engineer, shared his experience in interviewing. In particular, he gave a good description of how to ask questions. Imagine that in an interview you were given the assignment to design a box. No more information is given outright.

Questions might be:

1. What exactly should the system be able to do (how many items fit into the box, what are their sizes)?
2. Who is the target audience of the product?
3. What are the expectations of the product users?

Answers to them will allow you to understand that you need to create a yellow box with an emoticon drawn on it, which will fit at least one tennis ball. However, the ball is not quite ordinary – its radius is half a meter, and its weight is about 1 kg. The box will be easy to carry by holding the bottom, so no handles are needed.

There is much more information, now you can think about solving such a refined problem.

Image: freecodecamp.com

Don’t try to impress

A common mistake in interviews on systems design – many candidates think that since at this stage you need to work at the abstraction level, it will be enough to throw in cool terms and names of fashionable technologies during the conversation to pass for an expert. It doesn’t work that way.

Firstly, the interview on systems design will probably not be just a recruiter, but an engineer who is looking for a person to join his team. It is not enough for such a person to just hear words like No-SQL, Mongo DB and Hadoop. He will obviously start asking clarifying questions, and if you don’t really have much experience with the technologies mentioned, this will become clear very quickly.

Be honest

A systems design interview is one of those times when it’s okay not to know for sure. Therefore, answers like “I have never worked with this particular technology, but I know that it is often used to solve similar problems” is a good option. In addition to honesty, here the candidate showed certain knowledge and made it clear to the interviewer where he will start solving the problem (he will try a known solution, if it does not work out, he will “dig” further).

In addition, you should not pass off your solution as ideal and not containing any drawbacks. There are always limitations, and an experienced engineer-interviewer understands this better than anyone else. Therefore, during the interview, it is worthwhile to honestly say that there are such and such bottlenecks in the solution, but you can try to get around them in this and that way, use additional tools or conduct even more research.

This will make it clear that the candidate does not just come up with a solution and then toughly try to push it through, but can be flexible, make adjustments, and generally adequate and understand that it is always possible to do better.

Here’s a lovely fictional dialogue in a systems design interview that shows you how NOT to do:

Interviewer: Let’s make our Twitter. How will you store your tweets?

Candidate: I am using MongoDB NoSQL database.

Interviewer: Why not MySQL?

Candidate: DBMS are not scalable. For our task, we will definitely need MongoDB or BigTable.

Interviewer: But here on Twitter we store all the tweets in MySQL, everything scales fine.

Candidate: Well, then, perhaps, you just do not have a large enough volume yet. Truly huge systems like Facebook use NO-SQL.

Interviewer: But Facebook also uses MySQL.

Candidate: Hmm, I don’t know how they scale it, we need to figure it out. Perhaps they have MySQL only on the frontend, but on the BigTable back.

Interviewer: Never mind. Where will we store the analytical data?

Candidate: Obviously in MySQL.

Interviewer: But aren’t there too many for MySQL? Now we have HDFS for this.

Candidate: It looks like you started developing Twitter even before MongoDB developed enough. MongoDB can easily accommodate both tweets and analytics data.

Interviewer: Super, thanks for your time. It was nice to chat.

How to Prepare for an Interview: Useful Links

While systems design is one of the more fuzzy parts of an interview, you can prepare for it. To help candidates, we have compiled a list of useful materials:

• Anatomy of a System Design Interview
• How NOT to design Netflix in your 45-minute System Design Interview?
• Crack the System Design interview: tips from a Twitter software engineer
• Free Course in Systems Design in English
• A selection of 50+ sources on system design
• How to Successfully Pass an IT System Design Interview: What to Expect and How to Prepare