Published on

FAANG Interview – System Design

Authors

System Design Overview

In this post, I will cover the basic structure of the system design interview, how to answer it properly, and study resources. This study structure applies to system design interviews at FAANG. Note that the system design interview is different from the ML system design interview, which I'll cover in a future post.

The system design interview is designed to assess your ability to build systems just outside your normal domain. While it can cover a wide range of design choices – data model design, storage solutions, API design, etc. – system design interviewers typically deep dive into certain areas in which they sense you have experience so that they can extract the most data about your design abilities in the constrained interview window. And since system design skills vary among engineers specialized in product/application, infra, ML, and mobile, each interviewer is specifically chosen based on your résumé and initial phone screen cconversation with a recruiter.

The reason the system design problem is just outside your normal domain is if you were given a problem with which you were incredibly familiar, it'd be harder for the interviewer to assess your reasoning skills – you would be very comfortable regurtiating what you already know with little adaptation.

Again, since a system design interview can span many topics, it is beneficial to memorize a general template to follow so that you cover as many areas as possible. The following covers a typical 45 minute interview, which is typical at FAANG.

Problem Space Exploration

❌ Do not do this: Junior engineers typically jump straight into coming up with a design.

✅ Instead, take about 3-5 minutes orienting yourself around the problem and the context. Interviewers are trained to look for this. Ask questions to define the business goal you are solving, to reduce ambiguity, and to eliminate subproblems the interviewer isn't interested in hearing you solve. This will help you focus on what the interviewer is looking for. Remember, the real goal here is to pass the interview. While this section is the shortest in the interview, it is arguably the most important in that it helps you ensure that you are solving the problem the interviewer is asking. Many times candidates waste too much of the interview solving a problem the interviewer never asked and realize it too late. Furthermore, this section demonstrates to the interviewer how senior of an engineer you are – the more senior ones focus on defining the problem clearly – and the points you make will be used in leveling discussions (e.g., senior, staff, principal engineer, etc.) with the hiring manager. In fact, the leveling rubrics heavily favor engineers who demonstrate good problem space exploration.

Example questions to ask:

