Master System Design Interviews: A 6-Step Framework for Success
Structured approach to nail your next System Design Interview
Introduction
In my first system design interview, I thought it was just about drawing boxes and arrows. I didn't prepare well, leading to a rejection. After a year of failures and learning, I passed Meta's interview in 2020.
Each rejection taught me something new. I improved my technical skills and gained confidence. Eventually, I successfully cracked interviews at Microsoft, Amazon, Meta, Atlassian, and Airbnb.
This journey improved both my system design and interviewing skills. Looking back, I realized the mistakes that caused my rejections. And I developed a framework to handle complex system design interview problems. Using a structured approach in the 1-hour interview helped me succeed. This method also helped my friends get jobs at top tech companies.
In this article, I'll share a six-step approach to ace any system design interview. You'll learn common mistakes and how to divide the hour into six steps. I'll explain what to focus on in each step to create a complete design.
If you want to improve at system design and join top companies, let's begin. We'll look at typical candidate mistakes.
Common Mistakes
Poor time management: Spending too long on one aspect, neglecting others.
Lack of prioritization: Failing to focus on key features the interviewer wants, given the time constraint.
Shallow analysis: Not diving deep enough to justify choices or discuss alternatives, preventing interviewers from assessing technical depth.
Lack of initiative: Relying too much on interviewer guidance instead of working independently.
Overlooking bottlenecks: Not addressing how the system handles heavy loads or traffic spikes.
Now that you know the common reasons for rejection, we’ll now see how to tackle them through a structured framework.
System design interview framework
We’ll see each of the steps, what should be tackled and how much time you must allocate.
The interviews start with a one or a two liner problem statement. For eg: “Design a distributed job scheduler for a large enterprise”.
In most cases, you would be familiar with the constructs of the problem. However, you must discuss with your interviewer and understand the problem if you don’t have enough context about it. For eg: If you haven’t heard of a job scheduler, ask questions about it and its working.
Functional Requirements - 5 mins
After understanding the problem, focus on functional requirements:
List all actions the system must perform.
Prioritize the top 3 core features to design during the interview.
Make reasonable assumptions (e.g., existing user registration for Instagram's newsfeed).
Keep complex elements out of scope (e.g., treat recommendation systems as a black box).
Discuss with the interviewer about any additional constraints they want to add.
Clarify details with your interviewer, as they often want to see how you handle constraints.
Non-functional requirements - 5 min
After listing the functional requirements, you must list down how the system must achieve its objectives. These things would form the non-functional requirements.
You can refer to the below diagram for different non-functional requirements.
You must ensure that any non-functional requirement is given in the context of a functional requirement and not the system as a whole. For eg: You can have eventual consistency in newsfeed but not in user's registration. Hence, while stating it's important not to state that the system as a whole is eventually consistent.
Moreover, don't keep the non-functional requirements vague. You can make some guesstimates and quantify it. For eg: State that the latency must be less than 200 ms instead of just stating latency should be low.
Capacity estimation (Optional) - 2 min
In many system design books and courses, capacity estimation is covered, and I've noticed candidates often spend time calculating storage, throughput, and hardware needs.
I've been there myself, making incorrect calculations or wasting time during interviews. In my experience, this only shows calculation skills and doesn’t add much value to the discussion.
Now, I ask upfront if the interviewer wants to focus on capacity estimation. Nine out of ten times, they’re fine without it. It's important to clarify this early on.
That said, some design decisions do depend on calculations. For example, designing a live video system with emoji reactions would be write-heavy, so calculating requests per second (RPS) helps select the right storage system.
Core Actors, APIs and flows - 10 mins
Once you clearly understand what the system needs to achieve, the next step is to identify the core actors in your system. These are the key entities in your design. For example, in Tinder, the core entities would be Users, Swipes, Matches, etc.
This doesn't need to be exhaustive since you may not know all the required data. Just make a bullet list of the identified entities.
Next, identify the APIs your clients or services will use for communication. Note all the request/response interactions. Whether synchronous or asynchronous, these will clarify how entities in the system interact.
If working with an offline system, identify workflows with multiple steps. For example, in a job scheduler, you'd need to fetch jobs, schedule them, monitor, and trigger alarms. Note these workflows and the sequence of steps involved.
High-level architecture - 15 mins
In this step, you must walk through each functional requirement and sketch the flow from the client to the backend database. Draw the relevant entities and highlight the different flows.
Explain how the APIs would work and highlight cross-cutting concerns like rate-limiting, encryption, etc solved by components such as API Gateway.
You don’t have to be 100% correct in this as you can further iterate, and improve your design in the dive deep section. You have to actively communicate and explain each flow to your interviewer.
Here’s a sample high-level architecture for the design of Tinder along with its functional requirements.
During this process, you will get an idea of what fields are relevant for each data model. Hence, mention the important fields and ignore the redundant ones. For eg: Don’t spend time on attributes such as firstName, lastName for the User entity.
At the end, you must ensure that your high-level architecture meets all the functional requirements that were stated in the beginning.
Dive deep, Trade-offs and bottlenecks - 20 mins
After sketching the high-level design, you need to come up with a comprehensive design. In this step, you will vet whether your design meets all your non-functional requirements and constraints.
You must dive deep into each flow and justify the choice that you have made. For eg: Explain why PostgreSQL is preferred over Cassandra or DynamoDB. Similarly, rectify and use the correct data store or caching mechanisms to optimize and meet any latency constraints.
Often, there would be multiple approaches to solve the same problem. For eg: You can use Geo-sharding index provided by PostgreSQL or Elastic Search for finding nearest restaurants or cabs. In such cases, explain the pros/cons of each and why you prefer one over the other in the context of the problem.
Finally, identify the bottlenecks in your design and explain how you would address each. This could be hotspots or handling sudden burst of traffic. These are solved problems and it’s important to have a strong hold on fundamentals to tackle them.
You must make sure that your solution is complete and meets both the functional and non-functional requirements. Also, give the interviewer chance to speak and check if they need to probe any particular area during the discussion.
Conclusion
System design interviews can be challenging and often involve problems that companies take months or years to solve.
However, don't let this overwhelm you. A structured approach can help you showcase your skills effectively.
If you're struggling with system design problems, try applying a six-step approach and practicing interview questions. This method shows your ability to break down complex problems, propose simple solutions, and optimize further.
Now that you have learnt the six-step approach, try applying the same to problems such as :-
Design a Instagram newsfeed system
Design an online judge
Design a distributed job scheduler
Design a distributed web crawler
After attempting these problems, you can look at the solutions and see how you fared.
Improving at system design requires patience, perseverance, and hard work. Consistency is key, and the journey will ultimately make you a better engineer. 🚀 🚀
Before you go:
❤️ the story and follow the newsletter for more such articles
Your support helps keep this newsletter free and fuels future content. Consider a small donation to show your appreciation here - Paypal Donate