System Design · Interview Guide
Approach HLD Interviews With Structure.
High-Level Design (HLD) interviews test how you translate ambiguous requirements into a scalable, reliable architecture. The goal is not to draw the most complex system, but to make clear decisions and explain their trade-offs.
Think first. Design second.
Start by understanding the problem. Estimate the scale, define the system’s data and interfaces, design the architecture, and then investigate its risks and trade-offs.
01 / The mindset
What interviewers look for
There is rarely one universally correct architecture. Interviewers want to understand how you reason about a problem and adapt your design to its constraints.
Problem understanding
Identify the essential features, users, constraints, and quality requirements before choosing a solution.
Structured reasoning
Move logically from requirements to data, interfaces, components, and architecture.
Technical judgment
Explain why a choice fits the workload, what alternatives exist, and when that choice might stop working.
Communication
State assumptions, think aloud, invite feedback, and respond constructively to new constraints.
Golden rule: Never jump straight into architecture. First agree on what you are designing.
02 / The framework
A repeatable HLD approach
Follow these seven steps for a consistent starting point. Adapt the depth and order to the problem, interview duration, and interviewer’s direction.
Clarify requirements
Define the scope before discussing solutions.
- Functional: What must users be able to do?
- Non-functional: What latency, availability, consistency, or security goals matter?
- Clarify users, scope, constraints, and exclusions.
Ask: What is in scope, and what matters most?
Estimate the scale
Use reasonable assumptions to guide architectural choices.
- Estimate users, requests per second, and peak traffic.
- Consider read/write ratios and data growth.
- Estimate storage and bandwidth where relevant.
Ask: What workload must the system handle?
Define APIs and data
Establish the core interactions and information the system needs.
- Identify core entities and their relationships.
- Define the main API operations and data contracts.
- Choose a suitable storage model and access patterns.
Ask: What data is stored, and how is it accessed?
Draw the architecture
Start simple and add components to satisfy requirements.
- Map clients, APIs, services, databases, and integrations.
- Show important request and data flows.
- Add caches, queues, or CDNs when justified.
Ask: What does each component do, and why?
Deep-dive into critical paths
Choose the most important or challenging part of the system.
- Trace a key read or write flow.
- Explain data consistency and processing choices.
- Investigate likely bottlenecks and scaling limits.
Ask: Which part needs the most careful design?
Address reliability and trade-offs
Explain how the design behaves under load and failure.
- Consider replication, failover, retries, and timeouts.
- Discuss security, observability, and recovery.
- Compare meaningful alternatives and their costs.
Ask: What fails, and how does the system recover?
Summarize and validate
Close by connecting the design to the original requirements.
- Recap the architecture and key decisions.
- Identify limitations and remaining risks.
- Explain what you would improve with more time.
Ask: Does this design meet the stated goals?
Remember: The framework is a guide, not a rigid script. Prioritize the requirements and follow the most important architectural questions.
03 / Time management
One possible 45-minute plan
Use this as a starting point for a 45-minute interview. Rebalance the time based on the problem and interviewer feedback.
Agree on scope, core features, and quality goals.
Calculate the few numbers that influence the design.
Establish key operations, entities, and storage needs.
Draw components and explain the main request flows.
Explore critical paths, scaling, failure handling, and trade-offs.
Summarize the design, limitations, and next improvements.
04 / Avoid these pitfalls
Common HLD interview mistakes
Strong system design is about solving the stated problem, not demonstrating how many technologies you know.
Jumping into architecture
Clarify requirements and constraints before drawing components.
Over-engineering
Start with the simplest viable design. Add complexity only when a requirement or measured bottleneck justifies it.
Ignoring data and traffic
Use workload estimates and access patterns to guide storage, caching, and scaling decisions.
Listing technologies without reasoning
Explain why a component is needed, its limitations, and which alternatives you considered.
Ignoring failures
Consider timeouts, retries, dependency failures, recovery, and single points of failure.
Staying silent
Explain your reasoning as you go and invite the interviewer to clarify priorities or challenge assumptions.
05 / Continuous improvement
Review every practice session
After each problem, evaluate your process—not just whether you arrived at a plausible architecture.
- Did I clarify the scope and prioritize requirements?
- Were my estimates reasonable and useful?
- Did I explain APIs, data, and request flows?
- Could I justify my major architectural decisions?
- Did I address the main bottlenecks and failure scenarios?
- Did I communicate clearly and manage time effectively?
- What was my biggest knowledge or reasoning gap?
- What will I do differently in the next attempt?
06 / Keep learning
Put the framework into practice
Learn the fundamentals, explore individual concepts, and practice complete system design problems.
The key takeaway
Don’t memorize architectures. Master the reasoning.
Understand the problem, make assumptions explicit, build incrementally, and justify your decisions. Repeated deliberate practice turns this process into a reliable interview skill.