System Design Interview Questions & Prep (from FAANG experts)

If you’re preparing for system design interviews, it’s essential to know what kinds of questions top tech companies actually ask and what strong answers look like. 

Below, you’ll find a list of real system design interview questions from FAANG and other leading companies. These questions are most common in software engineer, engineering manager, and TPM interviews, but also come up for data, machine learning, and site reliability engineers.

We’ll start by breaking down what interviewers expect at different levels (from junior to senior), then walk through common system design questions with sample answer outlines from our FAANG experts—Mark (ex-Google), Tim (ex-Amazon), Ramprasad and Karthik (both ex-Meta).

Along the way, you’ll hear from more of our engineering coaches, including Xiao (ex-Amazon) and Pranav (ex-Meta).

Finally, we’ll share the best resources and a prep plan so you can walk into your system design interview with confidence.

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

• What to expect from your system design interview
  • What is a system design interview?
  • Types of questions and interview performance expectations
  • High-level design (HLD) vs. low-level design (LLD)
• Common "Design X product" system design questions (for FAANG candidates)
• System design knowledge interview questions (for fresher candidates)
• How to prepare for system design interviews

Let’s get started!

1. What to expect from your system design interview↑

Before we get into the commonly asked system design interview questions for engineering roles, let’s first look at what’s expected of you during your system design interview.

1.1 What is a system design interview?

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

System design questions are typically open-ended and are meant to kickstart discussions. To stand out, you'll want to show that you can be creative and structured at the same time.

The frequency of these interviews will depend on what role you’re applying for. If you’re applying for specialized roles like infrastructure, security, or platform engineering, you may face multiple system design rounds instead of just one.

Different FAANG+ companies may also have different requirements. But, generally, as a rule of thumb, the more senior the position, the more system design interviews you’ll have. 

The goal of this interview is to test how well you can design scalable, maintainable systems that can function in a massive, fast-paced environment. Building a technically sound solution is key, but equally as important is your ability to consider business needs, user experience, and internal resources.

1.2 Types of questions and interview performance expectations per level↑

The requirements for system design interview performance vary per career level. So, to help you focus your preparation, here are the types of questions you could get and what your interviewers expect you to cover based on your level, according to our expert coach, Xiao (Reddit, ex-Amazon). 

Just a quick note on our expert resource for this section: Xiao is a senior software engineer who has conducted 100+ actual and mock interviews, along with coaching sessions across all levels. He has recently gone through multiple FAANG interviews, so he’s up to date with current interview trends and expectations.

Entry-level engineer

As a junior engineer with less than 3 years of experience, you could expect basic system design questions. The most common ones you’ll get are for a URL shortener (Design TinyURL), rate limiter, real-time chat, or any basic API design.

“At this level, interviewers typically don’t expect full architectural depth,” Xiao says. So you don’t need to provide a production-ready design. Instead, the focus will be on foundational reasoning.

You’ll need to demonstrate clarity in communication, structured thinking, and basic understanding of key components (e.g., databases, caches, queues). These matter more than getting the 'right' answer.

How to ace your system design interview as an entry-level engineer? Xiao’s advice: “Asking clarifying questions and articulating trade-offs go a long way.”

Mid-level engineer

Applying for a mid-level position requires a step up in systems thinking and component-level discussion. To assess you on these, interviewers will likely ask you to design a notification system, newsfeed, job queue, or caching layer.

During your system design interview, you should drive the conversation, define key constraints, and discuss trade-offs. Xiao says, “You’ll be expected to go deeper into scaling, data flow, and basic fault tolerance.” 

Finally, according to Xiao, good signals for mid-level engineers include thoughtful simplification and an awareness of real-world constraints.

Senior/staff engineer

The rule of thumb for SD interviews is that the more senior you are, the more system design interview sessions you’ll need to go through.

The level of complexity expected from your system design interviews also changes. At your level, you should have ownership of the entire design process, according to Xiao. 

The questions you’ll get will likely be about complex distributed systems like collaborative document editing, large-scale search, or real-time analytics pipelines. Expect discussions around sharding, consistency, rate limiting, and trade-offs at scale.

“Strong candidates demonstrate depth in trade-offs, scalability, data modeling, and operational concerns,” says Xiao. 

To set yourself apart from other senior candidates, you need to communicate clearly across layers and proactively identify edge cases.

