HLD vs LLD: A Practical Breakdown for Interview Prep
I once watched someone absolutely nail a "design Twitter” question-sharding strategy, fan-out on write vs read, the works-and then completely stall five minutes later when asked to sketch the actual classes for a parking lot system. Different muscle. Nobody had told them that.
That's basically the whole story with HLD and LLD. People treat "system design interview prep" like it's one skill. It's not. It's two, and they don't transfer to each other nearly as much as you'd hope.
The short version
High-level design is the big picture-how the pieces fit together, how data moves between them, what happens when ten times the traffic shows up, what happens when one piece dies at 3am. Load balancers, caches, queues, the reasoning for why they're arranged the way they are. Boxes and arrows, basically, except every arrow has to survive a "why" question.
Low-level design zooms into one of those boxes. Actual classes, actual interfaces, the kind of object-oriented decisions that determine whether the next engineer can extend your code or has to rewrite it. If HLD is the map of the city, LLD is the blueprint for one specific building someone's about to ask you to draw on the spot.
Most interview loops test both eventually. Almost nobody gets to specialize in just one and call it done.
What an HLD question is really asking
You'll recognize these immediately-design a URL shortener, a rate limiter, a notification system, something at the scale of a company everyone's heard of. And the thing that trips people up early on: the interviewer doesn't actually care about your code here. Not yet. They're watching how you reason about:
Scaling-and more specifically, whether you know when horizontal scaling actually helps and when it just adds complexity for nothing
Where the system is going to choke first under load, and what you'd do about it
The consistency-vs-availability trade-off, which stops being a CAP theorem flashcard the moment someone asks you to defend a specific choice for a specific feature
How pieces talk to each other-REST calls, message queues, event streams, and why you picked one over another
What the failure story looks like, because something will eventually fail and "it just works" isn't an answer
Honestly, a lot of getting good at this is just pattern exposure. Not memorizing one perfect design-actually building enough of them that you start recognizing the shapes. Caching shows up in nearly everything eventually. Sharding shows up once you cross some threshold almost every time. The patterns stop feeling like trivia once you've actually hit the wall they're solving for, instead of just reading that the wall exists.
What an LLD question is really asking
Different flavor entirely-design a parking lot, a vending machine, an elevator system, the internals of a rate limiter. Here the interviewer's watching for:
Whether you can actually structure classes and relationships, not just describe a vague structure in prose
Whether the design patterns you reach for (Strategy, Observer, Factory, take your pick) are doing real work or just being name-dropped
How clean your interfaces are-what's exposed, what's hidden, whether someone else could extend this without breaking it
Whether you've thought about the annoying edge cases inside one component, not the whole system
Whether this would survive an actual code review from a teammate who isn't being polite
This is the part where people who are genuinely strong at architecture get caught off guard. Knowing exactly how a parking system should scale across a city doesn't help you when you're staring at a blank editor trying to figure out whether vehicle should know about parkingspot or the other way around.
Why both, and why the order shifts
Junior and mid-level loops skew LLD-heavy, because the assumption is you're closer to the actual code day to day-they want to know if what you write is maintainable. Senior and staff loops skew HLD-heavy, since the bet shifts toward "can this person make calls that don't blow up production a year from now."
But it's messier than that in practice. Plenty of senior loops still throw in an LLD round specifically because talking a good game about architecture and writing clean code turn out to be different skills, and they want to check both. And mid-level loops increasingly open with an HLD question just to see how someone thinks before narrowing in.
If I'm honest, the safest answer is: prep both, weight it toward whatever the role actually needs, and don't assume strength in one means you're fine on the other. I've seen that assumption burn people more than once.
Where people actually trip up
On the HLD side, the mistake I see constantly is designing for scale nobody asked about. Someone says "design a URL shortener for an internal tool" and the candidate immediately goes to multi-region failover and consistent hashing -for a tool three hundred people will use. A decent interviewer notices you didn't ask about scale before architecting around it. The two minutes you spend asking clarifying questions usually save you fifteen minutes of redesigning later.
On the LLD side, it's jumping into code before deciding what objects even exist. I've watched genuinely strong engineers start typing method signatures, get three lines in, realize the structure doesn't actually hold up, and have to backtrack mid-interview while the clock keeps running. A rough class sketch first-even just boxes with names in them — almost always pays for itself.
And the mistake that hits both equally: trying to cram either one the night before. Pattern recognition and clean class design are both things you build through repetition, not through a last read-through. Reading gives you the vocabulary. It doesn't give you the instinct for when a pattern actually fits versus when you're just forcing it because you remember the name.
How I'd actually go about practicing each
For HLD, the thing that works is sitting with a real problem end to end-sketching your own design first, badly if needed, then comparing where your reasoning diverged from a stronger solution and actually figuring out why it diverged, not just memorizing the better answer. I usually do this on ScaleDojo's HLD labs, mostly because it forces the same thing an interviewer forces: defend the trade-off, then see where it actually holds up under pressure instead of just looking reasonable on paper.
For LLD it's a similar instinct, but smaller and more concrete-actually writing the classes instead of describing them out loud. Saying "I'd use the Strategy pattern here" is easy. Implementing it cleanly enough that someone else could extend it without touching half your codebase is the actual skill. ScaleDojo's LLD labs run through the same loop specifically for object-oriented design-the parking systems and elevator systems and rate limiters that show up again and again in interviews, practiced as real code instead of as talking points.
The reason I'd keep these as separate practice reps, not one blended session: blending them makes it too easy to stay comfortably vague the whole time -gesturing at architecture without ever writing a concrete class, or writing nice clean code for a system you never actually stress-tested at scale. Treating them as genuinely different skills is what closes both gaps instead of quietly leaving one open.
Where I'd start if I were you
If you're not sure which to prioritize, the job description usually tells you more than the title does. "Scalable systems" and "distributed architecture" in the posting point toward HLD-heavy prep. "Clean code," "design patterns," "object-oriented design" point toward LLD. Most loops test both eventually anyway, so betting everything on one is the riskier move, even if it feels efficient right now.
I write about system design and backend engineering. For hands-on practice across both HLD and LLD, plus API design and GenAI system design, I'd point readers to ScaleDojo.
