Course · 01 Orientation
Introduction
How system design interviews work and what interviewers are looking for.
After conducting literally thousands of interviews at companies like Meta and Amazon, we've collected the most important things that candidates need to know to succeed in system design interviews. This course works backwards from the skills you need in the interview, then puts the material in an order that builds from the delivery framework and core concepts to complete design problems.
This is helpful for two reasons:
- You always know what to study and practice next, and
- As you learn new things you'll be able to connect them to real systems and real problems rather than just accumulating academic knowledge.
Other system design materials are either ChatGPT spew or go to a level of depth that you'll never possibly cover in an interview (and might be a yellow flag if you do). We aimed to keep this course dense, practical, and efficient.
Ready? Let's go.
What are system design interviews?
System design interviews are a way to assess your ability to take an ambiguously defined, high-level problem and break it down into the pieces of infrastructure that you'll need to solve it. These are practical interviews, not strictly academic ones, and most engineers find they are closer to real-world work than other types of interviews like the leetcode style interview.
Importantly, design interviews are not about getting to a single right answer. For many questions, there are many right answers. Instead your interviewer is looking to assess your ability to navigate a complex problem, reason about trade-offs, and communicate your thinking clearly.
Most entry-level software engineering roles will not have a system design interview (though there are plenty of exceptions). Once you've reached mid-level, system design interviews become more common. At the senior level, system design interviews are the norm and carry a disproportionate weight in the overall evaluation process for the candidate.
Types of System Design Interviews
Each company (and sometimes, each interviewer) will conduct a system design interview a little differently. You can get a sense for what to expect by browsing some of the community-reported questions we've collected. The overwhelming majority of system design interviews will be what we'll call "Product Design" or "Infrastructure Design" interviews.
In these interviews you'll be asked to design a system behind a product or a system that supports a particular infrastructure use case like "Design a ride-sharing service like Uber" or "Design a rate limiter". These problems typically require infra: services, load balancers, databases, etc. If this is you, this course is for you.
6 types of software design
interviews
Not the right spot?
- If you are planning for an interview where you'll be instead be asked to design the class structure of a system, that's an interview we call "Low-Level Design" (sometimes referred to as "Object-Oriented Design"). For these interviews, we have a different guide for you: Low-Level Design in a Hurry.
- If your interview includes ML modelling, feature engineering, and other facets of an applied ML engineer's role, we call that "ML System Design" and have created the ML System Design in a Hurry guide.
- Finally, if you're interviewing for a frontend engineering role, we highly recommend our friends at Great Frontend for both material and practice problems for frontend design interviews.
Assessment
The interviewers conducting system design interviews are looking to assess certain skills and knowledge through the course of the interview, and we'll walk you through their thought process as we go.
At a high-level, while all candidates are expected to complete a full design satisfying the requirements, a mid-level engineer might cover the basics well but not into great depth, while a senior engineer will quickly work through the basics leaving time for them to show off the depth of their knowledge in deep dives.
Sounds abstract? In our problem breakdowns, we list out the expectations of a candidate for each level for that specific problem so you can get a good idea for how the interview will be assessed.
If you're a staff+ engineer, we have some guidance specifically for you in our
Staff-Level System Design blog post.
Staff-level interviews are different from lower levels and you'll need to
adjust your approach accordingly.
Each company will have a different rubric for system design, but regardless of level these rubrics have strong themes that are common across all interviews: Problem Navigation, Solution Design, Technical Excellence, and Communication and Collaboration. They might use different words, but they're going to touch on the same things.
Interviewer Rubric
Problem Navigation
Your interviewer is looking to assess your ability to navigate a complex, under-specified problem. This means that you should be able to break down the problem into smaller, more manageable pieces, prioritize the most important ones, and then navigate through those pieces to a solution. This is often the most important part of the interview, and the part that most candidates (especially those new to system design) struggle with. If you don't do this well, you'll burn time solving the wrong problems all the while leaving a poor impression on your interviewer.
The most common ways that candidates fail with this competency are:
- Insufficiently exploring the problem and gathering requirements.
- Focusing on uninteresting/trivial aspects of the problem vs the most important ones.
- Getting stuck on a particular piece of the problem and not being able to move forward.
- Failing to deliver a working system.
The reason many candidates fail to make progress in their interview is due to
a lack of structure in their approach. We recommend following the structure
outlined in the Delivery Framework
section to give yourself a track to run on.
Solution Design
With a problem broken down, your interviewer wants to see how you can solve each piece. This is where the core concepts from the Fundamentals chapters come into play. You should be able to describe how you would solve each piece of the problem, and how those pieces fit together into a cohesive whole.
The most common ways that candidates fail with this competency are:
- Not having a strong enough understanding of the core concepts to solve the problem.
- Ignoring scaling and performance considerations.
- "Spaghetti design" - a solution that is not well-structured and difficult to understand.
Interviewers are on alert for candidates who have simply memorized answers or
material. They'll test you by probing your reasoning, doubting your answers,
or asking you to explore tradeoffs. This is where having solid fundamentals
which we'll cover coupled with appropriate depth are going to be critical to
your success.
Technical Excellence
To design a great system, you'll need to know about best practices, current technologies, and how to apply them. This course introduces those technologies in context, so you can describe how you would use them with well-recognized patterns to solve the problem.
The most common ways that candidates fail with this competency are:
- Not knowing about available technologies.
- Using antiquated approaches or being constrained by outdated hardware constraints.
- Not knowing how to apply those technologies to the problem at hand.
- Not recognizing common patterns and best practices.
Hardware has not stood still over the last decade, but much system design
material is still stuck in 2015. In this course we'll carefully call out those
places where outdated approaches are no longer applicable. You'll also learn
numbers to know that
will help you make better decisions.
Communication and Collaboration
Technical interviews are also a way to get to know what it would be like to work with you as a colleague. Interviews are frequently collaborative, and your interviewer will be looking to see how you work with them to solve the problem. This will include your ability to communicate complex concepts, respond to feedback and questions, and in some cases work together with the interviewer to solve the problem.
The most common ways that candidates fail with this competency are:
- Not being able to communicate complex concepts clearly.
- Being defensive or argumentative when receiving feedback.
- Getting lost in the weeds and not being able to work with the interviewer to solve the problem.
How to Use This Course
Work through the required course steps in order. The early chapters pair video walkthroughs and written guides with short quizzes. Later chapters put practice first: you'll attempt a real interview problem, review the solution, and then study the pattern behind it.
Some chapters include an optional video review after a practice problem. Watch it when you want to compare your approach with ours, or move on if the written breakdown gives you what you need. Optional reviews don't count toward course completion.
Lastly, we firmly believe you need to practice to ensure you're comfortable the day of your actual interview. A common failure mode for candidates is to have consumed a lot of material but stumble when it comes time to actually apply it. That's why quizzes and Guided Practice are separate course steps instead of extras at the bottom of an article.
Conclusion
Next up is the Delivery Framework, the structure you'll use for every design in the course.
If you've got questions as you make your way, the comments are a great place to ask them. You can also highlight text and click "Ask Tutor" to get a quick answer from our AI tutor, grounded in the context of this course and with relevant references so you can learn more.
Lastly, we're constantly updating our content based on your feedback. If you have suggestions or feedback, please leave them in the comments below. And thanks in advance!
Your account is free and you can post anonymously if you choose.