1.3 High-level design (HLD) vs. low-level design (LLD) ↑

Now let’s get into the difference between high-level design (HLD) and low-level design (LLD).

1.3.1 High-level design or HLD

You could describe HLD as the bird’s-eye view or the big picture of an entire system architecture. With HLD, you would be expected to cover the following:

• Functional requirements: Core features (send message, post tweet, search user, etc.).
• Non-functional requirements: Scale, latency, throughput, availability, consistency.
• Traffic estimates and capacity planning: Requests/sec, storage size, growth projections.
• Architecture components:
  • Load balancers
  • Application/API servers
  • Databases (SQL vs NoSQL, sharding, replication)
  • Caches, queues, CDNs, pub/sub
• Data flows: Read path vs write path, how requests move through the system
• Trade-offs: CAP theorem, eventual vs strong consistency, cost vs scalability.

The goal of your interviewer is to assess whether you can design a reliable and scalable system that can work in real-world conditions and constraints. 

1.3.2 Low-level design or LLD

LLD goes deeper into the details of how a system works, i.e., how the internal components are structured and work together. With LLD, you will be expected to cover:

• Object-oriented modeling: Classes, objects, interfaces, relationships
• Design patterns: Factory, Strategy, Observer, Singleton, etc.
• APIs and methods: Clear function signatures, parameters, return types
• Data models: Table schemas, indexes, relationships, how queries are optimized
• Component interactions: Sequence diagrams, how modules talk to each other
• Edge cases and validations: Error handling, retries, testing considerations
• Maintainability: Clean abstractions, modularity, extensibility

Asking you to drill down into LLD, interviewers want to see how you would translate and implement a high-level design for real-world use. 

You should be able to communicate clearly and with depth, anticipate real-world constraints (and suggest ways to handle them), and reason about tradeoffs. 

1.2.3 HLD vs. LLD - what will you cover at your level?

So, which one would you be expected to cover at your system design interview?

For freshers and entry-level engineers, a basic understanding of system design concepts is expected, but nothing too complex.

When you do look it up online, you’ll see that freshers and entry-level do get LLD questions. But these will mostly focus on testing your knowledge of Object-Oriented Programming (OOP) fundamentals, design patterns, and coding hygiene. 

Typically, covering both HLD and LLD is expected in mid-level engineers. You’ll see sample answers covering both in Section 2. At this level, you’re expected to own features end-to-end, so you must be able to design APIs, schemas, AND consider scale and integration. 

At a senior or staff level, you’ll mostly focus on HLD, designing systems at a scale that can serve millions of users. However, you could also be asked to drill down into LLD. You need to prove that you can bridge high-level architecture with low-level implementation.

To learn more about these two topics, we recommend reading the following deep dives:

• HLD vs LLD: The Ultimate System Design Interview Preparation Guide (by Dev.to)
• Architecture and Design 101: High-Level Design vs Low-Level Design (by Anji on Medium)

2. Seven commonly asked system design interview questions↑

Now that you know the different expectations for system design interviews at various levels, let’s get into the most common SD questions. 

For each question, we provide a summary of a FAANG expert’s sample answer, and a mock interview video for some. 

Try working on the system design interview question first, and then check your answer against the expert’s to find out where you can still improve.

• How would you design a messaging app?
• How would you design a social media app?
  • Design X 
  • Design Instagram
• How would you design a file-sharing system?
• How would you design a library management system?
• How would you design a phone billing system?
• How would you design a music streaming platform?

Let’s get started.

2.1 How would you design a messaging app?

Real-time messaging apps are a common standalone product, or a built-in feature of larger systems. For this question, you might be asked to design a specific app, like Messenger, WhatsApp, or Telegram.

Take a look at a sample answer outline from Mark (ex-Google engineering manager).

Check out the video below to see how Mark skillfully navigates this system design question. 

2.2 How would you design a social media app?

For this question, you'll typically be asked to design a specific app with a social media aspect, like Facebook, YouTube, Instagram, etc. Using this prompt allows interviewers to assess your problem-solving skills and your knowledge of system design fundamentals like reliability, scalability, availability, and performance.

#Design X (formerly Twitter)

For this example, let’s take a look at how Ramprasad (ex-Meta data engineer) would outline his answer to the question, “Design X (formerly Twitter):

#Design Instagram

Let’s take a look at another social media app design task, this time for Instagram by ex-Meta data engineer, Karthik.

