What LLD Interviews Actually Test

Ask ten engineers what a "system design interview" tests and you will get ten different answers, because "system design" quietly covers two very different skills. High-Level Design (HLD) asks: how do you connect servers, databases, caches, and queues so a system handles a billion requests a day? Low-Level Design (LLD) asks a completely different question: given that you are writing the code for one piece of that system, how do you structure the classes, interfaces, and objects so the code is correct, testable, and survives the next six feature requests without a rewrite?

An HLD round hands you a scenario like "design Twitter" and expects load balancers, sharded databases, and a fan-out strategy for the news feed. An LLD round hands you a much narrower scenario, like "design a parking lot" or "design an in-memory cache", and expects an actual class diagram, real method signatures, and code that would compile and run. There is no database schema to draw and no discussion of servers - the entire system lives inside one process, and the challenge is purely about object-oriented structure.

• -HLD scope: the whole distributed system - services, data stores, network boundaries, and how millions of users hit it.
• -LLD scope: a single component's internal design - classes, interfaces, relationships, and the behavior that lives inside one process.
• -HLD deliverable: a box-and-arrow architecture diagram with capacity numbers.
• -LLD deliverable: a UML-ish class diagram plus working code for the core classes and their interactions.

Interviewers are not grading whether you memorized the Gang of Four pattern names. They are watching four things: whether you clarified the requirements before designing anything, whether your classes have single, well-defined responsibilities, whether your design would survive a "now add feature X" follow-up without a rewrite, and whether you can defend your choices out loud. A design that uses zero named patterns but nails all four of those beats a design that name-drops five patterns and collapses the moment a new requirement shows up.