Five Tips for Systems Design Interviews

Most engineers do not know how to take control of and do their best in a system design interview question. This article will outline how you should approach an interview question and some tips to create an excellent impression.

STEP 1. Ask clarifying questions before jumping in

Your job is to get a sense of the type of answer the interviewer wants, and this is largely predicated on the type of company you’re interviewing for. 

There are essentially two main types of companies (not binary but more like a spectrum). The first category is huge companies. They build things on a massive scale from the beginning, even if the project is long and expensive. Then the second category is lean startup companies. They build things cheaply and quickly but still in a way that they will be able to expand upon. 

For instance, let's say that your prompt for your design interview question is the following:

Build a CRUD API meant to deliver information about people, and it has thirty different data points about each person. It provides demographic data, education, income, career information, etc. 

If you are interviewing at a huge company, they _might_ want you to think about a massive-scale system immediately, including async data ingestion, multiple data stores (one for searching and one for long lived storage), etc.

On the other hand, if they give you the system design question in a standard company, they probably want to hear you mention a database, an app server, a cache layer, and the contracts between these pieces. Then, a more traditional company will probably ask you about scale since they typically look for simplicity first.

In my experience, if you start off with a simple MVP approach, you get it right about 90% of the time. In order to better inform where to take the conversation, though, you will have to ask clarifying questions to understand the system's complexity and non-functional requirements (SLA for data availability, disaster recovery RPO/RTO, availability of APIs, latency, traffic numbers, spikyness of traffic, etc.).

Sometimes the assumptions are buried in the problem prompt. For instance, you might ask something like: 

"Based on this prompt, it seems like this information will be changing very infrequently, and the system is mostly for reads - it’s a very read-heavy system. Is that a fair assumption?"

STEP 2. Present a quick cohesive high-level vision of the system immediately. 

It should not take more than three sentences to present all the components that the system needs. For example, you should say: 

"I will have the data in MongoDB because that is the technology I know best. I think there are no major drawbacks for this use case. Then, I will have a Python Flask app server, a Redis layer, and a React app for my front end." 

Start with a high-level overview of the system. Your interviewer knows this is not the only viable solution at this stage. Do not ramble on about the different choices that would work; present one vision of the system and then move on to details. 

STEP 3. Describe the contracts between the components of the system. 

Present the contracts between the database and the API layer, and the contract between the API layer and the front end. If there is a caching layer between, discuss that. Let's go back to the example with the demographic data, and let’s say we are going with a MongoDB database and a single collection. So because a single collection is typically faster to query, and since it is read-heavy, we could use denormalized data. Each document in the collection would have all the person’s data. This is just an example; the point is you have to explain your data schema and the reasoning behind it. 

Don’t be dogmatic. Avoid sweeping generalizations such as “NoSQL is better for scaling.” 

Afterward, talk about how your API layer will connect to the database. You might mention a library like Mongoose or NodeJS; the important thing here is to convey the message of “I’ve done this before.” Talk about what your API expects to receive in terms of inputs. Once you are at this point, you could ask clarifying questions about which parameters you need to be able to allow searching on. Give an example of the type of API call your API would expect. For example: "I want to GET requests with query parameters, and if they are looking for a person with social security number XYZ, it would be mypersonsapi.com/api?SSN=XYZ." 

Make sure they understand the vision you are presenting. You want to be specific about how the different components of the system connect. If you want to mention a particular library, go ahead, as this conveys experience. But the platform-agnostic contracts between components, such as the shape of a request and the shape of a database schema, should be explicitly stated.

STEP 4. Take control of the conversation. 

After you’ve presented a broad vision, steer the conversation to what you are most familiar with. That is when you have the opportunity to discuss trade-offs at more length. Once you present the contracts between the system's main components, you can steer the conversation to the things you have more expertise in order to highlight them and showcase your strengths. 

If you are a product-focused engineer, then spend a lot of time discussing usability trade-offs in the front end. If you are a database guru, then spend a lot of time discussing the various indexing strategies you may use in your database, discuss the elastic search, and where you would or would not use it.

Do not change products in the middle of your answer. Don’t spend 5 minutes discussing what you would do with a SQL DB and then change to MongoDB. This is a waste of time, and it prevents you from getting deeper into the discussion and showcasing real strength.

If you feel good about your scaling knowledge, discuss what infrastructure you would select and why. Give details about how you would set everything up and get everything to work.

Steer the conversation towards your strengths.

STEP 5. Pay attention to your interviewer. 

There are three main unspoken hints interviewers will give you. The first hint, they might insist on a follow-up topic. So if they do this, there is a problem with your design. Pause, and try to figure out what the problem is. 

Another hint they might give you is changing the topic abruptly, which typically means you completely bombed the last question. If you detect this, pause for a second, try regroup, and maybe it is worth taking control of the conversation and returning to that topic. If you can figure out why the interviewer thinks your answer is not up to their standards, then go back to that topic and try to justify yourself. 

The third unspoken hint an interviewer might give you is a little different. If an interviewer asks you a crazy trivia question like "which specific systems calls might the C function malloc make?" If you were talking about memory management before, and they start getting down to a level of specific system calls, this usually means that the interviewer is relatively an expert in that area, they have detected you might also be, and they are looking for the depth of your knowledge. This is a great sign.

Summary

In order to do well at the systems design interview, you should adapt your responses to the type of company and follow these five practices:

1. Ask clarifying questions. 

2. Present a high-level vision of the system.

3. Talk about contracts between the different components of the system. 

4. Steer the conversation towards your strengths. 

5. Pay attention to the unspoken hints from your interviewer. 

By practicing these tips, you can boost your interview success rate.