Communicating Your Design

Imagine two candidates describing the same parking lot system design. Candidate A spends five minutes verbally explaining class relationships: "The ParkingLot contains multiple Floors, each Floor has many ParkingSpots, and each ParkingSpot can hold one Vehicle. There's also a ParkingTicket that references both the Vehicle and the ParkingSpot..."

Candidate B draws a simple diagram in 90 seconds, then points: "Here's the structure. ParkingLot aggregates Floors, each Floor aggregates ParkingSpots. This association between ParkingSpot and Vehicle is optional—the spot might be empty. ParkingTicket captures the parking session, linking these elements."

Which candidate communicated more effectively?

Candidate B's diagram accomplished in seconds what Candidate A's words took minutes to convey poorly. More importantly, the diagram creates a shared visual reference that both parties can point to, annotate, and evolve throughout the interview.

Diagrams in LLD interviews serve purposes that words and code cannot fulfill alone. Understanding these purposes helps you leverage visual communication strategically.

1. Diagrams reduce cognitive load

The human working memory can juggle only about 4-7 items simultaneously. When you verbally describe a system with 8 classes, 12 relationships, and multiple design patterns, you're asking the interviewer to mentally construct and hold a complex model while evaluating your decisions.

A diagram externalizes this mental model. Instead of remembering "ParkingLot contains Floors contains Spots," the interviewer sees it. Their cognitive resources shift from memory to evaluation—exactly what you want.

2. Diagrams create shared reference points

During interview discussions, ambiguity creeps into verbal references:

• "The ticket object": Which ticket? The class? An instance? A specific attribute?
• "When that method is called": Which method on which class?

With a diagram visible, you can point: "This ParkingTicket class here—I'm adding a calculateFee() method." The interviewer instantly knows exactly what you mean. Pointing at a diagram eliminates entire categories of miscommunication.

3. Diagrams reveal design gaps

Verbal descriptions allow vagueness to hide. You might say "the parking lot tracks availability" without committing to how. But when drawing, you must decide:

• Is there an AvailabilityTracker class?
• Is availability a responsibility of ParkingLot or Floor?
• How is the count updated—push or pull?

The act of drawing forces precision. Many candidates discover design gaps while drawing that they would have missed in pure verbal mode.

4. Diagrams demonstrate systematic thinking

The process of creating a clear diagram demonstrates skills interviewers value:

• Ability to abstract complex systems into visual representations
• Understanding of standard notations (UML or similar)
• Skill in progressive elaboration—starting simple, adding detail
• Professional communication standards

A messy, unclear diagram signals scattered thinking. A clean, well-organized diagram signals an engineer who can communicate technical ideas to stakeholders at all levels.

You don't need to know all of UML—you need to master a focused subset that covers 95% of LLD interview scenarios. Here are the essential elements and when to use each.

Classes: The Building Blocks

A class is represented as a rectangle divided into three compartments:

+------------------+
|    ClassName     |  ← Name (bold, centered)
+------------------+
| - attribute1     |  ← Attributes (fields/properties)
| - attribute2     |
+------------------+
| + method1()      |  ← Methods (operations)
| + method2()      |
+------------------+

Visibility markers:

• + public
• - private
• # protected
• ~ package/internal

In interviews: You often abbreviate. When time is short, just show class names and key methods. Details can be added later or discussed verbally.

Interfaces and Abstract Classes

« interface »       or      « abstract »
+----------------+          +----------------+
|   IPayment     |          |   Vehicle      |
+----------------+          +----------------+
| + process()    |          | # licensePlate |
| + refund()     |          +----------------+
+----------------+          | + getSize()    |
                            +----------------+

Interfaces are shown with «interface» stereotype. Abstract classes use «abstract» or italicized names. In quick sketching, you can simply annotate "(interface)" or "(abstract)" next to the name.

Multiplicity and Cardinality

Numbers at relationship ends indicate how many instances participate:

ParkingLot 1 ◆──────── * Floor     # One lot contains many floors
Floor 1 ◆──────── 0..* ParkingSpot # One floor has zero or more spots  
ParkingSpot 1 ──────── 0..1 Vehicle # One spot has zero or one vehicle

Common multiplicities:

• 1 — exactly one
• 0..1 — zero or one (optional)
• * or 0..* — zero or more
• 1..* — one or more
• n..m — specific range

