01OverviewTypes of system design interviews
01 · Orientation
Types of system design interviews
Distinguish product, infrastructure, object-oriented, and ML system design prompts.Lesson spine
What you need to understand.
The same opening prompt can test very different skills; identify the interview contract before choosing your depth.
Product design
Start with actors, critical user journeys, core entities, public APIs, and scale. Examples include feeds, marketplaces, maps, and chat.
Infrastructure design
Define the primitive and its guarantees before products or vendors. Expect depth on partitioning, replication, concurrency, and recovery.
Object-oriented design
Model responsibilities, interfaces, composition, state transitions, and extension points. Distribution is usually secondary unless requested.
ML system design
Connect data collection, training, evaluation, deployment, online inference, monitoring, and feedback. Model quality is only one system metric.
Detect the format
Ask what level, traffic envelope, and primary use cases the interviewer wants. Their answer determines whether you should draw services, classes, or an ML lifecycle.
Before the boxes
Frame the decision.
What must work
Distinguish product, infrastructure, object-oriented, and ML system design prompts.
What changes the design
Identify and confirm the format in the first 90 seconds.
What earns a decision
Separate facts you learned from assumptions you made, then name the requirement that justifies each architectural choice.
What stays out of scope
Do not solve every adjacent product problem. State exclusions so the interview can go deep on the decisions that matter.
Architecture map
Trace the reasoning, not just the boxes.
Follow the decision from left to right. Every arrow should have a reason.
Identify the expected artifact
Product, infrastructure, OOD, or ML
Select the relevant signals
Adapt the sequence
Confirm the format
Walk the method in order. At each arrow, state what new evidence or decision lets you advance without hiding an assumption.
- 01
Prompt clues — Identify the expected artifact Make the output of this reasoning step explicit before moving on.
- 02
Interview type — Product, infrastructure, OOD, or ML Make the output of this reasoning step explicit before moving on.
- 03
Evaluation lens — Select the relevant signals Make the output of this reasoning step explicit before moving on.
- 04
Method — Adapt the sequence Make the output of this reasoning step explicit before moving on.
- 05
Checkpoint — Confirm the format Summarize the decision and invite the next deep dive.
Decision table
Make the trade-offs explicit.
| Decision | Defensible position | Cost to acknowledge |
|---|---|---|
| Primary method | Product design rewards end-to-end flows; infrastructure design rewards invariants and recovery. | A visible structure costs a little time but prevents a shallow or directionless design. |
| Breadth vs. depth | Cover the end-to-end shape, then spend the remaining time on the highest-risk requirement. | Going deep too early can leave the core flow incomplete; staying broad hides engineering judgment. |
| Assume vs. clarify | Ask about decisions that change the architecture and state reasonable defaults for everything else. | Too many questions consume the interview; silent assumptions make the solution impossible to evaluate. |
Failure review
Recover the conversation.
Topic-specific risk
A memorized template can answer the wrong kind of question.
ResponseReturn to the prompt, make the missing assumption explicit, and restate the decision in a form the interviewer can challenge.
Premature solutioning
Jumping to technology before requirements makes every later choice look arbitrary.
ResponsePause, restate the user flow and scale envelope, then connect each component to a named constraint.
Unstructured deep dive
A good idea can still read as weak judgment when the interviewer cannot follow the decision path.
ResponseState the claim, alternatives, deciding constraint, and accepted cost before drawing the next box.
Evidence + level bar
Make the reasoning observable.
Clarity of the argument
Make requirements, assumptions, alternatives, and accepted costs audible. The interviewer should never need to guess why a box exists.
Complete and clear
Finish the happy path, identify the state owner, choose reasonable building blocks, and explain one scale mechanism.
Trade-offs and failure
Separate read and write paths, define consistency, explain partitioning, and make duplicate or partial failure safe.
Evolution and operations
Discuss multi-region boundaries, migration, tenant isolation, capacity, observability, and how the architecture changes over time.
Interview language
Open the deep dive with a claim.
“For Types of system design interviews, the method I want to make explicit is this: Product design rewards end-to-end flows; infrastructure design rewards invariants and recovery. I’ll state the output of each step, surface the assumption behind it, and use the highest-risk requirement to choose where we go deep.”
08 · Retrieval check
Can you defend it without the page?
- For Types of system design interviews, where is the correctness boundary and which failure would you test first?
- Which assumption most changes the design, and how would you validate it with the interviewer?
- Where would you stop covering breadth and begin the highest-value deep dive?
- How would you recover if the interviewer challenged your core requirement or estimate?
- Which part of your explanation could be removed without weakening the argument?