A few years ago, I took the educative.io course on grokking modern system design. And it was definitely the most structured write up on the internet that I could find on System design. Going through that inspired me to create something similar here.

What’s special about system design interviews?

System design interviews discuss concepts at a higher level than what you would do when you are programming. You aren’t delving into code, you are talking about systems. You clarify the needs and then map them into several different components and choose the right protocols, data store, replicas etc based on the needs of the system.

There is no right or wrong answer here. It is more of an exploration into your understanding of distributed systems. Unlike coding interviews where people ask you to solve a fictional, unrealistic programming puzzle, system design interviews cover areas that you might actually end up doing at work. This is why I personally like the system design interview. It demonstrates you know what to consider when designing large scale systems.

Companies use this information on how you perform in the system design interview to assess which level to put you on. If you lead the interview, from one part to the other, asking clarifying questions, thinking out loud and stating assumptions clearly and scoping the problem and solving that and iterating over your first solution till you get a more scalable solution, while diving deep into areas that might need a bit more explanation - or maybe, the interviewer might probe you into certain areas based on how you are approaching your solution. This depth and breadth is what is used to distinguish you as a Level 4 or Level 6 or whatever the levels are in your company.

Some companies like Meta, even offer something called a Product Architecture interview - which is similar to a system design interview, but instead of focussing on specific backend problems, they focus on a whole client facing product problems. Questions like design Twitter, competitor of Whatsapp, cloud storage, etc are these problems. They often have a user interface component to it and are looking to know what considerations you make empathising with your user base.

How to approach system design interviews

If you thought going straight into the whiteboard with drawing boxes was the answer, then you have missed the point.

System design interviews often start with just a one line question that doesn’t mention anything much other than what the outcome is. Something like Design a Twitter clone.

The other factor is that an interview is always timed, and you have to make sure you structure your solution within the time available. A clone of a popular application used by millions of people around the world for over 10 years would have a huge long list of features! So in order to ensure you design something to begin with within the time that you have, you have to scope the problem.

So what do we do?

Structure of the system design interview

Like any problem solving exercise, one must always follow a couple of steps to arrive at the solution.

  1. Clarify requirements - ensure you understood the assignment - paraphrase the problem and understand if it is exactly what you thought it is or is this one targetting a smaller group etc.
  2. Focus on one feature or a couple not more thereby scoping the problem you are going to solve in the given time
  3. Talk it through - remember that the interviewer can only assess what you say. They are humans like you. They cannot read your mind. So talk your thoughts as you go through the process.

Ensure that you lead the interview here. The interviewer might challenge you, but you evaluate the choices of tech, discuss the trade-offs and keep moving from one step to the other. If the interviewer needs more details on something that you stopped discussing, they would ask for it.

The third step might seem a little weird but if you have pair programmed it should come naturally as the pair usually talks through approaches as they code.

Zooming into a map

After the clarification and scoping, start the solution. Attempt at a very high level - just laying out the context of the problem. Talking about users, front-end, load-balancers, cache, data processing, any data pipelines etc. Just put those in place. Name them as you like in the diagram. I am assuming that you are going to draw it out as you explain. Most system design interviews are done on some sort of board - virtual or physical. So use the board and DO NOT forget to talk it through.

Then delve into the next level into the architecture, you could start with user interface, or API and then go to database structure design.

As you delve into one level and discuss a potential solution, think about how that solution would scale for 100000000x users and what options would enable the solution to scale that way.

Repeat the same process for other tiers of the application.

Keep in mind that you must always start with the simple solution and then introduce the scale as a factor. Nobody has infinite money to start building an application for large scale.

That is how you navigate a system design interview.

How do I practice for one?

Learn distributed systems. Learn its fallacies.

Practice a mock system design interview, if you have a friend, then with them. Else just imagine you are being interviewed and are also the interviewer. And answer your own questions.

Always remember to discuss trade-offs rather than the minute details. Knowing trade-offs will always help make a well rounded decision when it comes to solving such problems. As you discuss the high level trade-offs, you will gradually delve into a choice and will have to invest time there.

Other resources

An online system design course.

Read engineering blogs from Google, Microsoft, Amazon, Netflix and others… Exciting challenges solved by these companies are often written as blogs and shared widely online. This helps them attract talent interested in working for them. This also is a great source for curious minds to understand how large scalability issues were dealt with. Of course these blogs may not contain every detail but an abstract idea of how they approached the problem. This is the sort of detail expected to be discussed in a system design interview too. Keeping an eye out for such engineering blogs would also keep you up to date on trends in engineering challenges faced by organisations. However, it is important to understand that these are approaches taken by engineers and it might have been things that were exciting at a certain time and might have been replaced by newer better solutions over time.

Some popular company engineering blogs:

These are great resources, but how much time do you have in a day to read all these? Be practical. You don’t have all the time in the world. You don’t have to know everything that’s happening in the world either. If you do know something, that’s great, if you know things relevant to your job role, that’s even better.

How and why does a system work?

I find that curiosity is a great way to learn anything. Your curiosity leads you to invest time in finding more about something and you delve deeper and ge a better understanding about it.

Imagine if you questioned:

  • How does this cool app that I am using work?
  • How does it deal with so many users?
  • What choices might have been made to allow operations at this scale?
  • How does my click get recorded as a like, or dislike or clap or laugh
  • How far can I keep scrolling before the app stops fetching more on my feed?
  • What does it take to keep this infinite scrollability?
  • How do they show me related information and posts?
  • What type of analysis might they be doing?
  • Question the alternatives if you know the technical choices that were made for the app that you are using

This attitude encourages systems thinking. Helps you learn how large scalable systems are engineered to be highly available. Setting you up for success in your system design interviews.