You've been reading small diagrams since Lesson 2, without being told the rules behind them. This lesson makes those rules explicit — not so you can recite UML notation, but so you can draw a design on a whiteboard fast enough that it actually helps the conversation, instead of slowing it down.
Every diagram in this lesson (and this course) passes one test: can an engineer redraw the important part of it in 60-90 seconds? If a diagram fails that test, simplify it — UML in an interview is a communication tool, not an architecture poster.
Class diagrams: structure
A class diagram answers one question: what exists, and how is it shaped? Each box is one class or interface — name on top, fields below, methods at the bottom:
You don't need every field and method for a whiteboard — the goal is showing what job the class owns, not a complete API reference.
Inheritance, composition, aggregation
Three lines cover almost every relationship you'll need in an LLD interview:
Inheritance / implements (hollow triangle, pointing at the parent — "is-a"):
Composition (filled diamond ◆ — the part's lifetime belongs to the whole; delete the whole, the parts go too):
Aggregation (hollow diamond ◇ — the part can exist independently, just associated with the whole):
The practical test for composition vs aggregation: if deleting the whole should delete the parts, it's composition; if the parts can outlive the whole, it's aggregation. A Playlist and its Songs is aggregation — the songs exist even if you delete the playlist. A ParkingFloor and its ParkingSpots is composition — a spot makes no sense once its floor is gone.
Sequence diagrams: who calls whom
A class diagram is static — it never tells you "when the user clicks book, who gets called first, and in what order?" That's what a sequence diagram traces, for one specific flow:
Draw one for any flow with more than two or three calls in sequence — it forces you to actually think through the collaboration, catching missing steps a class diagram alone would hide.
State diagrams: an object's internal condition
Some objects genuinely behave differently depending on an internal condition — an order, an elevator, a vending machine. A state diagram shows those conditions as circles and the events that move between them as labelled arrows:
You'll use this properly for the Elevator System and Vending Machine lessons later in this course, where State (the pattern) is the direct code translation of this exact diagram.
From UML straight to code
A well-drawn diagram should translate almost line-for-line into class skeletons — no separate mental step in between:
reads directly as: an abstract PaymentStrategy, two classes implementing it, and an Order holding one as a field — exactly the Strategy code from Lesson 5. If you can't map your own diagram to code this directly, the diagram is probably vaguer than it needs to be.
When to skip a diagram entirely
Not every lesson or every problem needs all three diagram types. A two-class relationship is often clearer as one sentence than as a diagram. Draw a diagram when it replaces paragraphs of explanation — skip it when it would just decorate something already obvious.
Common mistakes
- Drawing every field and method on a whiteboard instead of just what clarifies the design.
- Confusing composition and aggregation — always apply the "does the part outlive the whole" test.
- Skipping a sequence diagram for a flow with several calls, then getting lost explaining the order verbally.
- Drawing a state diagram for an object with no real internal states, just to look thorough.
Quick recap
| Diagram | Answers |
|---|---|
| Class diagram | What exists, and how is it structured/related? |
| Sequence diagram | For one flow, who calls whom, in what order? |
| State diagram | What internal conditions can this object be in, and what moves it between them? |
| Composition (◆) | Part's lifetime belongs to the whole. |
| Aggregation (◇) | Part can exist independently of the whole. |
One thing to remember
A UML diagram exists to be redrawn on a whiteboard in under two minutes and translated into code without a second thought — if yours can't do both, simplify it.
Practice Zone
Five MCQs, then two reasoning questions.
In a UML class diagram, what does a hollow triangle arrowhead (△) pointing from a subclass to a superclass represent?
Asked in
What's the practical difference between composition (filled diamond ◆) and aggregation (hollow diamond ◇) in a class diagram?
Asked in
What does a sequence diagram primarily show that a class diagram doesn't?
Asked in
When is a state diagram the right tool to reach for in an LLD interview?
Asked in
What is the 'whiteboard test' this course applies to every diagram?
Asked in
Think it through, then reveal:
Requirement: 'A ParkingLot has multiple ParkingFloors. Each floor has multiple ParkingSpots. A ParkingLot also has a list of ParkingObservers it notifies on spot changes.' Which relationships would you draw, and with which notation?
Asked in
How does a Context o-- Strategy line in a UML class diagram map directly to code?
Asked in
FAQ
Do I need to know formal UML notation exactly (e.g. exact multiplicity syntax) for interviews?
No — most interviewers care that your diagram communicates the design clearly, not that every arrowhead matches the OMG UML spec exactly. Consistent, readable notation (as used throughout this course) is more than enough.
Should I draw a class diagram before or after writing code?
Before, at least a rough one — it's cheap to redraw a diagram, expensive to rewrite code. Sketch the classes and relationships first, adjust as you think through edge cases, then translate to code once the shape feels stable.
Are activity diagrams and component diagrams important for LLD interviews?
Rarely needed at SDE-I/II level — they're more common in HLD or formal documentation. Class, sequence, and (when relevant) state diagrams cover the overwhelming majority of what LLD interviews actually ask you to draw.
You now have every tool this course uses: SOLID, five patterns, and UML. Time to put all of it to work — starting with a problem that looks deceptively simple — Lesson 9: Design a URL Shortener →