The top 6 system design interview mistakes to avoid

What is the interviewer looking for?#

First, let’s talk about what interviewers want to know about you. When interviewers give you a system design question, they’re not just looking for a working solution and good communication skills.

Interviewers also want to answer the following questions: How many different solutions can this person come up with in a methodical way? Can this person do a pros-and-cons analysis of different approaches? What is the depth of their answers? Is this person thinking about the system’s lifetime and how it will evolve as more users and data come in? Can this person explain different scenarios end-to-end with concrete examples?

It’s important to note that not every interviewer will gauge your strengths using the questions above! Think of these questions as general guidelines for contextualizing answers as you practice solving system design questions. You want your interviewer to be able to have a definite answer to these questions whenever possible.

Now, let’s move on to some common red flags that interviewers see during system design interviews!

1. Failing to understand functional and non-functional requirements#

Finding out the functional and non-functional requirements of a system is one of the first things you should clarify with your interviewer.

• Functional requirements encompass the basic functions offered by a system and are essential for creating a final product that meets the expectations of your end-users. These requirements are necessary for your system to function.
• Non-functional requirements focus on performance expectations and how well your final product lives up to the expected standards. These requirements are not essential for your system to function.

System design interview questions are often intentionally vague, and it’s your responsibility to uncover the information needed to execute your design. When candidates jump into designing a solution without asking enough clarifying questions, they can make assumptions about how a system should function and perform.

If your interviewer doesn’t offer enough information, feel free to ask, “What are the functional and non-functional requirements of the system we are designing?”

Take the time to find out exactly what components your system needs to include and its expected performance.

2. Not identifying faults, points of failure, and solutions#

There should probably be an award for the first person to design a system that never fails. Virtually all systems have bottlenecks, and all system designs are capable of having some kind of fault or vulnerability that can lead to total system failure.

Alright, “total system” failure might be a touch dramatic, but it’s meant to underscore the importance of knowing your system’s weaknesses. As a system designer, you must be able to figure out a solution to non-transient, permanent issues, or the system will fail on you.

Being aware of these faults means you can plan ahead with fail-safe measures for getting systems back online at 100% availability. Be sure to provide a solution (or multiple solutions) for points of failure to show your interviewer that you are considering the design from every possible angle.

Considering faults and points of failure can open up the discussion of whether or not capacity will become an issue down the road. If you find that your system design could fail under intense loads, then ask your interviewer what the intended load for this system is before thinking of ways to make your system more scalable.

Note: Some of the biggest (and most common) system vulnerabilities to look for are related to processing and user input data (e.g., security loopholes, SQL injection).

3. Failing to consider the tradeoffs for different solutions#

There are countless possible solutions you could provide for a system design interview question, and chances are you won’t be able to consider the tradeoffs for all of them. However, you don’t want to make the mistake of not considering any tradeoffs.

Every system design has strengths and weaknesses. Be sure to consider the scalability, availability, maintainability, and reliability of different solutions.

4. Under-communication or over-communication#

During the interview, your interviewer will assess your ability to communicate with others. How well can you work in a team? If you stay silent the entire time without asking questions or seeking feedback from your interviewer, it could give the impression that you are uncooperative or independent to a fault. At the other end of the spectrum, you risk dominating the conversation or over-communicating with irrelevant information.

Both of these issues can be improved through practice. When you practice solving system design problems, try walking yourself or someone else through your solution. Do you give them enough time to ask questions? Are your explanations clear and concise?

Finally, make sure that you have been able to accomplish the following: Define the problem Identify all constraints Identify the features needed to design the system Identify the most critical components to prioritize

Communication is an art form, and not one that is easily mastered!

5. No justification for design decisions#

Take the time to articulate the thought process behind your choices carefully.

You need to be able to explain why you made a design decision, full stop. Being unable to justify a design decision is one of the more severe mistakes that can be made during a system design interview because it can leave the impression that you don’t know what you’re doing.

Remember, one of a system design interviewer’s main goals is to discover your thought process and understand how you make your decisions. They will ask you questions about why you went with one technology over another or other aspects of your system. They want to know what you think is the most appropriate solution to a given problem and why.

For this reason, it’s imperative to familiarize yourself with as many different technologies and system design patterns as possible. One way to get comfortable talking about these technologies and designs is to explain them to a non-technical person in a way that makes sense.

6. Skipping the high-level design#

Jumping straight into the details is one mistake that can lead to down-leveling. Down-leveling occurs when you apply for a job at a certain level but fail to meet the expectations for the level you’re applying to. So, for instance, if you were to apply for a senior SWE position but gave mid-level SWE interview answers, they might offer you a position at that level instead.

So, be sure to talk through your high-level system design details first. It’s important to ensure you aren’t jumping straight into the low-level aspects of your system design at the beginning of your interview.

• High-level design (HLD) involves translating your client’s needs into a solution that encompasses the overall design of your system, software architecture, databases, platforms, services, components, and modules. At this level, you are thinking about the relationship between different parts of your system.
• Low-level design (LLD) focuses on the components of your design solution and typically includes detailed descriptions of each component, how the functional logic of different modules work, and other specifications for meeting the needs of your client or business.

Note: Experienced system designers will not only focus on the different software components and how they interact with each other but on the entire lifetime of a system and how it evolves. They will think about ways to make systems more efficient, resilient, and scalable.