Anatomy of an LLD Interview

The timer starts, and the interviewer says, “Design a room-booking system.” You can already picture classes, so you open the editor—and ten minutes later discover you never asked whether bookings may overlap. The code runs, but it solves the wrong problem.

A low-level design (LLD) interview asks you to turn a small product problem into collaborating classes and code. In a machine-coding interview, you also implement enough of that design to exercise a core flow, one required request from start to result. The names vary, but a 45-minute version usually tests the same skill: can you reduce ambiguity, shape the problem, and explain your choices while the clock moves?

A useful 45-minute shape

Treat the timings as guardrails, not a stopwatch. A hard requirement may deserve another minute, while a small prompt may let you start coding sooner. What matters is that no phase quietly consumes the whole interview.

1. Clarify requirements — minutes 0–6.

   A requirement is a behavior or rule the solution must support. Ask enough questions to discover the core success case, invalid cases, and boundaries.

   For a community room-booking prompt, you might ask:

   • Who makes a booking: any visitor or a registered member?
   • Can two bookings overlap in the same room?
   • Can a member cancel?
   • Is a waitlist part of this version?
   • Does the interviewer care about saving bookings after the program stops?

   Then play the answers back in one compact statement: “A registered member can reserve one room for a time slot. Confirmed bookings for the same room cannot overlap. Cancellation is in scope; waitlists and recurring bookings are out.” An assumption is a condition you accept as true so you can move forward. Say assumptions aloud instead of hiding them in code.

2. Identify core entities — minutes 6–11.

   An entity is a distinct thing the design needs to track, such as a Room, Member, or Reservation. A responsibility is the work one class owns. Candidate nouns help you start, but not every noun deserves a class.

   Ask what information must survive through the flow and who should own each rule. A Room may describe its name and capacity. A Reservation may connect a member, a room, and a time slot. Some coordinating class must answer whether a slot is free. You are forming a first model, not signing a contract with your whiteboard.

3. Sketch the class design — minutes 11–18.

   Use the class-diagram notation you already know. Give each class only the fields and methods needed by its responsibility. Method names should read like the actions in the requirements: reserve(), cancel(), and isAvailable() tell a clearer story than process() or handleData().

   Look for one owner per rule. If overlap detection appears in three classes, those copies will drift. If one class books rooms, formats messages, saves files, and prints reports, it owns too much. You do not need inheritance or another advanced tool to make this first design credible; the smallest design that protects the core rules is enough.

4. Walk one flow — minutes 18–23.

   A happy path is the normal successful route through the system. Narrate one from start to finish: Mina requests Studio B from 18:00 to 19:00, the schedule checks existing reservations, a reservation is created, and Mina receives confirmation.

   Then test one edge case, an input near a rule or boundary that can expose a bug. What happens when Omar requests Studio B from 18:30 to 19:30? The second request must be rejected without changing the first reservation. You can sketch a short sequence diagram if the hand-offs are unclear, but the goal is to prove that your classes can carry a real request.

5. Code the skeleton — minutes 23–38.

   A code skeleton is the smallest set of types, named operations, and working code that makes the design concrete. Build the core flow end to end. Create the main classes, implement the overlap rule, and exercise one success plus one rejection.

   Keep the first pass narrow. Clear names and one correct flow beat half-built support for waitlists, databases, notifications, and every input format. When something remains unfinished, say what is missing and where it belongs. That turns an omission into an explicit scope decision.

6. Discuss extensions and review — minutes 38–45.

   Extensibility is how easily a design accepts a new requirement without forcing unrelated parts to change. The interviewer may now add recurring bookings, a waitlist, or email reminders. Do not bolt each feature onto the nearest class. Trace where the new rule enters, which responsibility it affects, and what stays untouched.

   They may also ask about persistence, saving data beyond the current program run. You do not need to build it unless asked. Explain where loading and saving would meet the current design, then name the trade-off. Finish by reviewing the core flow, the edge case you handled, and one limitation you would address with more time.

What the interviewer is grading

“Did it run?” matters, but it is one line on a wider scorecard.

• Requirements handling: You ask targeted questions, state assumptions, and keep out-of-scope work out.
• Clean responsibilities: Each class has a clear job, and each important rule has an obvious owner.
• Core correctness: The main flow works, invalid input does not corrupt state, and failure behavior is deliberate.
• Extensibility: A realistic change has a clear landing place instead of triggering a rewrite everywhere.
• Communication: You narrate decisions, listen when the prompt changes, and make trade-offs explicit.

Interviewers can reach different designs and still give both candidates strong scores. There is rarely one sacred class diagram. They are looking for a model you can defend and revise, not a memorized picture.

Three failure modes that sink good coders

Coding too early

Opening the editor after the first sentence feels fast. It often creates rework. If you discover the no-overlap rule after writing BookingSystem.create(), the class boundaries may already assume the wrong flow.

Recovery is cheap: stop, write the three core requirements, and state what is out of scope. Six focused minutes at the start can save fifteen unfocused minutes later.

Building a God class

A God class is one class that controls too many unrelated responsibilities. A BookingManager that validates members, finds rooms, checks overlaps, writes files, sends messages, and prints reports becomes the place every change lands.

Do not split it into tiny classes just to increase the count. Group work that changes for the same reason. Scheduling rules belong together; message formatting does not need to live beside them.

Ignoring edge cases

A successful booking proves only the easiest route. Ask what happens when the room is already taken, the end time is before the start time, the same reservation is cancelled twice, or an unknown member makes a request. You do not need to code every case in 45 minutes. You do need to show that you see the boundaries and know which ones threaten the core rule.

One last trap is silence. Quiet coding hides whether you are stuck, choosing, or overlooking something. Narrate at decision points: “I am keeping notifications out of the core model because a failed email should not undo a valid reservation.” That sentence exposes both a boundary and its reason.

A compact reset when the clock gets messy

If you lose the thread, return to four questions:

1. What exact flow must work?
2. Which class owns the rule that can reject it?
3. What state changes on success, and what stays unchanged on failure?
4. What would I leave as the next extension?

Those questions pull you back from class collecting and toward observable behavior. They also give the interviewer clear places to challenge your design.

Checkpoint ✦

Answer all three to mark this lesson complete

You now have a route through the interview even when the prompt is vague. Next, you will sharpen the first building block in that route: an object with state, behavior, and identity.