System Design (SD) interviews are common for SDE-2 roles and beyond. Basic knowledge of systems is also expected for junior SDE positions as interviews are evolving with AI.
What are some of the things you can do so you can stand out from rest of the crowd and show a clear impact. In short, “Make Interviewer believe that you’re the one”.
Approaching System Design Problems
Every problem can be approached in a certain way and you’ve to time it to 45-60 minutes. Time allocation is equally important because you don’t want to miss critical considerations for a system.
SD interviews are generally timed interviews but I’ve seen instances where you’re given a full fledged problem statement, you brainstorm on it for a week or so and then present a solution.
We’ll discuss the step-wise structure for approaching a system design problem. For each step, we’ll also focus on important details you should keep in mind. Let’s start with first step, system requirements.
System Requirements
The first part of solving something is identifying the requirements and the same is true for system design problem statement as well. Requirements means what a system is expected to do (and not do). The requirements can be classified into two categories, functional requirements (FR) and non-functional requirements (NFR).
As part of requirement gathering, you should be clear on system expectations and don’t leave any ambiguity on the table. A recommendation for interviews is keeping a limited scope. Always try to limit the requirements, keep in mind you’ll have to fulfil those requirements in next 30 minutes.
Let’s take an example of designing Facebook. You can’t design Facebook in one hour or a week or even a year, there are a lot (a lot) of points to consider. So the next step is figuring out what part Facebook should be considered? This could be focused on photos feed, video management, handling ads, etc.
The intention of interviews is never to design full-fledged system. It’s the thought process and how you tackle an ambiguous problem. You’re not being hired to design next Facebook (this could be the case as well) but the idea is if you’re hired, can you come up with solutions to problems. And more importantly, can the interviewer work with you during the job, which mostly depends on how well you give and take feedback throughout the discussion.
A subpart of requirements is NFR. Don’t throw random words for sake of completion (because you’ve seen bunch of videos on SD interviews). The NFRs such as highly available, scalable, reliable and fault tolerant are included into the discussion without much thought.
If you say the system should be highly available, then be ready to answer:
What does available mean?
Why do you need system to be available?
How much availability?
What considerations you’ll take later to make sure the system is actually available?
This set of questions applies to every NFR you suggest. Most people can’t differentiate available and reliable, don’t be that person. If you say the application is fault tolerant, make a point during architecture discussion for what components are included (or decisions are taken) in the system ensuring fault tolerance.
Ok, moving on the next step once you’re all cleared up with the requirements; Scale.
Scale
Scale is again similar to NFR discussion. Most people include scale because they have seen a few videos or read some blog posts with mention of scale in system design interviews. What is scale and why does it matter?
Scale is one of the term, another popular term used is Back-of-the-envelope Estimation. In this step, you determine various aspects such as traffic numbers, network bandwidth, storage calculations, etc.
The numbers can’t be perfect and could be based on assumptions. The recommendation is clarify with the interviewer and what kind of scale we’re looking at? Scale matters because the system design depends on the scale numbers. The design varies by a magnitude if a system needs to support 1 million users vs 100 million users.
If you agreed on certain scale numbers in initial discussion, bring them up again during design decision making for why particular choice makes sense.
Expanding on the Facebook example from previous section, don’t just say you’ll build newsfeed and then discuss those two approaches of push vs pull published on every system design blog post. Clarity is very important, which approach works and which not depends on the scale.
System requirements and scale discussion both are part of requirements gathering. Try to limit the discuss under 10 minutes for both of these steps. After scope clarity, we move on to actual design of the system.
Start with the Design
I generally start on my system design thinking from how customers access the system. What’s the first point of interactions for the customers? From there take a very high level picture of entire system (10000 ft) and then break into components as needed.
Don’t forget to check out my books with O’Reilly for building system design thought process.
System Design From Scratch (in progress)
and subscribe to YouTube @MsDeepSingh for detailed discussions.
Once you’ve a high level picture, how should you proceed further? The SD interview is a live discussion so there is no strict format. The interview can take different directions based on communication between interviewer and interviewee. Some of the pointers include:
API design
Monolithic setup or Microservices
If Microservices, what all services and how the boundary is defined?
Database choices and schema
Networking protocols
Design choices such as sync vs async
Failure handling, etc.
Sometimes discussing algorithms is important such as how will you shorten the URL and other times the algorithms could be too low level detail. As I said, this is live discussion so there is no strict format.
Let’s take an example of another pitfall which I’ve seen during interviews. To resolve any scaling bottleneck, people right away suggest a new micro-service without clarifying how it actually solves the problem. For any new feature introduction, always ask yourself.
Do you really need a new service?
Can the existing service be extended?
Trade-off analysis is key for system design discussion. So there is no right answer or an answer with 100% upsides. The decision will depend on the requirements, scale and multiple other factors. So proper upsides and downsides for each approach helps to figure out which fits best for the given use case.
The next recommendation is to avoid memorising the solutions. Example, I’ve heard multiple times if it’s latency intensive system, you can’t use queues, it has to be synchronous system and vice versa. For all the readings you do on internet or watch videos, always try to think on your own, why particular decisions are being made. Recommendation is to read company blogs for insights on actual production systems.
A general discussion that comes up during interviews is database choices, let’s discuss it in more details.
Database Choice
Database choice discussion is among the popular ones in SD interviews. The low level schema is mostly deferred for high level design interviews but are important for low level design interviews. How will you choose a database for give problem statement?
The recommendation is to avoid phrases like,
because there are 100 million customers or huge dataset, I’ll use non-relational database.
because there is transactional data storage requirements, I’ll use relational databases.
The choice of database should be derived based on similar factors as how we gather requirements for overall systems. There is a more detailed blog on database choices, please read -
The choice of database is highly dependent on the query patterns. You store the data in such a way such that it’s retrieval is faster. Other factors include cost (operations and infrastructure), ACID compliance, previous expertise, etc. The discussion could further move to database scaling, so you should be prepared to answer accordingly.
Relational databases such as MySQL or PostgreSQL solves most of the use cases. If you don’t know which database to pick, start with relational databases.
System health is another important discussion which holds good value during the system design interviews. Let’s focus on system health next.
System Health
System health means system is working as per the expectations and there is no degradation. Here are a couple of things to consider.
Failures and faults happen in live systems. This could be API failures or system in whole. The system should be able to handle these scenarios gracefully.
What if certain components in the system break, ways for graceful degradation. It involves discussion around if the components are decoupled enough.
Monitoring, logging and alerts are important to monitor the health of the system. The combination of three is often referred to as Observability. This helps you to figure out if something goes wrong so never skip this part.
This is all for today’s discussion. Let’s summarise.
Closing Thoughts…
Remember, no architecture is final or best architecture. Every decision in designing systems holds trade-offs. You should clearly specify why a particular decision makes sense for a specific scenario. Think before you answer to certain question, your capability to ask right questions matters a lot. If you’re asked to improved database performance, then don’t directly say I’ll use cache. First analyse why the bottleneck exist, introducing a cache might help or not.
If possible, take examples from your previous projects if any trade-off analysis matches the situation. Personal experience adds a lot of value. There are some lesser focused upon topics in SD interviews due to time constraints and you can consider depending on time and problem statements. The topics include security, application deployments and managing operational overhead (in addition to observability).
Here is the complimentary video on YouTube discussing “How to win System Design interviews” :
With all these TIPS, I’ll leave you with your preparation. Best of luck :) Apart from self-preparation, try mock interviews with your friends (or anyone) and analyse on what went wrong (and right).
For any questions, you can comment here or DM on LinkedIn.