UML Class Diagrams for LLD Interviews (Quick Guide)

🟢 Low-Level Design · Fresher-friendly → 🟠 senior nuance

In a low-level design interview, you'll be asked to sketch your classes — and the standard visual language for that is the UML class diagram. You don't need to memorise the whole UML spec; you need the handful of symbols that let you draw classes and how they relate, quickly and correctly. This guide gives you exactly that toolkit so you can whiteboard a clean design under pressure.

The class box

A class is a box with three compartments: the name on top, attributes (data) in the middle, and methods (behaviour) at the bottom. Visibility markers prefix each member:

• + public · - private · # protected
• Attributes read - name: String; methods read + getName(): String.

The relationship arrows (the part that matters)

🟠 The lines connecting boxes carry the real meaning. These five are all you need:

• Inheritance — a solid line with a hollow triangle pointing to the parent ("is-a").
• Realization — a dashed line with a hollow triangle to an interface ("implements").
• Composition — a line with a filled diamond at the whole ("strong has-a"; part dies with the whole).
• Aggregation — a line with a hollow diamond ("weak has-a"; part can outlive the whole).
• Association — a plain arrow ("uses-a").

Multiplicity: how many?

🟠 Numbers at the ends of a line say how many objects participate: 1 (exactly one), * or 0..* (many), 1..* (one or more). "A ParkingLot 1 —— * ParkingSpot" reads "one lot has many spots." Adding multiplicities shows you're thinking about the real cardinality of relationships — a nice senior touch.

A worked mini-example

Model part of a parking system: an abstract Vehicle with subclasses Car and Bike (inheritance triangles), a ParkingLot composed of many ParkingSpots (filled diamond, 1—*), and a Ticket that associates a Vehicle with a ParkingSpot (plain arrows). That single picture communicates the whole structure faster than paragraphs of description — which is exactly why interviewers ask for it.

How to use it in the interview

🟠 You don't need pixel-perfect UML — you need to communicate structure. Sketch the key class boxes with their main fields/methods, connect them with the right relationship symbol, and add multiplicities where they matter. Talk through it as you draw ("ParkingLot composes spots because a spot has no meaning without its lot"). A clear diagram plus a clear narration is what a strong LLD answer looks like. Don't get lost perfecting notation — get the relationships right.

The interview-ready summary

"A UML class diagram is my thinking tool for LLD. Each class is a box (name / attributes / methods with +,-,# visibility), and I connect them with the right relationship: a hollow triangle for inheritance (dashed for implementing an interface), a filled diamond for composition (part dies with the whole), a hollow diamond for aggregation, and a plain arrow for association — with multiplicities (1, *, 1..*) at the ends. I sketch the core classes and relationships and narrate the choices, rather than obsessing over perfect notation." That's exactly enough UML to ace the round."

What to read next

• Design Patterns in Java — patterns you'll diagram this way
• OOD Basics — the relationships these symbols represent
• Design a Parking Lot — a full class diagram in action
• ← The complete System Design guide (hub)

← SOLID principles · Design patterns in Java →