#23 Preparing for Tech Interviews, Part 2: System Design
Four things to do to prepare for system design interviews
Welcome to Part 2 of Preparing for Tech Interviews series, where I share insights and advice gathered from software engineers working at high-growth startups and big tech companies like FAANG.
Preparation Recap:
Note: companies might have specific requirements/responsibilities for their roles. Make sure to contextualise these estimates based on the role you’re applying for.
System Design
System design interviews can be one of the most intimidating rounds for engineers. However, with the right preparation and practice they can become the easiest to crack. A system design interview is a design activity that allows engineers to demonstrate their knowledge and expertise in building systems, break down a large system into a functional MVP, and discuss requirements and trade-offs with other engineers (interviewers).
System Design is not a Q&A interview, it is a collaborative design session, and you’re the one leading it.
So, here are four key things to do to prepare for system design interviews:
Refresh on the fundamentals
Learn to scope
Start high-level, end with deep dives
Do mock interviews
1. Refresh on the fundamentals
One of the strong signals interviewers look for in a candidate isn’t just familiarity with technologies but a deep understanding of the core fundamentals that guide their technology choices. A strong candidate can design a system without being locked into a particular tech stack. And if they do choose a stack, they can justify its pros and cons. When doing the interview, be careful about throwing out a lot of technology names without logical reasoning.
Here are two good/bad examples of designing a solution:
❌ I’ll use a MongoDB because it’s “fast” and “easy to scale”.
✅ Given the data locality imposed by the system, I’ll use a NoSQL database.❌ Scaling Database? We can do data sharding using AWS’ RDS (Aurora Limitless).
✅ Depending on the read/write ratio, if query performance is already optimised with indexing, we can introduce a leader-follower cluster, creating read replicas for read-heavy paths and a single master for write-heavy paths.
So what are the fundamentals?
Imagine there are three foundational layers beneath Technologies, representing the Fundamentals. These are:
Core Concepts
Protocols / Interfaces
Patterns / Techniques
The boundaries don’t matter; they highlight topics in specific areas like networking, protocols, data formats, and communication patterns. Technologies are solution offerings from different companies (e.g., cloud providers like AWS, Azure, and GCP) that solve a fundamental problem using a specific technology.
That’s why when candidates say they’ll use an object storage in their design—an S3 bucket or GCP bucket—I don’t care which technology they pick. I care that they pick the right solution for the problem (an object storage).
Interviewers look for signals of your knowledge depth beyond Technologies, so deepen your understanding of the Fundamentals to confidently explain any layer of the stack during the interview. They also help you make better decisions during the system design interview. Focus on the problem, not the technologies.
🌟 Tip: Technologies change over time. Fundamentals stay the same.
Here are two examples of topics around Technologies/Fundamentals:
Take the time to refresh on the fundamentals and deepen your expertise in a specific area that interests you. That could be working with databases, networking, security, etc.
🌟 Tip: Interviewers look for breadth and depth in the design, make it easy for them to see that.
2. Learn to scope
This one is similar to task-based interviews, covered in the Coding post:
Learning how to scope (i.e. gather requirements) is critical in a system design interview. When asked to design a system, you need to think about:
Functional requirements (FR): Core features/functionalities of the system.
Non-functional requirements (NFR): Attributes of the system.
For example, designing a system like Uber will have something like:
FR: Users can request rides to a specific location.
NFR: Real-time data (Uber should support live tracking)
🌟 Tip: NFRs usually end with -ility (e.g., Scalability, Availability, Reliability). However, only mention those that are important and relevant for your system. Don’t list them out without purpose.
Practice taking ambiguous systems and gathering requirements for each one. You’ll find lots of examples in the study resources down below.
3. Start high-level, end with deep dives
Once you’ve gathered the requirements for a system, start designing an end-to-end working solution (sharing your thought process) at a high level, and then dive deep into 1-3 technical components at the end.
Your approach should be to:
Satisfy the FRs via high-level.
Satisfy the NFRs via deep dives.
To illustrate, here are two examples of how to approach a system design interview question.
Example #1 - Spotify
Design Spotify: a music streaming platform where users can search for songs, play music, and create playlists.
Step 1: Scope the system
Step 2: Design a high-level solution
Step 3: Go through 1-2 deep dives:
Search Service: How to build a search engine for songs, artists, and albums.
Play Service: How to handle traffic spikes for song streaming.
Play Service: How to handle traffic spikes for top-10 hits.
Play Service: How to handle buffering and adjust quality based on network conditions.
Playlists Service: How to sync users’ playlists in real time across different devices.
Interview #2 - Design YouTube
Design YouTube: a video streaming platform where users can upload, search, and watch videos.
Step 1: Scope the system
Step 2: Design a high-level solution
Step 3: Go through 1-2 deep dives:
Watch Service – How to handle users with low internet connections to ensure smooth video streaming.
Watch Service – How to handle traffic spikes during peak usage times.
Video Processor – How to handle corrupted videos and generate different qualities.
4. Do mock interviews
Mock interviews are a great way to practice system design interviews and get feedback from others. That can be a friend, mentor, colleague, etc.
Benefits of doing mock interviews is that they help you understand:
Your approach to gathering requirements
How you communicate ideas to engineers
Where you get stuck on the technical components
How you handle “Bar raiser” questions or direction shifts
If mock interviews aren’t an option, try to set aside 45 minutes of deep focus time to work through an interview question on your own. You can record yourself if you want to simulate an actual interview with you speaking.
And these are the four things to do to prepare for system design interviews
📖 Study Resources
If you’re in a hurry, read System Design intro by HelloInterview
Highly recommend System Design Interviews by Alex Xu and Sahn Lam
Designing Data-Intensive Application, excellent resource for distributed systems.
Checkout Hello Interviews Playlists on YouTube, phenomenal walkthroughs by Evan King and Stefan Mai.
Fundamentals of Software Architecture, a great intro to architectural thinking.
⭐️ Final tip: You only learn if you try. So don’t consume all these resources without actively practicing.
Wrap up
Take a vague system design problem, narrow it down to a set of functional (FR) and non-functional (NFR) requirements, design the solution end-to-end on a high-level, and end with 1-2 deep dives. If you find any knowledge gaps during interview practice, take notes of the topics/areas and study them.
There’s no secret formula for “mastering” system design interviews. A system design interview can go in a million direction. The more you prepare, the more confident you’ll become in tackling ambiguous problems. So, practice, practice, practice.
To recap:
Refresh on the fundamentals
Learn to scope
Start high-level, end with deep dives
Do mock interviews
If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.