#10 Get Ready: Be Prepared For System Design Interview
Being well-prepared for a system design interview is extremely important in today's tech landscape. Make sure you spend enough time to prepare for it.
The current time in IT is quite tricky. Layoffs, 10,000 people submitting resumes for one position (true story; you can check one of the portals offering remote jobs), and a lot of stress.
It's hard to stand out enough to get an interview. That's why, once you get there, it would be a good idea to maximize your chances of getting a job. One of the recruitment stages is likely to be a system design interview, where this post is directed - I wish you knew how to approach it.
Over the last few years, I have participated in dozens of system-design interviews as both the interviewee and the interviewer. I have observed some patterns and would like to share them with you.
First, most such interviews differ greatly from how you plan the architecture in real projects. Normally, you would start the business analysis process and run workshops with domain experts and decision-makers, during which you would focus on domain discovery. Then, focus on boundaries around different business capabilities and recognize the environment around you. Finally, you would try to find technical components that match the requirements.
The system design interview usually takes 1-2 hours. There is no time to copy the steps from the real project. You must quickly understand the problem, discover numbers like daily active users, propose a technical solution, and discuss it with the interviewer. Additionally, you have to do it under time pressure. That’s it.
Most system-design interviews are based on a similar concept. You must design an application similar to YouTube, Spotify, Facebook, Uber, or a banking system. All these systems are based on similar components:
frontend (mobile and web apps)
backend (API, load balancer, API gateway, database, message brokers, storage, data streaming, cache, CDN)
It would be good to have a plan and stick to it so as not to forget something. Even better, if it would be easy to remember.
That’s why I started using the UNDER method:
Understanding the business domain. First, ensure you understand the domain for which you are asked to design the system. If this were YouTube, say that users can watch videos, upload them, add them to watching lists, etc., and tell the interviewer everything they know about it. If you do not know the domain, immediately tell the interviewer, and he will either explain it to you or ask about the other one.
Narrowing the scope. When you are done understanding the domain, narrow the scope - you don’t have more than 1-2 hours, so it is impossible to focus on each functionality. Choose one, e.g., the most critical, and ask the interviewer if it is fine to narrow the interview scope to it because of the time limit. They will often agree to it or propose another functionality to focus on.
Discovering numbers. One of the most important parts of the interview. You have to recognize the numbers you will play with. Some universal numbers will fit most domains like total number of users, daily active users, requests per second, total storage, or system availability (e.g., three-nines - 99.9%). Remember that here, you also make assumptions like there are 100 million daily active users. The exact numbers are not important, but make sure you can make such an assumption
Evaluating basic design. When you are ready with the discovery, start planning system architecture. Don't focus on scalability for now; make it clear that you need some entry point to the system, like an API, a place to store data, a database, or a place to store video files. Such a simple plan will be a great starting point for advanced discussion.
Redesigning current architecture. The most important part. This is where you will talk about scaling your system, load balancers, API gateways, microservices, database read-and-write optimization, etc. The interviewer will ask you many questions. Answer, ask questions, and discuss trade-offs.
If you want to know more about it, I invite you to watch my YouTube episode, in which I describe this method in detail.
Finally, a slide deck of the key aspects you should know about each component:
API gateway - rate limiting, authentication, supported protocols
Load Balancer - different algorithms for traffic distribution
API - REST, GraphQL, authentication, authorization, how to scale it, idempotency
Database - SQL, NoSQL, sharding (and how to do that), replicas, transactions
Message brokers - topics, publish/subscribe, inbox and outbox patterns
The more you know about each, the better.
I can also recommend two books that describe multiple problems in detail:
System Design Interview: Volume 1 by Alex Xu
System Design Interview: Volume 2 by Alex Xu
Happy weekend! :)