(Note: adapt these to the problem you've been presented)

  • What's the business context for the problem?
  • What are the success metrics?
  • How many users should the design handle? For example, 1 million or 100 million?
  • How many entities should the design handle? For example, 10 million rental properties or 100 million?
  • What kind of latency is the product specifying?
  • Any legal or privacy related issues to be aware of?

End to End Design

Spend the next 10 to 15 minutes drawing a simple diagram of a working system. How do you define "working"? Imagine that at the end of the system design interview, you need to hand the design to a group of engineers. Looking at your design, they should be able to implement a solution without any more design choices needed. Thus, it does not need to be fancy. It just needs to work.

Keep it simple. Only add components to your design as necessary. Do not overcomplicate it in the beginning. Too many candidates add unnecessary components such as a cache or a load balancer or a queue, but unless you know exactly why you've added it, resist the temptation. An experienced interviewer will ask you exactly why you've added the component, and if you don't have a good answer, it'll count against you.

Solve for the most common use cases first. Along the way, if you sense an area will run into complicated edge cases, mention it out loud to the interviewer that the component will need to be adjusted for the edge cases you have in mind. If the edge cases will drastically alter your design, then you'll need to account for them right then and there. If not, tell the interviewer you will revisit the edge case after you've completed an initial sketch of the diagram.

Follow the data. A great way to keep the design as simple as needed is to specify the exact pieces of data that will be processed by your system. Then, create components that will pass along or transform the data. As you create these components, discuss exactly how it will handle the data. If you find yourself unable to specify this, then perhaps you don't need the component. This also allows the interviewer to understand your design.

Subscribe to receive future guides on FAANG interview preparation. Unsubscribe any time.

Technical Depth

While designing your system end to end, the interviewer may probe you for deeper technical details of components you have defined. This where the 15-20 minutes of buffer left over from problem space exploration and end to end design matter.

Even though you're in a system design interview, you should be prepared to implement algorithms in pseudocode so that the interviewer can be confident that you know how to produce a working design without being overly reliant on an off-the-shelf component. If you do specify that you will use an open source component to handle the data processing, be prepared for the interviewer to ask you for a detailed description of how it works. As mentioned above, you need to go into system design interview with the mindset that the result of your design from the interview can be handed to engineers so that they can implement it with no further instructions. If they don't know the algorithm to use in a particular component, then a crucial element of your design is missing.

The interviewer will also ask you to perform quantitative analysis. This requires simply back of the envelope math. For example, you may be asked to estimate the number of storage databases.

❌ A poor answer: I think maybe three instances of the database are enough based on my experience.

✅ A good answer: Since we are storing 100 million objects, and each of these objects is approximately 100 bytes in size, we need to store 10^2*10^6 objects * 10^2 bytes / object = 10^10 bytes = 10 GB. Today's hard drives can easily store 10 GB of data, so we'll need just one distance of the database. For fault tolerance, we will have a backup instance of the database as well, so in total we'll need two instances of the database.

Technical Communication

During the system design interview, the interviewer is also constantly assessing your ability to communicate your reasoning in a logical and structured manner and the technical language you use in areas of expertise.

Common Mistakes During the Interview

  • ❌ Not defining the problem at the beginning. To reiterate, spend the first 3-5 minutes asking the interviewer to specify the system. This allows you to design for the correct problem, and the more senior the role, the more you are expected to dedicate time to this.

  • ❌ Regurtiating unnecessary components. Too many candidates add a load balancer, a cache, a queue, etc. without thinking about why it's needed. The interviewer will count this against you.

  • ❌ Using "feelings" instead of back of the envelope calculations. During the interview, you'll need to spend some time estimating the number of servers, the number of databases, the total size of the data, etc. A bad answer would be, "I feel like 10 databases are enough." A good answer would be, "each server can handle approximately 5000 QPS, and we calculated that we're expecting 50,000 QPS, so we'll need approximately 10 servers. However, to account for spikes in traffic, we'll need to double that to 20 servers." Let the interviewer know you are grounding your decisions in back of the envelope math.

  • ❌ Not rounding numbers for quantitative analysis – An engineer should use system design to make rough estimations. In an interview, you typically don't have time to perform very accurate calculations, nor will the interviewer expect you to. When gathering numbers for your calculations, round to multiples of 5 or 10 to simply the math. For example, if your calculation requires the number of hours in a day, use 25 or 30 instead of 24.

System Design Preparation

There are several resources I'd recommend to prepare for system design interviews (purchasing the referenced books through the links below helps to support this website at no additional cost to you):

System Design Interview – An Insider's Guide: Volume 1, https://amzn.to/3zITkBl – If you're short on time and need to study for an upcoming full round of interviews, practice the problems in this book. The book covers a wide range of problems you'd encounter in interviews. Use ChatGPT or your chatbot of choice to help you come up with alternative solutions during your preparation. Here are the problems you'll see in this book:

  • Design A Rate Limiter
  • Design Consistent Hashing
  • Design A Key-value Store
  • Design A Unique Id Generator In Distributed Systems
  • Design A Url Shortener
  • Design A Web Crawler
  • Design A Notification System
  • Design A News Feed System
  • Design A Chat System
  • Design A Search Autocomplete System
  • Design Youtube
  • Design Google Drive
  • The Learning Continues

System Design Interview – An Insider's Guide: Volume 2, https://amzn.to/4gJg7h3 – Same as the above book, if you're short on time, practice the problems in this book. If you practice the problems in both Volumes 1 and 2, you'll pretty much cover the vast majority of the system design problems you'll encounter in interviews. You may see some variant, but you'll be prepared.

  • Proximity Service
  • Nearby Friends
  • Google Maps
  • Distributed Message Queue
  • Metrics Monitoring
  • Ad Click Event Aggregation
  • Hotel Reservation
  • Distributed Email Service
  • S3-like Object Storage
  • Real-time Gaming Leaderboard
  • Payment System
  • Digital Wallet
  • Stock Exchange

Designing Data-Intensive Applications by Martin Kleppmann, https://amzn.to/3Y8Fkuc – If you have 2 or more months to prepare for interviews, this book doubles as a practical guide to building scalable systems and preparing for system design interviews.

To hone your end to end design skills, I would recommend reading chapter 2 on data models so that you learn how to specify simple but useful schemas that need to be defined since it's the data you'll be passing around in your design from component to component. The section on relational models vs NoSQL briefly discuss the tradeoffs of picking one over the other, which you'll need to present to your interviewer to demonstrate your ability to consider tradeoffs, a signal interviewers use for leveling discussions (i.e., are you a senior or staff engineer?).

In chapter 4, the section on Thrift and Protocol Buffers, which are used at Meta and Google, respectively, are useful to understand how data looks when transmitted across the wire. Then, move onto the section about modes of dataflow, which is useful knowledge when specifying the flow of the data in your end to end design.

Chapters 5 and 6 on replication and partitioning are useful because most system design interviews will require you to scale the system and you'll need to be knowledgeable of how to back up the data and split the data across databases.

Read the chapter on Consistency and Consensus because in the problem exploration portion of the interview, you'll need to think about whether or not you want to design an eventually consistent system or one with stronger consistency guarantees. This is a design choice you'll state up front and justify based on the business context, and it'll affect the database decision you make. Be sure to brush up on the CAP theorem as well.

Read chapter 11 on stream processing, specifically the section on messaging systems to understand producers and consumers use queues to communicate. Message queues are used often at FAANG and in system design interviews.