System Design
🗺️ 日本語版は システムデザイン 🇯🇵
A typical system design interview will take up to 40~50 minutes. Some companies do “smaller” system design interviews, such as using 15 minutes to talk about how a circuit breaker works at a high level. But in general, the fundamental of preparation is the same. If you have no idea what a system design looks like, here is an example you can watch.
https://www.youtube.com/watch?v=tndzLznxq40
You can expect a system design interview to be:
- Open-ended discussion using an online whiteboard tool to check your capability to design end-to-end reliable and scalable distributed systems.
- There will be many open-ended questions about usability, scalability, performance, and technologies. You are expected to clarify the scope, and requirements as necessary in the discussion with the interviewer.
Mindsets
- Don’t think like a coder. Think like a Tech Lead.
- While there are wrong solutions but there is no “right” and the only way to design a system.
- Communicate, communicate, communicate.
What the interviewer wants to see
It’s impossible to design a Twitter in an hour. What interviewers want to see are usually:
- A broad, base-level understanding of many topics
- Ability to clarify ambiguous problem statements
- Understand tradeoffs between choices and managed to make decisions using data or “sense”
- Some thoughts on user experience
More hints
- Listen to the hints/feedback interviewer gives and integrate them into the design. Try to act like you were working with a coworker rather than interviewing.
- If you are interviewing for a senior role, it's expected that you will drive the discussion most of the time.
- If you're stuck, ask your interviewer for help. Don't waste valuable interview time waiting for them to interrupt you.
- Use a generic name instead of using a specific technology unless you are familiar with it. For example, use a message queue rather than Kafka to avoid questions like why Kafka instead of RabbitMQ?
- It’s important to check if you are on the right track during the interview but checking too often (every decision) will be perceived as a “junior” candidate
Preparation
Passive Learning Mode: Preparation
You might find a lot of resources on the internet but here, we want to keep it small so we could help you begin your preparations while not getting overloaded with too many resources that you will never complete.
Pareto Principle (the 80/20 Rule) states that for many outcomes, roughly 80% of consequences come from 20% of causes. This is applicable to system design topics as well. 80% percent of system design interviews involve only 20% of the concepts:
- APIs
- Databases (SQL vs NoSQL)
- Scaling
- Caching
- Indexing
- Message queues
- CAP theorem
- Web authentication and basic security
- Load balancers
- Replication
- Consistent hashing
- Failovers
These are the resources we recommend:
- https://github.com/donnemartin/system-design-primer
- System Design Interview – An insider's guide
- Designing Data-Intensive Applications - Martin Kleppman
Active Learning Mode: Practice
Reading articles and watching videos help, but those are passive learning. At the end of the day, we believe system design requires you to be an active learner.
You can choose to practice with friends or use a platform like Pramp. Or, us?
Time Allocation Framework
A good enough framework for 60 minutes allocation looks like this:
- 10 + 15 + 25 minutes
- The 10 minutes left are buffers for introduction, minor technical problems, and Q&A which usually doesn’t affect your score
10 minutes: Clarification of the requirements
Different companies want different things. So you have to clarify unless they give you very detailed instructions. Some popular clarifying questions/assumptions include:
- Could we just focus on the backend?
- Are there any non-functional requirements?
- Does it make sense to assume we will have more reads than writes?
- Is it ok to use a 3rd party service for our payment gateway?
- Do we need to support multiple languages?
For assumptions, confirm with your interviewers because not every company wants a number. Unless you are asked to, skip the assumption step to save time for other steps.
15 minutes: High-level design
The goal of this step is to provide a big picture to show that we fulfill the functional requirements. At the end of this step, both you and your interviewer should have a general idea of how the data flow from request to response. Some common things you could talk about are:
- An illustration of your simplest architecture (could be client -> server -> database in some cases)
- System interface
- API (HTTP method, what your endpoint does)
- Databases
- what kind of data do we want to store
- what kind of databases and why (Relational, Key-Value, Graph, Search…
- schema
- (if you do estimation) figure out how much disk space we need and see if that makes sense
- For instance, storing TB-sized data in a single relational database instance doesn’t make sense (ref: Amazon RDS instance types)
To save time, skip talking about optimization, scaling, etc. So no load balancers, and no replicas at this point.
25 minutes: Detailed components, optimization, and all the goodness
This is where you want to spend most of your time because:
- Compared to high-level design, which might look similar across different titles (think TikTok vs youtube), interviewers are most interested in how deep could you go for the current title
- A place to show off how knowledgeable you are
Always confirm with your interviewers which components are they more interested in. This is the step you want to mention:
- How to scale your read and write
- Add more logic to help your system grows:
- compression
- an algorithm like splitting files into chunks etc
- Add more components/logic to help your system grow. For instance, message queue, CDN, etc.
Buffers
If you have more questions than the time allowed, it’s ok to ask your interviewers to stay for a few minutes.