UML class diagrams are the universal sketch language for LLD interviews. When an interviewer says “walk me through your design,” they expect a quick diagram showing classes and how they relate. We don’t need to be UML experts — just enough to communicate clearly.
The Class Box
Every class is drawn as a box with three sections:
# protectedField: Type
+ publicField: Type
- privateMethod(): void
# protectedMethod(): void
In interviews, we don’t always fill in every detail. Sometimes just the class name and key methods are enough. Speed matters more than perfection.
Relationships
This is where UML gets really useful. There are six relationships we should know:
1. Association (uses)
A basic “knows about” relationship. One class uses another.
Student ──────── Course
"A student is enrolled in a course"An Order has a reference to a Customer. They know about each other but can exist independently.
2. Aggregation (has, loosely)
A “whole-part” relationship where the part can exist without the whole. Drawn with an empty diamond on the “whole” side.
Department ◇──────── Employee
"Department has employees, but employees exist without the department"If we delete the Department, the Employee objects still exist. They can work somewhere else.
3. Composition (has, tightly)
A stronger “whole-part” relationship where the part CANNOT exist without the whole. Drawn with a filled diamond.
House ◆──────── Room
"House has rooms. Destroy the house, rooms are gone too"A Room makes no sense without its House. If the house is demolished, the rooms go with it.
4. Inheritance (is-a)
A child class extends a parent class. Drawn with a hollow triangle arrow pointing to the parent.
Animal
△
/ \
Dog Cat
"Dog is an Animal"5. Implementation (implements)
A class implements an interface. Drawn with a dashed line and hollow triangle.
<<interface>>
Flyable
△
┆ (dashed)
┆
Bird
"Bird implements Flyable"6. Dependency (uses temporarily)
A class uses another class temporarily (e.g., as a method parameter). Drawn with a dashed arrow.
OrderService - - - -> EmailService
"OrderService uses EmailService to send confirmation"The only difference from association: dependency is temporary (method parameter), association is stored (field).
Arrow Reference
| Relationship | Arrow | Meaning |
|---|---|---|
| Association | A ────> B | A knows about B |
| Aggregation | A ◇───> B | A has B (B can exist alone) |
| Composition | A ◆───> B | A owns B (B dies with A) |
| Inheritance | B ───▷ A | B is a type of A |
| Implementation | B --▷ A | B implements interface A |
| Dependency | A ---> B | A temporarily uses B |
Example: Library System
Let’s sketch a simple library system to put it all together:
- books: List<Book>
+ searchByTitle(String)
- isbn: String
- author: Author
+ isAvailable(): bool
- memberId: String
+ returnBook(Book)
The relationships:
- Library ◆── Book: Composition. Books belong to the library. Delete the library, the books catalog is gone.
- Member ──> Book: Association. A member borrows books but they’re independent entities.
- Book ──> Author: Aggregation. A book has an author, but the author exists independently.
Tips for Interviews
- Start with nouns — the nouns in the problem statement often become classes (
ParkingLot,Vehicle,Spot,Ticket) - Draw boxes first, arrows later — get the classes right before worrying about relationships
- Keep it simple — don’t draw every getter/setter. Focus on key attributes and methods
- Use the whiteboard wisely — leave space between classes so we can add arrows without it becoming a mess
- Talk while drawing — explain our thinking. “I’m making this a composition because a Room can’t exist without a Hotel”
We don’t need to memorize UML syntax perfectly. The interviewer cares that we can clearly communicate our design. A clean sketch with clear relationships beats a perfect UML diagram that takes 20 minutes to draw.