Systems design interview guide
This document provides recommendations on how to prepare for systems design interviews and what to do and not to do during such an interview.
About the authors
Usman Masood is a VP of Engineering at Pipe and a systems design mentor at Outtalent. Previously, he worked as an engineering manager at Stripe, as well as a software engineer at PipelineDB, Locu, Facebook, and Microsoft.
Tilek Mamutov is a co-founder of Outtalent. Previously, he worked as a Project Lead at Google[x], as well as in multiple software engineering, business, and other roles at Google.
Introduction
The goal of this guide is to help software engineers show their best in systems design interviews at big tech companies. We provide tips on how to prepare for the interview, a framework for how to approach the interview, and what you should avoid during it.
These recommendations helped each Outtalent fellow we worked with get 2 to 5 offers at companies like Amazon, Facebook, Flexport, Google, Microsoft, Spotify, Stripe, and Uber.
Preparation: Theory
Here are key topics we recommend reading up on.
If you are targeting more junior roles that usually require 2-5 years of experience:
Back-of-the-envelope calculations
Databases
Caching
Asynchronous processing
Availability vs consistency
Consistency patterns
Availability patterns
If you are targeting Senior Software Engineer or Staff Software Engineer roles:
Application scaling
Distributed systems (consensus + distributed transactions)
Advanced data structures
Probabilistic data structures
Trees, e.g. B-trees, Quadtrees
SLA, SLO, HADR, BCP, Observability, Monitoring
We recognize that there are a lot of resources on this topic and you can go fairly deep into any of these topics. To address that, we recommend starting off with the following two resources:
Designing Data-Intensive Applications book by Martin Kleppman
System Design Primer by Donne Martin (free)
Once you’ve gone over this material, find additional resources for topics where you feel you need to build more understanding and intuition.
You can also review an online course called Grokking the System Design Interview. We think there is a lot of useful information there, but please note that it focuses a lot on showing what the final infrastructure for services like Twitter may look like. In our guide, we recommend by default starting with a simple solution first. Plus, we think you need to be able to clearly justify every added component.
Preparation: Mock interviews
Interviews require extra skills that an actual engineering job often doesn’t. For example, interview time management or collaborating with an unfamiliar person.
In order to prepare, we recommend doing around ten mock interviews. Ideally, you should practice with more senior engineers or engineering managers with experience working at and interviewing for your target companies. If you don’t have access to such resources, try out Pramp to practice with random people around the world, as well as practicing with your friends.
We think during this stage it’s very important to also get good at illustrating your ideas using diagrams in a way that is fast and visible to the interviewer. For that, we recommend either setting up a physical whiteboard or becoming proficient with a diagramming tool, like Whimsical.
If you are using a physical whiteboard, we recommend a large whiteboard as you may want to fit a complex diagram, core requirements, some estimations, and notes. Please make sure the whiteboard doesn’t take up the entire screen and you’re also visible during the interview.
Key components
Now that you learned the basic theory, we suggest using the following mental model to think of key components of a system:
Fundamental components
Data storage
Partitioning
Databases
Indexing
Caching
Data transport
Stateless services (e.g. API servers)
Synchronous vs asynchronous data processing
Supplementary components
Throughput (e.g. rate limiter, load balancing)
High availability (e.g. replication)
We hope this simple logical distinction will help you design the core system and address various design problems. You can also use different box types in your diagram to clarify this distinction.
Interview process
We believe it helps to have a basic interview structure in order to move through the interview and cover the most important topics quickly.
Here is the structure that we recommend.
Understand the problem and the requirements
Estimate the scale of the system
Define the system interface
Define the data model
High-level design with only fundamental components (data storage and data transport)
Detailed design & design iterations
We will explain each step further in the guide.
Please don’t think of this process as religious and adapt based on interviewers’ expectations. Subjectivity in systems design interviews is much higher than with algorithms interviews.
Step 0. Before the interview
On the week of the interview:
Make sure your Internet, computer, headphones, and microphone are working well.
On the day of the interview:
Try to get to a confident relaxed state. It probably won’t come as a surprise, but we have seen very strong engineers who were highly prepared still fail interviews because they got nervous. They couldn’t recall what they learned and performed worse than usual. Some successful Outtalent used meditation to get to a confident relaxed state. Some people use music or exercise. Don’t overthink it.
Step 1. Understand the problem and the requirements.
One of the most common problems we see is candidates rushing to design the solution without clearly understanding the problem. We believe it often pays off to invest time upfront and make sure you understand the problem and core requirements well.
We recommend writing down key requirements in a way that’s visible to the interviewer - on a whiteboard (if it’s big enough) or in your diagramming tool.
Start by gathering requirements that will influence the fundamentals of your design. Don't spend too much on features that can easily be retrofitted later. Making forward progress is the most important thing in the beginning. There will always be unknowns and new requirements that will become clear over the course of the interview.
If you have already seen or worked on a similar problem before, don’t rush to conclusions. Just because it feels similar doesn’t mean it is the same problem. Minor changes in the problem can lead to drastically different requirements.
Take time to make sure you clearly understand the interviewer. You may feel rushed to get started with problem-solving or feel like you're asking too many questions. Try not to worry about that too much. You will end up wasting a lot more time if you don't understand the problem and start solving for the wrong thing.
If the problem is complex, for example, it’s a service like Twitter, then functional requirements are important. If the problem is simple, then don’t spend too much time on them.
Don't ask later stage questions (for example, SLA) before you understand the crux of the problem you’re trying to solve.
Double-check with the interviewer that you have a good understanding of the problem before moving on to the next step.
Step 2. Estimate the scale of the system.
This step is important to inform our high-level design because designing for 1K user vs 1M users is a fundamental difference. 1M vs 100M users is likely a scale problem that can be addressed using scalability tricks like load balancing, caching, etc.
This estimation is supposed to be rough and quick. That’s why this step is often called a “back-of-the-envelope” estimation. Testing the precision of your estimation skills is not a primary goal of the interview.
Key parameters depend on the problem, but it can include metrics like the number of users or the number of requests per second.
For QPS, consider if machines or people are making requests. Another important thing here is a company-internal vs customer-facing system -- the former will likely have less stringent throughput and availability requirements.
Overall, we recommend demonstrating the intuition you have built with your experience. Provide your suggestion for numbers and confirm if your assumptions are correct.
Steps 3-5. Core design stage.
We recommend asking the interviewer if they want to see a simple solution first or design for the largest scale straight away. We see interviewers having strong opinions on each side of the question.
For example, you can say: “I would like to start by designing the system interface. Next, I’ll define any data models needed. Then I’ll design a basic solution and iterate on it to take care of high load and failure modes later. Does that sound good or would you prefer I design for scale straight away?”.
Make sure you are sketching out system interfaces, data models, and architecture diagrams on a whiteboard or in a diagramming tool. As the design evolves, make changes to the diagram accordingly.
It’s important to label all nodes in the diagram.
Be careful about overcommunicating.
For example, by describing all the ways a webhook can fail. Go as fast as you can, don't feel the need to spend a certain number of minutes on a section. Pay attention to the interviewer’s reaction once in a while, if they look interested in hearing more or nudge you to move forward. Don’t ask if the interviewer agrees on every step, try to use your own judgment.
Avoid academic concepts like CAP theorem unless they are critical for the task at hand and you understand them well. If the interviewer is interested, they’ll likely probe you on it anyways.
Consider planning for 2-3 years of growth of the project/company
First, just explain in words how you are thinking about the problem to make sure both parties are on the same page. Once you have clarity of the basic design in your head, translating it into a block diagram is easy.
Any design choice has implicit trade-offs. Articulate all key trade-offs well.
If you have more than 1 idea to solve the problem, tell the interviewer about them, explain the tradeoffs and why you’re going with one of them.
There is usually no clear right or wrong answer. It's usually more important to demonstrate a good thinking process.
While designing your system, make sure to keep coming back to the design parameter estimates to justify your choices based on them.
Be clear why you make certain design decisions, even if you disagree with the interviewer on the optimal design decision.
Identify the fundamental components solving a simpler version of the problem
Focus on data storage and data transport, and don’t worry about supplementary components such as load balancers and rate limiters.
Identify which part is offline and which is online.
Don't overfocus on a diagram here, focus on showing your thoughts.
Detect potential hints like "Why do you think a middle proxy layer is helpful?", or "Why do we need a separate table for such requests?".
If an interviewer made a suggestion for an alternative solution, not only is it bad to reject it without explanation, it’s also bad to accept it without explanation. Please explain whether you accept or reject.
Note: at level 6 (Staff Software Engineer level) there might be a lot of devil's advocate questions, don't get frustrated, they are looking more for ideas rather than actual solutions.
If you have a database, draft the schema in a way visible to the interviewer.
Describe actual technologies you would use (e.g. Kafka for the messaging queue or your own solution). Explain why you are choosing them.
If you don't know the technology deeply, it may be better to just mention key features of abstract technology you need (e.g. "We need a messaging queue with persistence" instead of “I will use Kafka”).
Some interviewers will care less about detailed knowledge of technologies and care more about your understanding of the types of components that are needed and what’s required from them. You should adapt accordingly.
If you know a piece of technology well and want to use it, it’s good to show off a bit of knowledge of it as well.
When choosing technology, please note that the "battle-testedness" of a technology is a valuable feature. And in real life, context matters, for example, what stack that company is using.
Step 6. Detailed design & design iterations.
At this stage, we recommend starting to think about key failure modes and specific problems that may arise. Start adding supplementary components to optimize your core design (e.g. load balancers, rate limiters, caches)
Key failure modes to consider:
Availability: can your system stay operational 24/7?
Scalability: can your system scale with the workload?
Do I have bottlenecks?
Can I handle the throughput that I calculated earlier? How do I handle it?
Reliability: is your system resilient to sub-system failures?
What are some single points of failure?
Can I recover from a machine going down? How do I recover? A good trick is to look at all the “boxes” in your diagram and think through what would happen if one of them went offline.
Recommendations:
You can review each box and each arrow for the problems above.
Try using simple solutions first.
Be careful about quickly and intuitively coming up with patches.
Make sure your patch doesn't change user requirements.
One patch is ok, ten patches likely means you may have to change something more fundamental about the solution. Take time to step back (maybe 10-15 seconds) and understand the fundamental problem deeply.
Patches often overcomplicate the design and highlight the lack of deep understanding.
After 2-3 patches start rethinking the design.
Try starting to simplify before your interviewer tells you to start simplifying. If you are not erasing or redrawing, it's usually a symptom of a bad design.
Conclusion
We hope this guide will help you better prepare and perform during systems design interviews.
Please reach out to us on LinkedIn if you have any questions, and if you would like to get personalized support from us, check out Outtalent's main page and fill in the eligibility check which should only take a couple of minutes.
All the best!
Last updated