🐲 How to prepare the system design interview

A step-by-step framework to solve this interview + 🎁 Free Notion Template

Entry-level roles don’t have this interview and your knowledge from your time as a student is not relevant or it’s forgotten. Most people are afraid of it because they are self-taught in System Design.

Welcome to the guide all software engineers need to ace the system design interview at FAANG companies.

This is the last post in my 4 post series I’m writing about the technical interview for software engineers.

• 🗺️ How to prepare the technical interview (Contains an explanation of my study framework)

• 🧙‍♂️ How to prepare the behavioral interview.

• 🤖 How to prepare the coding interview.

• 🐲 How to prepare the system design interview. (this post).

📝 The preparation framework

This is the planning to do before grinding problems.

1) Understand the mindset of this interview

When we talk about “Designing Youtube”, you won’t design it with all its complexity.

I can tell you from working on Amazon’s Search page. There’s no way you define a system at this scale in your 1-hour interview.

The goal of the interview is to show you understand common patterns in real-world applications.

2) Identify patterns

Because a 1-hour interview is not enough to get into details of a particular platform, even when using the name of a platform as the title, the problem you’ll solve is a generic pattern.

As an example, designing the home page of YouTube (with all video miniatures) is the same kind of problem as designing a Twitter feed, Instagram feed, or TikTok feed. It’s a “social media feed” problem.

Another group could be designing Glovo, designing Uber, designing Google Maps… They are “Spatial data” problems.

When finding resources and solutions, don’t get frustrated because you don’t find anyone solving “Design Instagram Stories”, because it’s the same problem conceptually as “Design Snapchat”.

Check the 🎁 Notion template for a list of problems with their groups. It’s interesting to think about the problems separately because each app you design has its particularities.

3) Identify your gaps

You may have worked all your life with regular 3-tier web applications with a frontend app, the backend API, and the Database.

If I ask you: “Design the upload workflow for Youtube’ or “Design Twitch”, you’ll be blocked. You never worked with video processing.

Now is when you want to go through the groups of problems and identify what you don’t have any idea about.

For me most of these were completely unknown and I had to study them from scratch. That’s fine. You don’t need to become a master of all, you need to understand what elements come into play

4) Collect resources for study and practice

In the example above, if you have a gap in video processing, I’d still not recommend you to study in-depth video processing workflows.

The goal of the interview is not to show you are an expert in an area unless the position you interview for is about it. Focus on the breadth of these patterns of problems rather than depth.

From the resources in this post, pick the resources for theory and practice that you need the most.

🗺️ The interview framework

This is heavily based on the framework proposed by Alex Hu in his books on System Design.

1) Ask clarifying questions and gather all requirements

You are told the problem and it’s intentionally vague. Interviewers do this to get you talking.

Focus on writing down the functional and non-functional requirements.

Functional requirements: If your problem is “Design X product”, interpret it as defining its core functionality. Clarify with the interviewer if that’s the scope you want to cover. Examples:

1. Design Instagram/Twitter → Design the upload workflow and the feed. Assume reverse chronological order

2. Design YouTube → Design the upload (video processing) and consumption of a video. Notice how even if YouTube has a feed, it’s likely they don’t want the feed if they ask for YouTube.

Define the use cases and API design.

Depending on the problem, you’ll have a clear API that you’ll have to define (REST, RPC, GraphQL…). Other problems will not require a definition of an API but rather have the use cases “we have a read use case and a write use case”.

Define the nonfunctional requirements.

These problems are oriented to “we have to scale this to N thousand of customers and expert viral growth”.

Despite that, not all architectural characteristics are relevant to each problem. You have to understand the domain of the problem.

For a social media feed, eventual consistency is fine. It’s fine you won’t get a post until propagated to all DBs. It’s even fine losing a post. You prioritize high scalability and low latency.

For a money transaction, you can’t have eventual consistency. There’s no reconciliation possible if an account balance gets to $-1000. Also, the transactions are less frequent than people refreshing a social media feed. You prioritize data durability and consistency instead of latency/throughput

If you don’t understand the product you are asked to design, ask questions to the interviewer as a user of the platform and try to compare it with other products you know: “Is this a social media feed like Instagram?”, “What kind of content can people upload to this social media?”

To understand the problem, ask yourself questions like:

• Read vs Write traffic?

• Size limit on files?

• Encryption requirements at rest and in transit?

2) Propose a high-level design. Validate it.

The typical design of a web application contains a generic design where you name the DNS, frontend servers behind a LoadBalancer, backend servers behind a LoadBalancer, a distributed database (either SQL or NoSQL)

But that’s just memorizing and not solving the problem at hand. Create a mental checklist you go through for every problem:

• Is this workflow fully synchronous or anything asynchronous with workers?

• What’s the protocol for communication between clients and servers? regular HTTP, HTTP LongPolling, WebSockets, UDP based protocols…

• What kind of storage do you need?

• Do you benefit from caching some data?

3) Get into the details

Ask the interviewer what to dive deeper into.

Some scenarios to dive deep into could be:

1. How the database is partitioned and replicated

2. Walk through the entire request from the DNS up to your services.

3. Data modeling

You won’t have time to go into the low level for each area. Get the information from the interviewer.