Watch how FAANG expert Karthik answers ‘Design Instagram’ here:

2.3 How would you design a file-sharing system?

If you were interviewing at Google, this question would probably be presented as "Design Google Drive". Elsewhere, it might be "Design Dropbox."

You'll need to design a system that can scale to millions of users and handle petabytes of data.

Let’s take a look at an outline of ex-Shopify EM Alex’s answer to this question.

Check out the video below to see how Alex works through this system design question. 

2.4 How would you design a library management system?

Designing a library management system is another popular system design task in most interviews. It allows interviewers to see if you can handle common software challenges and assess your OOP (object-oriented programming) knowledge.

Let’s take a look at how ex-Meta software engineer Honglu tackles this question with the outline below.

2.5 How would you design a phone billing system?

“Design a phone billing system” is yet another classic SD interview prompt. It’s a fairly relatable topic, so there’s no need to ask about features like with other apps like social media or file-sharing systems.

It’s also a great tool to use to assess how you make trade-offs, as a phone billing system concerns both money and users’ security.

Let’s take a look at an answer outline from ex-Amazon Web Services Sr. software engineer Tim.

Watch ex-AWS Sr. software engineer Tim tackle this system design challenge in the video below.

2.6 How would you design a music streaming platform?

“How would you design Spotify?” is a good way to assess candidates on multiple facets of system design, including distributed systems, recommendation systems, and more.

Let’s take a look at an outline of how ex-Google EM Mark would tackle this challenge.

Watch the video below to see how Mark works on this system design challenge.

2.7 More system design questions