Different diagram types serve different purposes. Knowing when to use each amplifies your communication effectiveness.

Choosing the right diagram:

In a typical 45-minute LLD interview, you'll likely create one detailed class diagram and optionally one sequence diagram for a complex flow. State diagrams appear less frequently but are valuable for stateful entities like elevators, orders, or payment transactions.

Interview conditions are challenging: whiteboards (physical or virtual), time constraints, nervous hands, and an audience. Here are battle-tested techniques for producing clear diagrams under pressure.

The Progressive Elaboration Approach

Don't try to draw a complete diagram in one pass. Use layers:

Pass 1 — Entity boxes: Draw rectangles with class names. Establish visual anchor points.

Pass 2 — Core relationships: Connect with lines. Add arrows for inheritance. Add diamonds for composition/aggregation.

Pass 3 — Multiplicity: Add numbers at connection ends where cardinality is important.

Pass 4 — Key methods: Add critical methods only—the ones you'll discuss extensively.

Pass 5 — Attributes: Add attributes only if time permits or if they're central to discussion.

This approach ensures that even if time runs out, you have a coherent partial diagram rather than an incomplete jumble.

Modern interviews increasingly use virtual whiteboards (Miro, Excalidraw, FigJam, etc.) or shared documents. Each medium has distinct characteristics that affect your diagramming strategy.

Virtual Whiteboard Best Practices

1. Master the rectangle and arrow tools. You'll use these 90% of the time for class diagrams. Be able to create them instantly.

2. Use color sparingly but purposefully. Highlight interfaces in one color, core entities in another, patterns in a third. But don't rainbow your diagram—it becomes visual noise.

3. Zoom to direct attention. When discussing a specific part, zoom in. This focuses both parties on the same detail.

4. Use the canvas space. Unlike physical boards, virtual canvases are infinite. Spread out. Use one area for class diagrams, another for sequence diagrams, another for notes.

5. Copy-paste for consistency. If you create a nicely formatted class box, duplicate it for others. Consistent formatting looks professional.

The highest-value use of diagrams isn't documentation—it's collaboration. A diagram becomes a shared thinking space where you and the interviewer jointly explore design options. Here's how to leverage this collaborative potential.

Technique 1: Leave deliberate gaps

Don't finish your diagram completely before discussing. Leave obvious gaps that invite questions:

• Draw a payment processing class without showing its dependencies, then ask: "I'll need to integrate with external payment systems here—should we dive into those interfaces?"
• Show a relationship without multiplicity, then discuss: "How many tickets can a vehicle have at once? That affects this cardinality."

These gaps invite collaboration rather than evaluation. The interviewer becomes a co-designer rather than a judge.

Technique 2: Point and reference constantly

Once your diagram exists, treat it as the primary communication medium:

• "Looking at this relationship here..." [points]
• "If we add a method to this class..." [circles area]
• "The flow goes from here... to here... to here..." [traces path]

Physical pointing (or cursor highlighting in virtual settings) keeps both parties focused on the same element. It eliminates the "which class are you talking about?" confusion.

Technique 3: Annotate during discussion

As you discuss, mark up the diagram:

• Circle areas that need refinement with "TODO" notes
• Cross out alternatives you've rejected (visually shows decision history)
• Add question marks near uncertain elements
• Number flows to show sequence

The diagram becomes a living artifact of your design session, not a static picture.

Technique 4: Invite modification

Explicitly invite the interviewer to interact with your diagram:

• "Does this relationship look right to you?"
• "I could add another class here—would that help clarify things?"
• "Point me to any part that seems unclear."

This transforms the dynamic from "candidate presents, interviewer evaluates" to "colleagues design together."

Avoid these pitfalls that undermine diagram effectiveness:

Diagramming under pressure is a skill developed through deliberate practice. Here are exercises to build fluency:

Effective diagramming transforms LLD interviews from verbal marathons into efficient, collaborative design sessions. Let's consolidate the key insights:

What's Next:

With verbal communication (thinking aloud) and visual communication (diagrams) covered, we'll next address Explaining Trade-offs—the skill of articulating why you chose one approach over alternatives, acknowledging limitations, and demonstrating the nuanced judgment that distinguishes senior engineers.