Here’s a post summarizing the key points from a AMA (Ask Me Anything) session that was conducted on SDE Skills forum in 2020. The session invited questions related to the system design interview process and was led by Vivekanand Kirubanandan, who comes with 15+ years of software development, and has been a former Amazon Bar Raiser with ~600+ interviews.
If you have questions around the overall software engineering interviews (that includes questions around levels of hiring at different companies, coding practice etc.), please refer to the the post here.
Here is how you can reason about the considerations to designing a system. Let us define what is a system - a set of things working together as parts of a mechanism or an interconnecting network. So how will you go about designing a system? First step is to understand what the “different” components are and how they interact with each other. The roles and responsibilities of each component, and the expectation/dependency that each component has with each other.
During the interview process, I tend to split the interview into four “phases”. Requirements Clarification, Problem Solving, Implementation and System Verification. During each phase, this is what I look for (and I suspect most interviewers do something similar). The fundamental question I am trying to get an answer for: Can you, the candidate, design a system that meets a requirement that we may have?
Here are some of the check-boxes I need you to tick to be successful.
The fun part (as an interviewer) is that there is no difference in the question that I/we ask between the level of the candidate. What is different is the responses.
System design cannot be “learnt” from text books that easily. Junior engineers typically have this sort of text-book knowledge. Sr Engineers typically have a wider gamut of experience.
It is quite easy to distinguish. As long as you are not pretending, it is not bad. This is similar to how you can talk about visiting a specific city. Say you have never been to Paris. a. you can either read about it and pretend to have visited it. b. talk to someone who has visited that city and then “inherit the knowledge”. c. talk about another city with similar properties.
These are okay, but nothing beats real experience.
There is no replacement for real-life experience. In the absence of that, I would recommend the following resources.
Reading papers are useful only if you are already at a specific level.
You have to go through the motions of designing it. Even if you do not have such possibilities, try to acquire this knowledge second hand (talking to people, and discussing their designs for their problems).
Design Fractally! Start with super high level, and iteratively refine each segment. This is good, because your design always works all the time. With more time, you are just refining each section and are making your design more robust. You also let your interviewer dive into areas he/she is interested in.
I am super partial. Here is a list i often share.
Ask the recruiter to provide a better system design collaboration tool like - https://sketchboard.me/home. Tools like google drawing won’t be great.
Nothing works then just share your screen. And have some tools where you have practice a lot. It could be draw.io.
You may not have spent enough time on requirement clarification? Empathise with the customers?
Not super relevant for junior engineers, but extremely relevant for senior roles.
Great question! There are no “single best solutions” for any question. I prefer the trade-off based solutions.
How do you solve questions that you do not know answers to? The idea is to come up with a generic problem solving framework that you can use to arrive at a solution with interviewers help.
Calculation needs to be done at three parts. a. during requirements gathering: high level calculations b. during implementation: more detailed QPS, find system chokepoints etc. c. during verification phase: wil your system design work?
You need to be at a specific skill level before this is useful!
Start from use-case. What are the ways the user can do a search? Do we need search by location, number of rooms, price, search matching the description, do we have search based on distance criteria like 100 miles within SF or Seattle. Thoughts around data structure - if the user is more interested in houses by number of rooms, or price, or a combination of many such criterias. This might help us decide how we might want to structure the data. For questions around load balancers, replication - think about what questions do you need to ask to get to this decision?
1) Is it a telemetry system? 2) Is it a command/control system? 3) How do you deal with low bandwidth, high latency networks between the control center and the module? The system should be able to provide acknowledgements and account for loss of acknowledgment.
Liked this post or have further questions? Check out and participate in our active sessions by joining our discord server. SDE Skills is a non-profit organization with the singular vision to bridge the gap between the skills job seekers possess and the skills that they need to succeed. We provide the resources and support necessary to maintain the sharpness of technical skills. it is founded by Vivekanand Kirubanandan, and currently co-organized by many leaders along with many volunteers and thousands of active members across the globe.