Now that we’ve gone through the most common system design interview questions, let’s get into a longer list of questions that have been asked in real tech interviews in the last few years, according to data from Glassdoor (note: we've edited to improve the phrasing of some questions).

The questions below are organized by company, to help you find the most relevant ones for your interviews.  

Check out our Google system design interview guide for more questions and Google-specific insights.

Check out our Meta system design interview questions for more questions and Meta-specific insights.

Check out our Amazon system design interview guide for more questions and Amazon-specific insights.

Check out our guide on Microsoft software engineer interviews for more examples. 

If you're applying for an AI/ML engineering role, you can also check out our machine learning system design interview guide. 

3. System design knowledge questions (for fresher/junior engineers)↑

The second type of system design questions is “knowledge” questions to test your knowledge about key system design fundamentals, e.g., “How does caching work?”. These are more common in interviews when the candidate is a fresher/junior engineer.

As ex-Meta engineering manager Pranav explained to us, FAANG interviewers generally don't ask these more straightforward questions. However, these topics may come up when discussing the design choices and trade-offs associated with them as you do your main system design question.

Pranav, who has conducted over 200 engineering interviews over the course of his career, created the following list of ten system design knowledge questions.

3.1 What is consistent hashing and how does it work?

Consistent hashing is a technique used in distributed systems to distribute data across a cluster of nodes efficiently. Unlike traditional hashing, which can lead to massive data reshuffling when a node is added or removed, consistent hashing minimizes the amount of data that needs to be moved.

How it works:

• Hash Space: Consider a circular hash space where each node and data item is assigned a position based on a hash function.
• Node Assignment: Nodes (servers) are placed on this circle according to their hash values.
• Data Assignment: Each piece of data is also hashed to a position on the circle. It is assigned to the nearest node in the clockwise direction.
• Rebalancing: When a node is added or removed, only the data between the node and its predecessor/successor is affected, drastically reducing the amount of data moved compared to traditional hashing methods.

This method ensures that the load is balanced across the nodes and scales well as nodes are added or removed.

3.2 What is an API Gateway?

An API gateway is a server that sits between clients and backend services. It acts as a reverse proxy to accept all application programming interface (API) calls, aggregate the various services required to fulfill them, and return the appropriate result.

Key Functionalities:

• Routing: Directs client requests to the appropriate backend services.
• Composition: Combines responses from multiple services into a single response, which can reduce the number of client requests.
• Security: Enforces authentication, authorization, and rate limiting, protecting backend services from malicious attacks and overuse.
• Monitoring and Logging: Tracks API usage, logs requests and responses, and monitors performance to help identify and troubleshoot issues.
• Load Balancing: Distributes incoming requests across multiple instances of backend services to ensure high availability and reliability.

By consolidating various functions into a single point, the API gateway simplifies client interactions and enhances system efficiency and security.

3.3 What is the difference between SQL and NoSQL?

SQL (Structured Query Language):

• Schema: SQL databases use a fixed schema, where the structure of data (tables, rows, columns) must be defined before data can be inserted. This ensures data integrity and supports complex queries.
• Transactions: They support ACID (Atomicity, Consistency, Isolation, Durability) properties, making them ideal for applications requiring reliable transactions, such as financial systems.
• Examples: MySQL, PostgreSQL, Oracle Database.

NoSQL (Not Only SQL):

• Schema: NoSQL databases have a flexible schema, allowing for the storage of unstructured or semi-structured data. They can accommodate a variety of data models, including document, key-value, wide-column, and graph stores.
• Scalability: Designed for horizontal scaling, NoSQL databases handle large volumes of data and high traffic loads efficiently, making them suitable for big data applications and real-time web apps.
• Transactions: Generally, NoSQL databases prioritize availability and partition tolerance over strong consistency (CAP theorem), offering eventual consistency.
• Examples: MongoDB (document store), Redis (key-value store), Cassandra (wide-column store), Neo4j (graph database).

3.4 What is caching and what are different strategies around caching?

Caching involves temporarily storing copies of data in a cache, a high-speed storage layer, to improve data retrieval times and reduce the load on the primary data source.

Strategies:

• Cache-aside (Lazy Loading): The application looks for data in the cache first. If the data isn't found, it's loaded from the database and then added to the cache. This approach ensures the cache only stores frequently accessed data but can lead to cache misses.
• Write-through: Data is written to both the cache and the database simultaneously. This keeps the cache up-to-date with the database but can increase write latency.
• Write-back (Write-behind): Data is written to the cache first and later persisted to the database asynchronously. This improves write performance but can lead to data loss if the cache fails before the data is written to the database.
• Time-to-Live (TTL): Cached data is set to expire after a specified period. This strategy ensures stale data is periodically refreshed, balancing performance and data accuracy.
• Eviction Policies: Determine which data to remove when the cache is full. Common policies include Least Recently Used (LRU), Most Recently Used (MRU), and Least Frequently Used (LFU).

Effective caching strategies can significantly improve system performance and scalability by reducing latency and the load on backend systems.

3.5 What is the difference between a row and columnar database?

Row Database:

• Storage: Stores data row-by-row, which is efficient for transactional operations where the entire row is accessed or modified frequently.
• Access Pattern: Ideal for applications with a high volume of write operations and those requiring complex transactional queries.
• Examples: MySQL, PostgreSQL, Oracle Database.

Columnar Database:

• Storage: Stores data column-by-column, which allows for efficient read operations, especially for analytical queries that involve aggregate functions on large datasets.
• Access Pattern: Optimized for read-heavy workloads and OLAP (Online Analytical Processing) where queries often involve scanning large amounts of data.
• Examples: Apache Cassandra, HBase, Google BigQuery.

3.6 What is a CDN and how is it helpful?

A Content Delivery Network (CDN) is a geographically distributed network of servers designed to deliver content to users more quickly and efficiently based on their location.

Benefits:

• Reduced Latency: By caching content closer to the end-users, CDNs significantly reduce the distance data must travel, resulting in faster load times.
• Improved Load Times: Static content like images, videos, and stylesheets are served from edge servers, alleviating the load on the origin server and speeding up page load times.
• Reliability and Redundancy: CDNs provide redundancy by distributing content across multiple servers, ensuring high availability even if some servers fail.
• Scalability: CDNs can handle large traffic spikes by distributing the load across many servers, preventing performance bottlenecks and downtime during high-traffic events.

CDNs are essential for enhancing the user experience on high-traffic websites and applications by ensuring fast, reliable, and scalable content delivery.

3.7 What's the difference between polling, long polling, WebSockets, and Server-Sent Events?

Polling:

• The client periodically sends requests to the server to check for new data. This approach is simple but can be inefficient, as it involves many unnecessary requests when there is no new data.

Long Polling:

• The client sends a request to the server, and the server holds the request open until new data is available. Once new data is sent, the client immediately re-requests. This reduces latency compared to regular polling and is more efficient.

WebSockets:

• WebSockets provide full-duplex communication channels over a single, long-lived connection. This allows for real-time, bidirectional communication between the client and server, making it ideal for applications like live chat and gaming.

Server-Sent Events (SSE):

• The server sends automatic updates to the client over a single HTTP connection. SSE is simpler to implement than WebSockets for one-way data streams, such as live news feeds or real-time notifications.

Understanding these communication methods helps in selecting the right approach based on the requirements of real-time data transfer in applications.

3.8 What is data partitioning?

Data partitioning involves dividing a large database into smaller, more manageable pieces that can be distributed across different storage nodes or servers.

Types of Partitioning:

• Horizontal Partitioning (Sharding): Divides data by rows, where each partition contains a subset of the rows. This approach is commonly used to scale out databases across multiple machines.
• Vertical Partitioning: Divides data by columns, where each partition contains a subset of the columns. This can be useful for isolating frequently accessed columns to improve performance.
• Range Partitioning: Distributes data based on a range of values, such as dates or numerical ranges, allowing for efficient query processing for range queries.
• Hash Partitioning: Distributes data based on a hash function applied to one or more columns, ensuring even distribution and minimizing the risk of hotspots.

Data partitioning improves scalability, performance, and manageability of large databases, making it easier to handle growing data volumes and traffic.

3.9 What is a database index and how does it help?

A database index is a data structure that improves the speed of data retrieval operations on a database table by providing quick access to rows.

Benefits:

• Fast Query Performance: Indexes significantly reduce the amount of data the database engine needs to scan, speeding up search and retrieval operations.
• Types of Indexes:
  • B-tree Indexes: Commonly used in most databases, they allow for quick searches, insertions, deletions, and sequential access.
  • Hash Indexes: Provide constant-time lookup for equality comparisons but are not suitable for range queries.
  • Full-text Indexes: Optimized for searching large text fields, useful for applications involving text search.
• Trade-offs: While indexes enhance read performance, they can slow down write operations due to the overhead of maintaining the index.

Indexes are crucial for optimizing query performance, especially in large databases with complex queries.

3.10 What are load balancers?

Load balancers are devices or software that distribute incoming network traffic across multiple servers to ensure no single server becomes overwhelmed, thereby improving the overall availability and reliability of applications.

Types:

• Hardware Load Balancers: Dedicated physical devices designed to balance loads at high performance levels

This is by no means a comprehensive list of all the system design topics you could be asked about. We recommend using our 9-part system design interview fundamentals series to dive deeper into certain areas ahead of your interview.

4. How to prepare for system design interviews↑

As you can see from the complex questions 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.

Below, you’ll find a prep plan with links to free resources. 

4.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. Here's the full list:

• Network protocols and proxies, which 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.
• Databases, integral components of the world’s biggest technology systems.
• Latency, throughput, and availability, three common metrics for measuring system performance.
• Load balancing, the process of distributing tasks over a set of computing nodes to improve the performance and reliability of the system.
• Leader election algorithms, which describe how a cluster of nodes without a leader can communicate with each other to choose exactly one of themselves to become the leader. 
• Caching, a technique that stores copies of frequently used application data in a layer of smaller, faster memory in order to compute costs and to improve data retrieval times and throughput.
• Sharding, 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.
• Polling, SSE, and WebSockets, techniques for streaming high volumes of data to or from a server.
• Queues and pub-sub, mechanisms that allow a system to process messages asynchronously, avoiding bottlenecks and help the system to operate more efficiently.

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

4.2 Learn an answer framework

As you likely noticed in the common questions section, we recommend using a repeatable answer framework when answering system design interview questions. 

1. Ask clarifying questions

First, spend about five minutes checking in with your interviewer about the functional and non-functional requirements of what you’re going to design. Ask about the system’s goals and how they will be measured. Be sure that you fully understand the question before moving forward.

Call out any assumptions you’re making that will influence your design approach. If applicable, ask about non-functional requirements such as availability, consistency, scalability, etc.

2. Design high-level

Start the high-level design by specifying one to two metrics (e.g. number of users added, products sold before vs after a feature launch, etc.). Then use these metrics to do some simple calculations in order to find the optimal usage pool of the system.

Once you’ve defined your metrics, map out only the most functional components of the system (e.g. front end, web server, database, etc.).

Finally, before getting into the more detailed aspects of your system, make some decisions on how you will design its database. Choose whether it will be a relational or a NoSQL database, as well as its metadata and table structure.

3. Drill down on your design

If you haven’t already, start mapping out the system on your whiteboard. Talk through your diagram so that your interviewer is able to follow along and ask questions when necessary.

Consider any bottlenecks that may arise when it comes to the system’s scalability, performance, or flexibility.

To finalize your design, play to your strengths by choosing a component you’re more familiar with and drilling down on it. If you’re not sure which component would be best to explore, ask your interviewer.

4. Bring it all together

Before wrapping up the round, take about five minutes to re-examine what you’ve designed. Does it meet the objectives you laid out with the interviewer at the beginning of the session?

It is okay to change some components at this stage if you think it will improve the system, but you must explain to the interviewer what you are doing and why.

Learn more about that framework in our guide on how to answer system design questions. 

Apply this framework to practice questions like those we’ve included in this article. Use it on different types of questions in a variety of subjects, so that you learn how to adapt it to different situations and respond to unpredictable questions on the fly.

4.3 Tips to improve your interview techniques

For this section, we’ve gathered tips from two of our system design interview coaches, Mark and Xiao. Collectively, they’ve conducted hundreds of interviews, both actual and mocks, at Google and Amazon. Here are their tips, based on what they’ve seen on the ground:

Tip#1 Communicate efficiently

45 minutes is an artificially compressed time. You won't be used to working and talking about things at this speed and so you need to practice communicating with the interviewer efficiently. 

During your interview, you don’t want your interviewer to wonder about what you’re working on. “What you need to do is keep your mental model of what you’re thinking and their mental model as closely aligned as possible,” Mark says.

Your task is not to get your interviewer to agree with you on everything. Instead, you have to make sure they can follow your thought process. 

This won’t come naturally, but you can get used to it with practice.

Tip #2 Scope the problem

According to Xiao, one of the most common system design interview mistakes is jumping straight into design without scoping out the problem first. 

You're often asked to design entire large-scale systems like Spotify or YouTube. In ~45mins, this is impossible, so Mark’s tip is to “scope the problem to a size that you think you can complete during the interview.”

Start by clarifying the requirements with your interviewer and making clear assumptions if details are vague. 

Focus on a specific, crucial part of the system, such as the backend architecture or a particular feature (e.g., if you were designing Spotify, this might be the music recommendation engine). Be ready to adjust your scope based on the interviewer's feedback.

Tip #3 Start drawing ~15mins in

Drawing is an important visual aid to help the interviewer understand your answer. Try to start drawing around a third of the way into the interview. 

This timeframe is important to consider, according to Mark. “If you start drawing too soon, you might start going down a road that doesn’t address the problem.” If you start too late, say 20 or 30 minutes in, you may run out of time to finish drawing your design.

Tip #4 Start with a simple design

Xiao says that candidates often make the mistake of designing for unrealistic scale without grounding in problem constraints, and not prioritizing or evolving the design incrementally. 

To avoid this, Mark’s advice is to get to a working solution first, then iterate. Don't get sidetracked and add requirements that didn't exist in the question. These will complicate your design.

You can always mention something and come back to it later. For example, "we'll need to use caching here but I'll come back to that later."

Tip #5 Properly understand the problem

“It’s very tempting for us engineers to hear somebody describe a problem and immediately go into solutions mode,” Mark says. This is natural, as this is what engineers have been trained to do.

However, this prevents you from truly understanding the problem and might even prevent you from catching some wrong assumptions.

So his tip is to imagine you're calling your own APIs and think about specific use cases. This will help you ensure you really understand what the problem is and what the objective is. It can help you catch assumptions you’ll likely make in your instant solution mode.

This will also help you avoid the mistake of glossing over trade-offs, failure scenarios, or state consistency, which is another common mistake Xiao has observed.

Tip #6 Practice, practice, practice!

There is a knowing and doing gap with system design interviews. Learning the theory and reading prep guides is great, but you need to practice out loud with friends or experts, or at least record yourself and watch yourself back.

Another benefit to practicing that Mark has observed in his clients is increased confidence and lessened stress. 

If you do some mock interviews, which are hugely helpful, ideally allow time for a long feedback and conversation afterward. You can start with our guide to the best system design mock interview services here.

Tip #7 Explain your thinking

Give your reasons as to why you're making each choice you do. Why did you choose one particular technology over another one? 

As an interviewer himself, Mark says that he wants to understand what's behind a candidate’s thinking in order to assess their level of technical judgment. 

“Not only do you understand why you're making a choice and the different aspects of different technology choices, but you're also communicating it to me in a way that I can understand.”

Tip #8 Get comfortable with the math

For FAANG companies, scale is important in system design interviews. That means you're going to have to do some back-of-the-envelope calculations early on in your design. Get used to calculating queries per second and the storage capacity needed.

Tip #9 Use the drawing tool efficiently

Your drawing is a visual aid, it doesn't need to look pretty, but you do need to be able to create boxes, shapes, and arrows quickly without having to think much about it.

Try to find out which tool the company you're interviewing with will want you to use and make sure you're comfortable using it. 

Tip #10 Utilize a range of prep resources

There are some great resources out there, so make sure you use them, ideally both written and video content. There will be some differences of opinion as there is not one catch-all "recipe" for successful system design interviews, that's normal.

For more explanation around these tips, watch the full video with Mark.

4.4 Know your target company

If you already have a system design interview scheduled at a specific company, take the time to familiarize yourself with how its entire interview process works.

You also want to know if they have specific requirements for their system design interviews in particular.

For example, Google system design interviewers prefer that candidates refrain from using specific products (e.g. certain databases, load balancers, etc.). Instead, they require candidates to build from scratch. This is to make sure they know how these components work, rather than resorting to a product that takes care of certain aspects like sharding.

Meta, on the other hand, might give you the option to choose between a system design and product architecture/design interview. Meta system design interviews are focused on large-scale distributed systems, while product design are for user-facing products, i.e., APIs, data modeling, etc.

Also, include in your research your target company’s engineering challenges. The official company websites of most FAANG companies will typically have a dedicated engineering blog like Uber and Meta.

To get started with your research, check out our interview guides for engineering roles at some of the world’s top companies. 

• Meta software engineer interview guide
• Meta engineering manager interview guide
• Meta technical program manager interview guide
• Google software engineer interview guide
• Google engineering manager interview guide
• Google technical program manager interview guide
• Amazon software development engineer interview guide
• Amazon software development manager interview guide
• Amazon technical program manager interview guide
• Microsoft software engineer interview guide
• LinkedIn software engineer interview guide
• Airbnb software engineer interview guide
• Uber engineering manager interview guide
• NVIDIA software engineer interview guide

You can also read our company-specific system design interview guides:

• Amazon system design interview
• Google system design interview 
• Meta system design interview

4.5 Practice answering questions

You'll need to spend a good amount of time practicing answering questions on your own or watching mock interviews on YouTube.

We’ve linked to quite a few mock interview videos in Section 2. If you want to watch more videos, here’s a list.

The easiest way to start practicing under simulated interview conditions is to practice interview questions out loud or with peers. But if you want to get more actionable feedback and company-specific tips, we highly recommend practicing with an expert.

4.5.1 Practice by yourself

A great way to start practicing is to interview yourself out loud. This may sound strange, but it will significantly improve the way you communicate your answers during an interview. 

Use a piece of paper and a pen to simulate a whiteboard session, or use a whiteboard if you have one. There are also online whiteboarding tools like Excalidraw, Visual Paradigm, or Sketchboard.me, which are particularly useful to practice for virtual interviews.

Play the role of both the candidate and the interviewer, asking questions and answering them, just like two people would in an interview. Trust us, it works.

4.5.2 Practice with peers

Once you've done some individual practice, we strongly recommend that you practice with someone else interviewing you. 

If you have friends or peers who can do mock interviews with you, that's an option worth trying. It’s free, but be warned, you may come up against the following problems:

• It’s hard to know if the feedback you get is accurate
• They’re unlikely to have insider knowledge of interviews at your target company
• On peer platforms, people often waste your time by not showing up

For those reasons, many candidates skip peer mock interviews and go straight to mock interviews with an expert. 

4.5.3 Practice with experienced system design interviewers

In our experience, practicing real interviews with experts who can give you company-specific feedback like Xiao, Mark, Tim, Karthik, Ramprasad, and Pranav makes a huge difference.

Find a system design interview coach so you can:

• Test yourself under real interview conditions
• Get accurate feedback from a real expert
• Build your confidence
• Get company-specific insights
• Save time by focusing your preparation

Landing a job at a big tech company often results in a $50,000 per year or more increase in total compensation. In our experience, three or four coaching sessions worth ~$500 make a significant difference in your ability to land the job. That’s an ROI of 100x