How to Prepare for a System Design Interview — and Pass It

Tala brings his 10+ years of software engineering experience to Formation as a mentor. Formation is a career accelerator founded by former Meta and Nextdoor software engineers who have one goal: to help engineers from all backgrounds land life-changing roles.

As a software engineer in the real world, you’ll often get vague questions like, “Can we add a chat feature on the website?” or “Would we be able to put a ‘like’ button here?” These questions will come from everyone— a product manager, the marketing team, and even the CEO. In these scenarios, you wouldn’t just say yes and start building; you would ask questions to learn more about what is needed and wanted. You’d also want to ask about specific requirements so that you can best answer the question and, eventually, build something that lasts.

The questions you’d ask in the real world are the same ones you should be asking in a system design interview. In my 10 years of experience in software engineering at companies like Reddit, Instagram, and Facebook, I’ve been on both sides of the interview. As a Mentor at Formation, I help Fellows navigate the system design interview process. Here’s what I tell Fellows, and would tell all engineers, who reach this point in the hiring process.

What is the purpose of a system design interview?

To start things off, let’s cover the basics. What’s the point of a system design interview, anyway? Well, at its highest level, here’s an outline of what your interview should convey to an interviewer:

1. Given an ambiguous problem, can you create concrete technical requirements? It takes some experience to understand that system design interview questions are ambiguous, but that’s one of the challenges.
2. Given these technical requirements, can you give a high level description of how to implement each specific requirement? Descriptions come in the form of text, diagrams, voice over, etc.
3. Can you defend your design and explain why it’s built to last? Can you create on cohesive system that feels cohesive, durable, fits into the existing flow, and is scalable?

How to Prepare for a System Design Interview

The goal of the interview, to put it simply, is to explain your ideas clearly and document them. I’ve found that many engineers psych themselves out before a system design interview. When I was prepping, I thought I needed someone to interview me to kind of gauge how well I did. As a mentor, I’ve learned that practicing software design on your own prepares you better than doing a bunch of mock interviews. There are a few pieces of advice I give Fellows when they’re preparing for a system design interview.

1. Start by designing common apps you use

It’s really tempting to learn system design by just reading articles and blog posts on how an app works, but it’s likely that the information will go in one ear out the other. Instead, read it, close it, and try designing it yourself. If you can, try building some of your design and see how well it holds up!

Open your phone, find an app you like to use, and start designing it. You can practice this entirely on your own since there are plenty of tools out there you can use to start building. Building apps on your own lowers the barrier and allows you to practice at any time without another person there to interview you. Keep in mind that as you’re practicing, you should be able to explain, document, and diagram your work. Reading and learning is an active process and, as an engineer, you have the benefit of being able to build something as a way of learning.

2. Practice makes perfect

Get familiar with common diagramming tools such as Lucidcharts, draw.io, and Excalidraw. Every tool has a few weird, sharp edges so familiarize yourself with them as much as possible. It can be very different to type your thoughts out on a computer versus a whiteboard or paper, so practice as much as you can until you’re super comfortable doing so. Practicing getting your thoughts down on a digital canvas makes it so you’re not figuring out how to do that in the middle of the interview.

3. Time-box yourself

It’s very easy to not practice for system design interviews because you think you need another person to interview you. In reality, physically putting in the effort of practicing the interview is the most valuable thing you can do to prepare. I recommend doing so while time-boxing yourself to 30 minutes or 45 minutes. Document everything as you would during an interview. When your time is up, send your documentation to someone for feedback. Does this document adequately describe the problem you were trying to solve, your approach toward solving it, and decisions you made along the way? Is this something they’d be able to implement? Their feedback will help you improve and adjust your design.

How to manage your time during the interview

Perhaps the most important soft skill in a system design interview is time management. It’s also the biggest non-technical skill gap I see when interviewing candidates or hosting mock interviews. Be aware of the clock. Knowing what you can get through with the flow you want in the time you have left is crucial.

You may have less time than you think: in a system design interview that is 45 minutes long, you’ll spend about 5 of those minutes with interviewer chatting in the beginning, and 5 minutes asking questions to the interviewer at the end. That only leaves roughly 35 minutes for actually going through the interview, and even less time once you account for listening to and understanding the prompt!

You can observe a similar pattern in coding interviews: in a 45-minute, 2-question coding interview, doing the math above gives roughly 17.5 minutes for each question. Assuming you spend 90 seconds to understand each question, this only leaves 16 minutes to code up each solution.

If you manage your time well in the interview, you’ll be less likely to go down unproductive rabbit holes, and you’ll be better at asking the interviewer questions to unblock yourself. This will, in turn, improve your interview performance. I’ve seen many engineers do poorly on interviews because, for one reason or another, they lost track of time, and before we knew it our interview had come to an end. Staying on time and pacing yourself to complete the interview is a good signal of a strong hire.

Top 3 skills that will help you pass a system design interview

When I interview candidates or host mock system design interviews for Fellows, there are three important skills I’m looking out for. Here are the top three skills and a bit of context as to why each one is important to convey to your interviewer if you want to pass.

1. Gathering requirements: Perhaps most importantly, I’m looking to see how well you gather requirements before building anything. Lots of junior engineers will come into a system design interview where we’re asking about YouTube’s design and they’ll write out all the features of YouTube. That’s great, but it’s not the point of the interview. The most important part of requirements gathering is staying inquisitive and really working to understand what is completely necessary and what is nice-to-have
2. Communicating your thought process: Imagine you’re giving a presentation on something and you’re drawing it all out on a whiteboard. Then, you leave the room. Ideally, you have communicated your thought process so well that someone who walks in the door and reads it on the whiteboard can understand it down to the nitty gritty details. You should treat a system design interview the same way; your design documentation should be so good that someone who wasn’t in the interview can look at it and build your design as you intended it.
   
   Ultimately, the output of your interview should be a design document. Do your best to document all of your thoughts and your approach. The goal of the interview is for someone who wasn’t in the interview to understand your approach, tradeoffs, solutions, core flow, and make it super clear how the system would be designed. The key points should be understandable by everyone—all the way down to a new grad.
   
3. Translating requirements to implementation details: I want to see how you think about actually designing the app, taking into consideration all of its necessary requirements. Think about your approach to system design like a jpeg image in the 1990s would have loaded: the image is super blurry at first, but then you start to see some pieces of it come into focus until, eventually, you can see the image as a whole. Like this jpeg image, your approach to system design should be to zone in on certain parts until the parts come together as a whole.
   
   Additionally, interviewers want to see how you talk about the data and where it’s going to go inside of your services and your systems. They also want to know that you know the user. Based on your questions when you were gathering requirements, you should at least know the answer to the questions “who is this for?” and “how will they be using it?” when you translate it into implementation details.

Preparing for a system design interview doesn’t have to require hundreds of mock interviews. In fact, most of your prep can be done by yourself. If you can take a screenshot of something you’ve designed, look at it a week later, and understand what you need to do to build the system, then you’ve succeeded.

Looking for more interview prep tips? Check out our resources here or apply today to get hands-on training of how to pass technical interviews during our Fellowship!