Tips for leading a system design interview

Fair warning, this is a long one. Brew a pot of coffee (or tea!) and read on.

The purpose of a system design interview is to gauge whether the candidate can identify and refine what needs to be built. This can help understand the candidate’s level of experience with designing non-trivial scalable systems.

In general, a system design interview should follow certain steps, but the order of some steps can change.

Suggested steps

1. Gathering requirements

• Functional: what does this system need to do?
• Non-functional: talk about the numbers, RPS, number of users, etc.

2. Define API

• What do we need to provide for each feature of the functional requirements?
• What will the endpoints, request body, and HTTP methods look like? What API format are we using? (SOAP, REST, GraphQL, gRPC)
• Inputs and outputs
• Pagination

Frontend focus: How does the frontend fetch data? How do we ensure it doesn’t over-fetch or under-fetch? How do we manage state to keep a pleasant UX? How should we respond when the backend throws an error?

3. High level diagrams

• Initial diagram: keep it small and quick to make
• Don’t let the candidate worry about using the right icon for RDS vs Aurora; use a blank box with a name instead
• Walk through the system end to end to verify it actually works; this makes the deep dive much easier

4. Data model and schema

• Table schema
• What entities do we need?
• Relationships between these entities?

Frontend focus: How can we break our frontends down into appropriately sized components? Are there shared components within a page or within a component? What behaviour do these components have?

5. Deep dive on the design

• Scale this out

It’s important that:

The candidate asks questions to clarify the requirements

• As interviewer, if they do not ask, you can ponder the questions yourself or give away some numbers:
  • “How many requests per second are we getting in this case?” or “We are going to be getting roughly 1k RPS by the way”

There is a system that is designed in the end that applies well to the problem

• If the system is so generic that it could be swapped out, maybe a more unique question should be chosen in the future, or the candidate should define the system more aptly.

The candidate doesn’t get sidetracked; guide them back on track with the topics you want to focus on

• If you’re asking a very open question like “design Uber,” this is pretty large. Consider honing in on a part of it, like the payments system or matching riders and drivers.
• Tailor the question before the interview starts to already be focused:

  “We’re building out a fleet of self driving cars that act as Taxis. Think of it like Uber but with Teslas only. Let’s focus on matching the riders with these self driving cars for this scenario.”

• If you say “Let’s focus on matching riders with drivers” and the candidate starts designing the full app, redirect them back to the scoped problem.

Get them to make a diagram early on because it:

• Allows for concrete choices to talk about
• Prevents flip-flopping on answers like “why is there a load balancer already in this design when we have no scale?”

Dive into their choices at every stage

• Why have they chosen an object-relational db vs document db?

  “I want to store location information so I chose PostgreSQL because it has a PostGIS extension for storing that kind of information. I could use MongoDB for storing this information instead but I’ve found familiarity with a solution also helps when implementing.”

  Follow up: have they actually used this before? Does it apply to this situation?

• Defining schema: if there is no structure to this, are we using the right db at this point? Does the data we’re using look like it would benefit from a time series db?

• Can they define a database schema?

• Can they define API endpoints?

If they can define the API endpoints, discuss:

• What kinds of functions might be called
• Don’t dive into actually writing the code; focus on what the code is expected to do
• Are things going to run in background jobs?

Don’t move to scaling out too early. There are a lot of questions to be asked in every stage. No rushing!

Scaling: look at some of the questions written and answered here.

The candidate rushed through everything and I can’t think of questions!

Try introducing changes to the requirements:

“This system worked well for us, and we ended up scaling up massively. But now we want to aggressively target a new segment that were previously not reachable.”

Some directions you can take this:

• Integrate with an outside system (e.g. Indeed) to provide this new functionality
• We acquired a legacy system and we need to ensure that it connects with our system; data must flow end to end without data loss and minimal migration work needed. We will not be re-writing the legacy system.

Or try a different scenario:

• There is a CVE in one of the dependencies that would be expensive to patch and could lead to data being exfiltrated. How can we take down this service while minimizing impact on the system until it is patched?

Still stuck? Go back through this page and see if there are topics that weren’t touched on. There likely are!

In closing

Hope this helps with how to structure the conversation, what to probe for at each stage, and how to keep candidates on track without leading them by the hand. Running a great system design interview is harder than it looks, but having a consistent framework makes it a lot easier.