UML Diagrams for LLD Interviews
The reference guide for reading and drawing the UML diagrams that matter in LLD interviews: class, sequence, state, and activity diagrams, and when each one earns its place.
UML Diagrams for LLD Interviews
Every mermaid diagram in every other guide in this series — the classDiagram boxes, the sequenceDiagram call chains, the flowchart decision trees — is UML notation, or close enough to it that the vocabulary transfers directly. This guide is the decoder ring: what each shape and arrow means, not just what it looks like. In an LLD interview, being able to sketch a class diagram in ninety seconds that correctly distinguishes composition from aggregation is often worth more than the code itself — it signals you understand object lifecycles, not just syntax.
1. Class Diagrams: Structure and Relationships
A class diagram is the only UML type that shows what exists rather than what happens over time. Every box is a class or interface; every arrow is a specific, named kind of relationship — and the arrow type carries real semantic weight, not just visual variety.
| Relationship | Arrow (mermaid) | Reads as | Lifecycle: does the "part" die with the "whole"? |
|---|---|---|---|
Inheritance (implements/extends) | ..|> (dashed, hollow triangle) for interface implementation; --|> (solid, hollow triangle) for class extension | "is a" | N/A — it's a type relationship, not ownership |
| Composition | *-- (filled diamond at owner) | "owns and is made of" | Yes — the part cannot outlive the whole. Order deleted → its LineItems are deleted; a LineItem has no meaning outside its Order |
| Aggregation | o-- (hollow diamond at owner) | "has a, but doesn't own exclusively" | No — the part survives independently. Car deleted → the Driver still exists and can drive another car |
| Association | --> (plain arrow) | "uses / refers to" | N/A — a reference relationship, no ownership implied either way. Order refers to a PaymentMethod but doesn't own its lifecycle |
| Dependency | ..> (dashed arrow) | "depends on, temporarily" | N/A — weaker than association; typically a method parameter or local variable, not a stored field |
The composition-vs-aggregation distinction is the single most commonly tested class-diagram detail in LLD interviews, and the test is always the same question: "if you delete the whole, does the part get deleted too?" Yes → filled diamond, composition. No → hollow diamond, aggregation. Order/LineItem is composition; Car/Driver is aggregation; Library/Book is aggregation (delete the library record, the physical books still exist); House/Room is composition (a room doesn't exist independent of its house).
Visibility and member notation
| Symbol | Visibility | Java equivalent |
|---|---|---|
+ | public | public |
- | private | private |
# | protected | protected |
~ | package-private | (no modifier) |
+charge(amount: double) boolean reads as: public method charge, one parameter amount of type double, returns boolean — this maps directly onto Java's public boolean charge(double amount).
A class diagram with correctly distinguished composition, aggregation, association, and inheritance is effectively describing the same design decisions covered in the OOP Pillars Deep Dive guide (encapsulation, inheritance) and the Coupling & Cohesion guide (association vs dependency strength) — the diagram is a visual vocabulary for those same design choices.
2. Sequence Diagrams: Interaction Over Time
Where a class diagram is static, a sequence diagram shows one specific scenario playing out as a sequence of method calls between objects, top to bottom in time order.
| Notation | Meaning |
|---|---|
Solid arrow (->>) | Synchronous method call |
Dashed arrow (-->>) | Return value / response |
alt / else block | Conditional branching — different paths through the same interaction |
| Vertical order top-to-bottom | Time — this is the one diagram type where position on the page encodes sequence |
Sequence diagrams are what you draw when an interviewer asks "walk me through what happens when a user does X" — they force you to name every collaborator involved and the exact order calls happen in, which surfaces missing error handling (what if reserveStock fails?) far faster than prose or code alone.
3. State Diagrams: Object Lifecycle
A state diagram shows the finite states one object can be in and the events that trigger transitions between them — this is the direct visual counterpart of the State design pattern.
| Notation | Meaning |
|---|---|
[*] --> | Initial state — where the object's lifecycle begins |
--> [*] | Final state — terminal, no further transitions |
A --> B: event | Transition from state A to B, labeled with the triggering event/condition |
Draw a state diagram whenever an object's allowed next actions depend on its current status — an Order that can be cancelled while Pending but not while Shipped is exactly the scenario the State pattern (and this diagram) exists for. If you find yourself writing if (status == PENDING) { ... } else if (status == SHIPPED) { ... } scattered across multiple methods, that's the code-level signal a state diagram would have caught at design time.
4. Activity Diagrams: Workflow and Process Flow
An activity diagram models a process — the flow of control across possibly many objects or actors — as opposed to a sequence diagram's focus on messages between specific objects, or a state diagram's focus on one object's lifecycle.
| Notation | Meaning |
|---|---|
| Rounded start/end shapes | Process entry and exit points (an activity diagram can have multiple end points, unlike most sequence diagrams) |
| Diamond | Decision point — branches on a condition |
| Rectangle | An action or activity step |
| Arrows | Control flow — "and then" — not messages between specific objects |
Activity diagrams are the right tool when the interviewer's question is about business process/workflow ("what's the checkout flow?") rather than about a specific object's behavior or a specific pair of objects messaging each other. They're also the closest UML diagram to a plain flowchart — which is exactly why mermaid's flowchart syntax works for both.
5. When to Skip UML Entirely
Not every design needs a diagram. Drawing one has a cost — time in an interview, upkeep in a codebase — and that cost should buy clarity, not ceremony.
| Situation | Draw a diagram? |
|---|---|
2-3 classes with one obvious relationship (e.g. a single Strategy interface and two implementations) | No — describe it in a sentence, save the time |
| A design with 5+ classes and non-obvious relationships (composition vs aggregation matters, multiple interfaces) | Yes — a class diagram prevents ambiguity that would otherwise surface as a misunderstanding mid-interview |
| An interviewer explicitly asks "walk me through the flow when X happens" | Yes — sequence diagram, this is exactly what's being asked for |
An object has 2 states with a trivial boolean flag (isActive) | No — a state diagram for a boolean is overkill; just say "it's a flag" |
| An object has 4+ states with conditional, order-dependent transitions | Yes — state diagram, and consider whether the State pattern applies |
| Documenting a stable, rarely-changing internal utility class | No — the maintenance cost of keeping a diagram in sync outweighs the benefit for code that doesn't change |
In an interview, spending eight minutes perfecting a UML diagram for a three-class design is a worse signal than spending ninety seconds on a rough sketch and moving on to the code — interviewers are grading judgment about when to model, not just diagramming skill.
6. Tools
| Tool | Best for |
|---|---|
| PlantUML | Text-based, version-controllable, precise UML notation — good for design docs that live in a repo |
| Mermaid | Text-based, renders natively in Markdown/many doc tools (including this site) — slightly less strict UML notation than PlantUML but far more portable |
| draw.io / diagrams.net | Free-form, precise control, good for polished design-doc diagrams shared outside engineering |
| Excalidraw | Fast, hand-drawn-style sketches — ideal for live interview whiteboarding and quick brainstorming |
| Whiteboard / paper (in-person interviews) | Fastest for live interviews — no tool overhead, just the notation conventions from this guide |
7. Decision Table: Which Diagram Do You Draw?
| Interview moment | Diagram to draw |
|---|---|
| "Design the classes for a parking lot / elevator / library system" | Class diagram |
| "Walk me through what happens when a user places an order" | Sequence diagram |
"How does a Order/Connection/Document object's status change over its lifecycle?" | State diagram |
| "What's the end-to-end checkout / approval / onboarding process?" | Activity diagram |
| "What design pattern would you use here?" (after identifying repeated conditional state logic) | State diagram first (to see the states), then a class diagram (to show the pattern's structure) |
| "How do these two services communicate?" | Sequence diagram (call order) — optionally a class diagram if the interfaces themselves need defining |
| A quick 2-3 class relationship with no ambiguity | Skip UML — say it in one sentence |
A useful mental shortcut: class diagrams answer "what exists and how are they related"; sequence diagrams answer "what happens, in what order, between which objects"; state diagrams answer "what can this one object become, and when"; activity diagrams answer "what's the process, regardless of which objects are involved." If you can name which of those four questions the interviewer just asked, you know which diagram to draw.
8. Multiplicity Notation
Every relationship line in a class diagram can carry multiplicity labels at each end, stating how many instances participate — this is the same 1:1 / 1:N / M:N vocabulary from ER diagrams, applied to objects instead of tables.
| Multiplicity | Meaning |
|---|---|
1 | Exactly one |
0..1 | Zero or one (optional single reference) |
0..* or * | Zero or many |
1..* | One or many (at least one required) |
many / N | Unbounded, generally more than one, exact bound not asserted |
Reading Customer "1" --> "many" Order: one Customer is associated with many Orders — the same fact a 1:N ER relationship would express with the foreign key living on Order. This is exactly why the object model and the schema (see ER Diagrams & Schema Design) tend to mirror each other so closely: a 1:N class association usually becomes a 1:N table relationship with the FK on the "many" table.
9. A Worked Example: Reading an Unfamiliar Class Diagram
Interviewers sometimes hand you a class diagram and ask you to explain it, rather than asking you to draw one — the reverse skill matters just as much.
A correct reading, in order: NotificationChannel is an interface (guillemets <<interface>>) with one method, send. EmailChannel and SmsChannel both implement it (dashed hollow-triangle arrows — this is the Strategy pattern, not inheritance of shared implementation). NotificationService aggregates a list of channels — hollow diamond, so the channels are not exclusively owned by the service and could be shared or independently constructed; deleting the service wouldn't delete the channel objects. User merely associates with a channel (a plain arrow) to record a preference — the weakest relationship on the diagram, just a reference, no ownership claim either way.
When reading a diagram cold, work through it in this order: (1) find the interfaces/abstract classes first — they usually anchor the design; (2) trace inheritance/implementation arrows to see what pattern is in play (Strategy, Factory, Decorator...); (3) only then look at composition/aggregation to understand object lifecycles; (4) associations and dependencies last — they're the weakest links and rarely change the overall shape of the design.
Interview Questions
- What's the difference between composition and aggregation, and what's the concrete test to tell them apart?
- In a class diagram, what does a dashed arrow with a hollow triangle mean versus a solid arrow with a hollow triangle?
- When would you draw a sequence diagram instead of a class diagram to answer an interviewer's question?
- How does a state diagram relate to the State design pattern? What code smell suggests you should have drawn one?
- What's the structural difference between a sequence diagram and an activity diagram — both show "things happening over time," so what distinguishes them?
- Give an example of association vs dependency in a class diagram, and explain why dependency is considered a "weaker" relationship.
- When is it a mistake to draw a UML diagram at all, in an interview setting?
- Name a tool you'd use for (a) a live whiteboard interview and (b) a design doc that needs to live in version control, and explain the difference in requirements.