Cracking system design interviews guide

System design interviews are tough to crack if you aren't well prepared. The questions are broad, have multiple possible answers, and require some foundational systems knowledge. 

Companies like Facebook, Google, and Amazon use system design interviews to evaluate candidates for tech roles (e.g. software engineers, technical program managers, etc.). So if you want to land a job offer at a top tech company, then you'll probably need to pass system design interviews. 

Here's the good news. We've done some of the heavy lifting for you. Instead of bouncing around the internet to find preparation tips, example questions, and concept definitions, you can just use the below guide. Consider this your ultimate hub for system design interview preparation.  

Here's an overview of what we'll cover:

  1. Overview of system design interviews
  2. Method for system design interviews
  3. System design interview questions 
  4. System design concepts
  5. System design interview preparation

1. Overview of system design interviews

Let's start with the basics. 

1.1 What are system design interviews?

System design interviews are typically 45-60 minutes long, and begin with a very broad prompt, like "Design Twitter". Then, you'll be expected to generate a high-level design, showing the different system components that will be required, how they're connected, and any trade-offs in the approach you've taken. 

This is very different than other types of interviews (e.g. behavioral, coding, etc.) that you might face when applying for a tech role. As a result, you won't be able to "coast" through system design interviews using the skills you've developed in other areas. You'll need to do specific preparation for system design questions. 

1.2 How common are system design interviews?

You might also be wondering how common system design interviews are. The answer depends on the company and role that you're applying for. As a rule of thumb, the more senior the position, the more system design interviews you’ll have.

If you’re applying for junior positions, your interviews will be more focused on coding and you’ll usually have a maximum of 2 system design interviews (you could have 0). And if you're applying for a more senior software engineer role, or for a software development manager position, then you should expect system design interviews to be much more heavily emphasized. 

In addition to software engineers, system design interviews are also used in TPM interviews, and potentially in interviews for other technical roles. 

1.3 What companies use system design interviews?

Below, we've compiled a list of our interview guides for every company and role that we've covered, where system design interviews are used. This is not a comprehensive list of all companies in the industry that use system design interviews, but it does cover some of the biggest companies in the industry.

If you'd like to learn more about a specific company's system design interviews, or their overall interview process, then we'd encourage you to check out our guide for that company below :

2. Method for system design interviews

Now that you have a high-level understanding of system design interviews, let's talk about how to approach them systematically. There are a variety of ways to solve system design interviews, but at the end of the day, you need a method that will consistently:

  • Show your interviewer that you have the knowledge they need
  • Break the problem down into manageable steps

With that in mind, our favorite approach and the one that we recommend you use is summarized in the following video from Amazon: 


The approach shown in the video above can be boiled down into 3 main steps:

  1. Ask clarifying questions
  2. Design high-level, then drill down
  3. Bring it all together

Let's dig into each of these in more detail. And by the end of this section, you should have a good idea of what to do at each step of a system design interview. For a more detailed breakdown of this method, and a full example answer, take a look at our article on how to answer system design interview questions.

Let's get started!

2.1 Ask clarifying questions

The first step to answering a system design question is to ask clarifying questions. You need to make sure you clearly understand the goals and requirements of the system. This will have a huge impact on the quality of your design, because the value of a system is deeply connected to how well it meets the intended objectives.

Let's examine this further using the same example covered in the Amazon video above: Design an online bookstore.

2.1.1 What is the goal of the system? 

If you're asked to design an online bookstore, you'll need to begin by collecting more specific details about the bookstore's purpose. For instance:

  • What kind of bookstore is it?
  • Does it focus on a specific type of reader (e.g. students, business leaders, science fiction fans)?
  • Does it sell paper books, ebooks, or both?
  • Etc.

This is not a comprehensive list, but your goal should be to clearly establish the purpose and goal of the system you need to design. 

2.1.2 What is the scale of the system? 

Once you know the goal of the system, that's progress, but you still won't have a clear vision for the system until you clarify a few more things, including the required scale. 

You'd design a very different system for a university bookstore that delivers special order textbooks to the local campus than you would for an online bookstore that sells millions of books worldwide. 

