The Do’s and Don’ts of the System Design Interview

Use the interview to show how requirements lead to a design. This lesson covers the questions to ask, the data to characterize, and the tradeoffs to explain before committing to components.

What to do during the interview

Start from the problem you were given. A familiar architecture can be useful, but explain why its components fit these requirements and where you would change it. Novelty alone does not justify a design.

Since interviews can be stressful, having a structured plan is a valuable strategy. While there are many ways to approach a System Design problem, we recommend the following technique.

Strategize, then divide and conquer

We recommend including the following activities somewhere in the interview:

Ask refining questions

Ask questions that change the design: which users matter, which actions they need, and which constraints are mandatory. Prioritize a few features with the interviewer, then use those answers to explain the scope of your solution.

We need to ensure we are solving the right problem. It is helpful to divide requirements into two groups:

• Functional requirements: Features the clients need directly, such as sending messages to friends in near real-time.

• Non-functional requirements: Qualities and constraints on those features, such as a latency target at an agreed user load. State the target and the load together so the requirement can guide a design decision.

Handle data

Describe the data before choosing storage or processing components. Its size, access patterns, consistency needs, and retention requirements determine which options are worth comparing.

Some important questions to ask ourselves when searching for the right systems and components include the following:

• What’s the size of the data right now?

• At what rate is the data expected to grow over time?

• How will the data be consumed by other subsystems or end users?

• Is the data read-heavy or write-heavy?

• Do we need strict consistency of data, or will eventual consistency work?

• What’s the durability target of the data?

• What privacy and regulatory requirements do we require for storing or transmitting user data?

Discuss the components

At a high level, our job involves selecting components, determining their placement, and defining their interactions.

For instance, we must decide on the appropriate database type, such as choosing between a conventional SQL database or a NoSQL alternative.

Suppose you recommend a NoSQL database and the interviewer asks you to use a relational database. First clarify whether this is a fixed constraint or an invitation to compare alternatives. Then adapt the design: explain how the required queries and updates would work, and identify any cost or scaling tradeoff. Repeating the original recommendation does not answer the new constraint.

Note: We often abstract component details into boxes and use arrows to illustrate interactions. Defining high-level user-facing APIs can further clarify system data and interaction requirements.

Common System Design components include front-end interfaces, load balancers, caches, databases, firewalls, and CDNs.

Discuss trade-offs

Remember that there’s no one correct answer to a design problem. If we give the same problem to two different groups, they might come up with different designs.

Here are the primary reasons for diversity in System Design solutions:

• Trade-offs: Components have distinct advantages and disadvantages. We must carefully weigh which options best suit our needs.

• Resource management: Compare financial cost, operating effort, and technical complexity against the requirements.

• Weaknesses: Every design has limitations. We must identify these flaws and have a plan to address them.

We should proactively highlight design weaknesses to the interviewer and explain our reasoning. For example, our current design might not handle a tenfold increase in load, but we do not anticipate reaching that scale soon. By implementing a monitoring system to track growth, we can upgrade the design when necessary. This demonstrates an intentional trade-off to reduce immediate system costs.

Failures are inevitable in large systems. Therefore, we must integrate fault tolerance and security directly into our design.

What not to do in an interview

Here are a few things that we should avoid doing in a System Design interview:

• Keep code secondary to the design unless an implementation detail or interviewer request makes it useful.

• Agree on the problem and scope before drawing components.

• Explain decisions as you make them, leaving room for questions.

• Give estimates units, assumptions, and a reason they matter to the design.

• State what you do not know and explain how you would resolve it.

Note: If an interviewer asks us to design a system we haven’t heard of, we should just be honest and tell them so. The interviewer will either explain it to us or they might change the question.

Use this sequence as a guide, then respond to what the interviewer says. A clarifying question only helps if its answer affects the design. When a constraint changes, revisit the relevant decision rather than defending the original diagram.

In your next practice session, pause after the high-level design and name one assumption that would force a revision. Explain what you would change and what evidence would justify it. The next lesson examines this kind of adaptation under interview pressure.