The HLD Interview Framework
Beginner · 14 min read · High-Level Design, Foundations
A step-by-step method for running a design interview, from requirements to deep dives.
A system design interview is not a quiz with a correct answer. It is a 45–60 minute simulation of a design discussion with a senior colleague. The interviewer is evaluating how you think: whether you clarify ambiguity, make reasonable assumptions, choose sensible building blocks, and — most importantly — explain the…
Candidates rarely fail because they don't know what a cache is. They fail because they jump straight into drawing boxes, design for the wrong problem, run out of time before the interesting part, or can't justify their decisions. A framework fixes all four.
What interviewers are actually scoring
Most companies use a rubric that looks roughly like this. Keep it in mind — every step of the framework maps to one of these signals.
The seven-step framework
A rough time budget for a 45-minute interview:
Communicating trade-offs
The single most important habit in a design interview is making trade-offs explicit. Compare:
Common mistakes
A worked opening
Here is what the first five minutes might sound like for "Design a URL shortener":
Interview questions
- The interviewer says 'Design Instagram' and nothing more. What do you do first?
- How do you decide which areas to deep-dive into?
- The interviewer challenges your database choice. How should you respond?
- What's the difference between functional and non-functional requirements, and which matters more for architecture?
Practice
Write your answer before opening the suggested one. If you mark it "Partly" or "Missed it", it comes back in your review deck.
Further reading
Key takeaways
- The interview evaluates reasoning and communication, not memorised architectures.
- Follow a fixed sequence: requirements → estimation → API → data model → high-level design → deep dives.
- Non-functional requirements (scale, latency, consistency) shape the design more than features do.
- Build a simple working end-to-end design first, then optimise the parts that matter.
- For every decision: requirement → options → choice → cost.