As a result, you'll want to ask questions like:

  • How many customers does the system need to serve per day? How many transactions? 
  • What are the performance requirements (e.g. latency, throughput, availability)? 
  • How is the demand on the system expected to change in the future?

2.1.3 Where should we focus? 

Once the goal and scale of the system are clear, then it can also be helpful to discuss with your interviewer where to focus your attention during the interview. Obviously, there are a lot of different aspects of an online bookstore system, and you won't have time to cover every detail in ~45 minutes, so it's helpful to clarify the focus. 

To do this, you could ask questions like: 

  • Should we focus on the end-to-end experience? Or should I drill into a specific component of the overall system? 
  • Should we focus our conversation around the API, as it appears to be a key component of this system? 

Keep in mind that different interviewers may have different views on where you should focus, so it's really helpful to get their buy-in to make sure you're on the same page before proceeding with your high-level designs. 

This can also save you from designing the wrong type of system, because it gives the interviewer an opportunity to help steer you in the direction they most want to go. 

2.1.4 Call out your assumptions

Here's a final note to keep in mind while you clarify the requirements of the system. Whenever you make an assumption that will influence your design approach, make sure you mention it to your interviewer. 

A big part of system design interviews is showing your interviewers how you think, and not just the final solution you reach. As a result, you want to voice your thoughts out loud, so that the interviewer will be able to follow your logic without getting lost or confused along the way.

2.2 Design high-level, then drill-down

Once you've clarified the requirements of the system, it's time to start designing! 

2.2.1 Do high-level design in the first 20 minutes

According to Google (see video in section 2.4 below), your interviewer in a system design interview will want to see your high-level design within the first 20 minutes. Most system design interviews last for about 45-60 minutes, so this raises the question: how do you allocate your time? 

Well, the flow that you should expect in a system design interview is to quickly clarify the requirements and draft a high-level design for the system within the first 20 minutes. Then, you'll spend most of the remaining time drilling-down into more detailed aspects of the system. 

When you put together your high-level design, you only need to include the most foundational components. For example, the front-end, web servers, and database. 

2.2.2 Drill down into your strongest area first

From there, you should drill-down into more details, starting with the specific component that you are most familiar with. For example, if your background is in front-end development, then you should start with the front-end, and work your way backwards through the system. This is the exact process demonstrated in the Amazon video above. 

Using this approach will ensure that you have time to go in-depth where you have the most knowledge. Similarly, it may allow you to give more general designs for areas where you're weaker, due to the time limitations of the interview. Both of these situations can help you make a stronger impression. 

2.2.3 Don't get caught in a "rabbit hole"

As a final note about your detailed designs, be careful not to drift too far down a "rabbit hole". Your interviewer will want to see that you can focus on the broader view of the system, without getting overly caught up in design considerations.

This is a bit of a grey area, and it can be tough to know exactly how deep to go into the details, so it's helpful to ask for your interviewer's input along the way. For example, you could simply ask "would you like to dig into the finer details of this component, or shall we move on?"

2.3 Bring it all together

Before the end of your interview, you should take a few minutes to summarize your solution and highlight important bottlenecks or improvement opportunities. 

A good way of going about this is to recap the goals and requirements you captured at the beginning of the interview, and then to highlight how your solution meets those objectives. At the same time, you should also highlight significant gaps or trade-offs in your design.  

You can also briefly summarize how the system you've designed will work from end-to-end, to bring all of the elements of your design discussion together.

Taking these steps is a great way to refresh your interviewer's memory, to demonstrate strong communication skills, and to show that you've kept a clear vision for the system's goals throughout the entire interview.

2.4 Additional tips

That's the end of the 3-step process for approaching system design interviews. However, we thought it would be helpful to also include the below video from Google.

It reiterates a few points, and offers some additional suggestions from Googlers for how to succeed in system design interviews:


