8 Steps to acing your next system design interview

System design can be a huge leap forward in your career both in terms of money and satisfaction you get from your job. But if your previous job was focused on working closely on one of the components of a system, it can be hard to switch to high-level thinking

Imagine switching from roofing to architectural design. Instead of knowing the ins and outs of making one component, you need to develop a system of components that work well together. This is why so many people fail in system design interviews. They don’t understand what the interviewer wants to hear from them.

What are interviewers looking for?

You walk into an interview, ready to discuss the pros and cons of using NoSQL, fine details of implementing map-reduce, and the possibilities of using the newest node library. What do they ask you? Design Netflix from scratch.

This leaves many interviewees puzzled, and they do two crucial mistakes. The first mistake is focusing too much on the service that already exists. The interviewer doesn’t want to know how Netflix or Twitter is actually made. Rather, they want to see your thought process that goes into creating a similar system.

The second mistake is focusing too much on details. That’s not what you need to do, at least not at first. The technical knowledge and the ability to solve bottlenecks is great, but your main goal for such interviews should be understanding the  type of system you need to develop and figuring out the optimal way of solving user problems.

How to ace a system design interview: A step by step guide

Now that you know the direction, let’s go through the interview, step by step.

Step 0: Get good

Preparing for the interview starts months before you arrive at the office. You need to work on gaining knowledge and acquiring skills to be sure that you have what it takes to crack it.

This includes a lot of reading. Start with following high scalability and getting yourself a copy of Martin Klepmann’s Designing Data-Intensive Applications. It’s a great place to start if you have limited experience with system designs.

If you have the knowledge but struggle to apply it to real-world problems, try hosting brainstorming sessions with your pals. After all, trying to design Twitter from scratch can be fun when your employment doesn’t rely on it.

You can go even further and attend a hackathon to try implementing your system design knowledge in practice and get expert advice on it. When you feel confident about your skills, start polishing them before the interview. For instance, you can focus your practice on the typical cases interviewers offer.

In most cases, the interviewer will ask you to design one of the following services:

• URL shortener
• Social network
• Messenger
• Video streaming
• File storage
• Search engine

If you know a bit about each of these services, you’re already on the right track. To gain even more confidence before the actual  interview, attend a mock one. You can do it online, and instead of “we’ll call you back”, you’ll receive an expert opinion on your performance.

Step 1: Define the key assumptions about the system

Now, let’s say you’ve made it to the interview. Given the number of applications big tech companies receive, it’s already an achievement. You feel good about yourself, and when the interviewer asks you to develop something like Facebook, you start talking about peculiarities of data storage and what is the best way to create a dynamic feed.

That’s not what they expect to hear. First, you need to understand what kind of system are you building. What is the intended audience? What problems are they solving with this service? You’ll need to answer those questions before you can go any further.

In many cases, the interviewer won’t know the answer. Why? Here’s a very important thing about system design interviews: it’s not about giving the correct answer to a well-defined problem, but it’s about your ability to define the open-ended problem and solve it creatively.

This means you can pretty much decide on these key assumptions together with the interviewer.

Step 2: Define the key features

Once that is out of the way, your next step is defining what kind of features your hypothetical service must possess. Even though your task is designing an already existing service from scratch, it doesn’t mean they should be identical.

For instance, if you’re tasked with designing Facebook, you can take the features this social media has as the basis and work from that. Think of ways you can combine Messenger and Facebook into one app instead of two or suggest how to make ads more user-friendly.

If you’re tasked with developing a Discord-like chat, you’ll need to include secure chat rooms with stable voice chat features. You can also suggest a streaming option. If you need to develop a digital product marketplace such as Pro Essay Writer, you’ll need to combine features like dynamic display of offers, secure access to database, and several payment options. You can throw in a Ai live chat or a monitoring feature to make sure the freelancer the user has hired is busy working on the project.

This will show the interviewers that you’re not only capable of reverse-engineering a service, but actually thinking about the problems customers face and solving them.

Step 3: Define the scale

While the system you design should be scalable, you need to start somewhere. This is why you need to define the scale of the system at first. Think about the read-to-write ratio, the number of concurrent requests the system should expect, and various data limitations.

Once you define these parameters  together with your interviewer, you can think of the best way to make that system work well and be scalable. But before that, there’s one more step.

Step 4: Define the data model

Before you can design the hypothetical system, you need to define how you’re going to process data. Find out the main inputs and outputs, how they’re going to be stored, and how the data will flow.

This doesn’t require you to know every little aspect of implementing MongoDB or the latest MySQL library. If you know what database would serve the purpose better, it’s going to be enough. Remember, you don’t need to go into detail too much at this stage.

Step 5: Design the high-level system

By this time, you should have all the information necessary to design the system your interviewer wants. Ideally, you should be no more than 15-20 minutes into the interview.

Start with the entry-points and work your way up to the database. If the interview room has a whiteboard, it’s a great opportunity to visualize your ideas, but even a sheet of paper will do. Draw the architecture that’s needed to support all user and API interactions and present a decent response time.

Don’t be afraid to change the layout of the system on the go. Interviewers don’t care about you making mistakes. They want to see if you’re able to iterate your ideas and improve as you go along.

Step 6: Look for bottlenecks

Once your version of the system seems more or less final, you can get down to details. Look for possible bottlenecks that can slow down or hinder the functions of the system. It’s also okay to take the interviewer’s advice on this. In many cases, the interviewer is an expert on the topic, so you’ll only show your readiness to learn and improve by this.

Find out the bottlenecks and come up with ways of eliminating them either by redesigning a part of the system, or scaling up the hardware.

Step 7: Go in-depth on the subsystem you know well

This is an optional step, but many interviewers ask you to go through this as well. You’ll have to go low-level and elaborate on a subsystem. If you can, steer the conversation to the one you know best.

There’s no shame in admitting you don’t know much about a certain subsystem. After all, you’re no Renaissance man, and the company you’re applying to has teams of experts working on each subsystem, so you’ll have plenty of opportunities to consult with them.

Show off the knowledge you have, and move to the next step.

Step 8: Acknowledge the trade-offs

No system is ideal, and a good system design engineer knows that well. Let the interviewer understand what trade-offs did you make to let the system work well at this stage.

Stay in touch

With that, your 45-minute interview should be over, and the interviewer would be either impressed or bored with your take on the problem. Regardless, you should try to stay in touch with them to increase your chances of getting hired. At the very least, you may get an expert opinion on what went wrong.

If you’ve failed the interview, don’t stop in your tracks. It’s just an opportunity to learn more and practice more. Join Hackathons and do mock interviews to up your skills, and you’ll get the job you’ve been dreaming about.