4) Walk through the use cases and answer any follow-up question

Now it’s turn to go back to the functional requirements and walk through how your system solves them.

You’ll often find edge cases you didn’t consider.

⚙️Preparation resources

🧑‍🎓Deliberate study time

There’s no point in preparing for the system design interview without having a solid base on distributed systems.

Since most of this is not studied at universities and many people don’t have this exposure to large-scale systems at their day jobs, I consider the study time the most important part of this preparation.

My recommendations:

• 📚 Understanding Distributed Systems

• 📚 Web Scalability for Startup Engineers

• 📚 Designing Data-Intensive Applications

🧑‍🏭Deliberate practice time

Don’t think just studying you’ll crack the interview. You need to practice in an interview-like scenario.

Use the Interview Framework in your practice problems. Once you get stuck, leave TODOs across your design and check the answer later in a solved problem.

You may want to use mock interview platforms to practice. I have never used any and always practiced self-taught

Remember, try to solve them first, and check how other people solve them later.

• 📚 System Design Interview book 1 and book 2 by ByteByteGo

• 📚 Grokking System Design course 1 and course 2 in Educative.io (I didn’t use this, but heard good recommendations)

• Find the solved problems across the internet

  • 🔗 TianPan.co

  • 🔗 System Design Primer solved exercises

  • 🔗 System Design GitHub Chapter 5

🛡️Siege your brain time

No engineer has worked at all the big tech companies solving all the groups of problems. We all have areas we don’t know from first-hand expertise.

These resources are great for reducing your gaps:

• Read newsletters:

  • 📰

    ByteByteGo Newsletter

  • 📰

    System Design Newsletter

  • 📰

    Architecture Weekly

  • 📰

    Byte-Sized Design

• 🔗 Read real engineering blogs

• Read GitHub READMEs

  • 🔗 ByteByteGo

  • 🔗 SystemDesign

  • 🔗 Frontend-oriented

• Watch YouTube solved problems

  • 🎥 Exponent

  • 🎥 Gaurav Sen

  • 🎥 ByteByteGo

  • 🎥 System Design Fight Club

🍱 Other advice

🚀 Use ChatGPT and ChatGPT-powered resources.

There are many things in the system design interview related to the theory of distributed systems. It’s great to check out with an LLM to dive deeper and understand why using one approach or another.

I used ChatGPT to refine my understanding of event-emitting and event-processing with streaming technologies. It was like having a Senior engineer answering my doubts based on my level of understanding of the technologies.

There are also integrated platforms like Codemia where you have the LLM implicit by default. It’ll reduce the prompt engineering pre-work you have to do.

🤷‍♂️ Don’t worry if you solved the problem based on other requirements

A common concern I had is that I imagined I had to do some calculations for 1k read transactions per second (TPS) and another person would solve the problem for 50k read TPS.

Both are fine if you have the right reasoning. Don’t bother about solving with the same numbers as someone else but about your calculations and intermediate steps being right.

⭐ Focus on communicating the entire interview

Remember the goal of the interview is not creating a real product from your design, but checking how you think and reason about systems.

Communicate during the entire interview and treat the interviewer as a coworker you are doing a whiteboarding session with.

🗃️ Resources

• 🎁 Notion template

• 📚 Understanding Distributed Systems

• 📚 Web Scalability for Startup Engineers

• 📚 Designing Data-Intensive Applications

• 📚 System Design Interview book 1 and book 2 by ByteByteGo

• 📚 Grokking System Design course 1 and course 2 in Educative.io (I didn’t use this, but heard good recommendations)

• 🔗 TianPan.co

• 🔗 System Design Primer solved exercises

• 🔗 System Design GitHub Chapter 5

• 📰ByteByteGo Newsletter

• 📰System Design Newsletter

• 📰Architecture Weekly

• 📰

  Byte-Sized Design

• 🔗 Read real engineering blogs

• 🔗 ByteByteGo

• 🔗 SystemDesign

• 🔗 Frontend-oriented

• 🎥 Exponent

• 🎥 Gaurav Sen

• 🎥 ByteByteGo

• 🎥 System Design Fight Club

👏 Weekly applause

I have been doing my annual review this week and I found these posts insightful:

• How to Conduct Your Own Annual Review - Chris Guillebeau → I was doing my annual review this week. I apply many of these topics like a yearly theme and setting up milestones per area.

• Reduce the gap between idea and execution -

  Elevate
  → When planning the goals for my yearly review, I find it valuable to set micro-goals based on input rather than SMART goals based on results.

• The Personal Annual Review - Sahil Bloom → The most important part of an annual review is having the right prompts to answer with useful information. This article contains quite a few good prompts.

• Why asking your customers what they want doesn't work -

  Tech Books
  → We can’t predict HOW we’ll solve a problem in the next 365 days. This leads to goals that have to be thrown away in the middle of the year. We have to ask ourselves what job an activity does and focus on improving and fulfilling that goal. Sometimes that means throwing away your current activity.

🗞️ Other posts people like

How to prepare the coding interview

🧙‍♂️ How to prepare the behavioral interview

🗺️ How to prepare the technical interview

🚀 Skyrocket your productivity