Here is a brief summary of the video:

  1. Communication. Make sure you ask clarifying questions, gather requirements and communicate out loud in a structured way.
  2. Designing to scale. Get to a first design in less than 20mins, and then dive into how to make it scalable, reliable and efficient enough so that it can be used at "planet scale".
  3. Concrete and quantitative solutions. Be familiar with common design patterns (e.g. sharding data) and be ready to estimate the cost generated by the system you designed (e.g. read from disk / memory).
  4. Trade-offs and compromises. Proactively call out the trade-offs and compromises you've made in your design. Iterate the design if necessary.

For a list of 19 extra tips that come from FAANG ex-interviewers, take a look here.

Now that you've learned a method for approaching system design questions, let's take a look at several example questions (with solutions) to better understand how to put these ideas into action.

3. System design interview questions

Below, we've compiled a list of system design interview questions, along with the best free example solutions we've been able to find online. You can use the below list as your "one-stop-shop" for practice questions, because it's representative of the types of system design questions you'd be asked at leading tech companies, like Facebook, Google, Amazon, etc.

The more practice you can get with system design questions (like the ones mentioned below) the better prepared and the more comfortable you'll be for your interviews. So go ahead, jump into some practice questions!

3.1 Social media system design questions

3.1.1 Design TikTok


3.1.2 Design Twitter

3.1.3 Design Instagram

3.2 Instant messaging system design questions

3.2.1 Design Whatsapp


3.2.2 Design Facebook Messenger

3.3 Ride sharing system design questions

3.3.1 Design Uber



3.4 Additional system design questions 


4. System design concepts

You can think of this section as a crash course on several foundational system design technologies and concepts. The high-level descriptions in each subsection below are summaries from in-depth articles that we've published on each topic. So, if you want to learn more about any (or all) of these topics, you can do so by clicking the link embedded in each subsection. 

4.1 Network protocols and proxies

Network protocols and proxies are among the most fundamental building blocks of system design. And if you’re preparing for a system design interview (or just want to be more familiar with system design), then understanding these topics is a good place to start.

Network protocols make it possible for any networked computers to talk to each other, no matter where they are or what hardware or software they’re running. They do this by establishing standard forms for sending and receiving data over the network’s physical infrastructure.

And a proxy is a server that sits between a client and application server to provide some intermediary service to the communication. There are two kinds of proxies that provide different services: forward proxies and reverse proxies. Check out our network protocols and proxies guide to learn more. 

4.2 Databases

Databases are an important part of the world’s biggest technology systems (i.e. Facebook, Amazon, etc.). And the way databases are used have a huge impact on the speed, scalability, and consistency of those systems.

This is a huge topic with a lot of moving parts. So, to make your life easier, we’ve put together a separate guide covering the basics you may need to know for your system design interviews.

4.3 Latency, throughput, and availability

 "Performance" is an important concept in system design, and it’s also a common topic that comes up on system design interviews for tech roles. 

Intuitively, we want our services to be fast, and to ensure that every user has this experience we need precise measurements of what "fast" means. The following are three common metrics for measuring system performance:

  • Latency is the amount of time in milliseconds (ms) it takes a single message to be delivered. 
  • Throughput is the amount of data that is successfully transmitted through a system in a certain amount of time, measured in bits per second (bps).
  • Availability is the amount of time that a system is able to respond, that is the ratio of Uptime / (Uptime + Downtime).

To learn more about each of these (including some helpful illustrations), you can read our separate guide on this topic.

4.4 Load balancing

Load balancing is the process of distributing tasks over a set of computing nodes to improve the performance and reliability of the system. A load balancer can be a hardware or software system, and it has implications for security, user sessions, and caching. 

To learn more about load balancing, the types of load balancers, and load balancing algorithms, you can read our guide on load balancing.

4.5 Leader election

Sometimes horizontally scaling a system is as simple as spinning up a cluster of nodes and letting each node respond to whatever subset of the incoming requests they receive. At other times, the task at hand requires more precise coordination between the nodes and it’s helpful to have a leader node directing what the follower nodes work on.

leader election algorithm describes how a cluster of nodes without a leader can communicate with each other to choose exactly one of themselves to become the leader. The algorithm is executed whenever the cluster starts or when the leader node goes down. 

There are pros and cons to using leader election. To learn more about when to use it in a system, and different approaches to accomplish the same goal, you can review our leader election guide.

4.6 Caching

Caching is a technique that stores copies of frequently used application data in a layer of smaller, faster memory in order to improve data retrieval times, throughput, and compute costs.

As you might imagine, this is a simplified definition. You can learn more in our caching guide, including information about related topics like writing policies, replacement policies, and distributed cache.

4.7 Sharding 

Sharding is essentially the horizontal scaling of a database system that is accomplished by breaking the database up into smaller “shards”, which are separate database servers that all contain a subset of the overall dataset.

To learn more about sharding, how it works, and different approaches for sharding, you can check out our separate guide

4.8 Polling, SSE, and WebSockets

Polling, server sent events, and WebSockets are all techniques for streaming high volumes of data to or from a server. It’s important to know their differences when designing a system.

We don't have the space necessary to explain each of these topics here, but we'd encourage you to spend a little time reviewing our separate guide to get a high-level understanding. 

4.9 Queues and pub-sub

Queues and pub-sub are both mechanisms that allow a system to process messages asynchronously, which basically allows the sender and receiver of a message to work independently, by providing a “middleman”. This can eliminate bottlenecks and help the system to operate more efficiently.

To learn more about queues and pub-sub, and how to approach them during a system design interview, check out our queues and pub-sub guide

5. System design interview preparation

As you can see from the information above, there is a lot of ground to cover when it comes to system design interview preparation. So, it’s best to take a systematic approach to make the most of your practice time, and we recommend the four steps below.

For extra tips and resources, take a look at our preparation-focused system design interview prep guide.

5.1 Learn the concepts

There is a base level of knowledge required to be able to speak intelligently about system design. You don't need to know EVERYTHING about sharding, load balancing, queues, etc. 

However, you will need to understand the high-level function of typical system components. You'll also want to know how these components relate to each other, and any relevant industry standards or major tradeoffs. 

To help you get the foundational knowledge you need, we've put together a series of 9 system design concept guides. These are the articles that we've mentioned in section four above, but here's a recap of the full list:

  1. Network protocols and proxies
  2. Databases
  3. Latency, throughput, and availability
  4. Load balancing
  5. Leader election
  6. Caching
  7. Sharding
  8. Polling, SSE, and WebSockets
  9. Queues and pub-sub

We’d encourage you to begin by studying these topics and once you understand the basics, you can begin practicing system design questions.

5.2 Practice by yourself

Next, you’ll want to start getting some practice with typical system design interview questions. You can start by practicing with a couple of the example questions provided in section three above.

We'd recommend that you attempt to solve the problem yourself, before you look at the provided solution.

In addition, we suggest that you interview yourself out loud as you practice. Play both the role of the interviewer and the candidate, asking and answering questions. This will help you develop your communication skills and your process for breaking down problems.

5.3 Practice with peers

Once you've done some individual practice, we would also strongly recommend that you practice solving system design questions with a peer interviewing you.

A great place to start is to practice with friends or family if you can. This can help you get some preliminary feedback on your approach, which will be especially helpful if your partner is familiar with system design interviews. 

Practicing with another person will also force you to improve your communication, and will more closely replicate the conditions of the real interview (compared to practicing by yourself). 

If you don't have anyone in your network who can interview you, then you might want to check out our system design mock interview peer group, where you can set-up practice interviews with other candidates. 

5.4 Practice with ex-interviewers

Practicing with peers can be a great help, and it's usually free. But at some point, you'll start noticing that the feedback you are getting from peers isn't helping you that much anymore. Once you reach that stage, we recommend practicing with ex-interviewers from top tech companies.

If you know someone who has experience running interviews at Facebook, Google, or another big tech company, then that's fantastic. But for most of us, it's tough to find the right connections to make this happen. And it might also be difficult to practice multiple hours with that person unless you know them really well.

Here's the good news. We've already made the connections for you. We’ve created a coaching service where you can practice system design interviews 1-on-1 with ex-interviewers from leading tech companies. Learn more and start scheduling sessions today.

cta_illustration arrow_left Browse FAANG ex-interviewers