The whiteboard design round: how to talk through it

Part of the free Low-Level Design course on LogicWiz, in the chapter: The machine-coding round and the design discussion. The class-diagram exercises run in the app.

The whiteboard design round: how to talk through it

"I can see your boxes. I cannot hear your reasons."

Priya, after Arjun's silent mock design round

A clean diagram and a silent candidate

Priya's second mock was a design discussion: a round with no running program. You draw classes on a whiteboard or a shared document, and you explain them aloud.

The problem was SwiftKart coupons. Arjun drew for eight minutes without a word. The diagram was good: a Cart, a Coupon and two types of coupon. When he put the pen down, Priya asked, "Why two classes for coupons?" He froze. He knew the answer. He had never said it.

"The diagram is my answer," he said. "She can read it."

She can read the boxes. She cannot read your reasons, and the reasons are what she scores. In this round, talking is graded as much as drawing. Interviewers usually listen for three things:

• Communication. Can they follow your thinking? Do you state assumptions and check them?
• Trade-offs. A trade-off is a choice where you gain one thing and give up another. Do you name what each choice costs?
• Extensibility. When they change a requirement, do you say where it lands and what stays untouched?

A silent candidate shows none of the three, even with a perfect diagram.

Five phases, with a clock

Most design rounds run 45 minutes. For 60, add the extra time to the diagram and the extension.

Say a short opener when you enter a phase and a closer when you leave it. Learn these scripts until they are automatic, so your mind is free for the design.

• Clarify. Opener: "Before I draw, I will ask about scope." Closer: "So A and B are in, and C is out. Tell me if that is wrong."
• Entities. Opener: "I will list the nouns and decide which become classes." Closer: "These four are classes. The rest are fields."
• Class diagram. Opener: "I will start with the central class and add outward." Closer: "That is the structure. Please challenge the coupon hierarchy."
• Key method. Opener: "I will write the method that carries the main rule." Closer: "It covers the normal case and two errors. I would test the expired coupon first."
• Extend and trade-offs. Opener: "Give me a change, and I will say where it lands." Closer: "This design extends easily at X and costs us Y. If Z changed, I would revisit it."

Three sentence shapes carry most of the marks: "I choose X because Y." "The cost is Z." "I assume W, tell me if that is wrong."

Draw fast and keep it readable

A whiteboard is small, and you will redraw. These habits keep it clear.

• A box holds a name and two or three members. Write only what carries the design.
• Start at the centre. Draw the class the problem is about, such as Cart. Add one neighbour at a time, so you do not run out of room.
• Leave a gap beside each interface. The interviewer will ask for a new class in phase 5.
• Label every line with a verb or a count: "holds 0..1", "contains 1..*". An unlabelled arrow makes the interviewer ask what it means.

You need three relationships most of the time:

1. Association, a plain arrow: one class keeps another in a field. Cart holds a Coupon.
2. Extends or implements, a hollow triangle at the parent: FlatCoupon is a kind of Coupon. Use a dashed line for an interface.
3. Composition, a filled diamond at the whole: a Cart owns its CartItem lines, and they end with it.

For anything else, draw a plain arrow and say the word aloud: "this is a dependency, it only uses the date for one call."

classDiagram
  class Cart {
    -items
    +total() int
  }
  class Coupon {
    <<abstract>>
    +discount(subtotal) int
  }
  Cart "1" --> "0..1" Coupon : holds
  Cart "1" *-- "1..*" CartItem : contains
  Coupon <|-- FlatCoupon
  Coupon <|-- PercentCoupon

In phase 4, write the one method that carries the main rule: the signature, the loop and the edge cases. Then stop.

public int total(LocalDate today) {
    int subtotal = 0;
    for (CartItem item : items) {
        subtotal += item.price() * item.quantity();
    }
    if (coupon == null || !coupon.isValidOn(today)) {
        return subtotal;
    }
    return Math.max(0, subtotal - coupon.discount(subtotal));
}

While writing, Arjun said: "I skip null checks on the list. I handle no coupon and an expired coupon. The Math.max stops a negative total."

When the interviewer pushes back

Interviewers push on purpose. Arjun's old reaction was to defend. Priya gave him four steps for "why not X?":

1. Agree with what is true. "Yes, X is simpler."
2. Say what X costs here. "But with X, each new coupon type edits one method."
3. Decide, with a condition. "I keep the classes, because I expect more types. With two forever, I would use X."
4. Invite them. "Does that match your picture?"

Defending says "I am right". This says "I weighed it", and that is the signal. If the challenge is right, change your answer and say why.

A requirement change, such as "now add free-delivery coupons", needs three sentences: where it lands, what changes, and what stays. If it shows a real flaw, say so: "My discount method sees only the subtotal, so it cannot see delivery. I would pass the whole order."

Everyone takes a wrong turn: a field in the wrong class, an arrow in the wrong direction. Repair it in thirty seconds. Name it: "I put expiry in each coupon type, and that repeats." Fix it on the board. State the lesson: "Shared data goes in the parent." Do not erase in silence, and do not apologise at length. Interviewers expect errors. They score how you repair them.

💡 Tip: When you are stuck, say what you are stuck on: "I am choosing between a list and a map here." Interviewers often give a hint.

A mock round, annotated

Here are ten exchanges from a mock round on the coupon problem. Each note says what the answer shows.

1. Interviewer: "Design SwiftKart's coupons." Candidate: "Three questions first. Can an order use two coupons? Are there only flat and percent coupons? Do they expire?" Shows: questions that can change the design.
2. Interviewer: "One coupon per order. Flat and percent now, more later. Yes, expiry." Candidate: "So in scope: cart, coupon types, expiry. Out: limits per user. Tell me if that is wrong." Shows: a stated scope, with an exclusion the interviewer can correct.
3. Interviewer: "Go ahead." Candidate: "The nouns are cart, item and coupon. Coupons differ in how they discount, so Coupon is abstract, with FlatCoupon and PercentCoupon. Each keeps an expiry date." Shows: entities with a reason, and a named seam.
4. Interviewer: "Why a class per coupon? A type field would do." Candidate: "It would, and it is simpler for two types. But each new type edits one method. I expect more types. With two forever, I would use the field." Shows: agreement, a cost, a condition for switching. No defence.
5. Interviewer: "Show me the total." Candidate: "Items subtotal, minus the coupon's discount, never below zero. An expired coupon is ignored." Shows: one method, edge cases spoken while writing.
6. Interviewer: "Where is expiry checked?" Candidate: "In both coupon classes. That repeats. I will move it into Coupon. Shared data goes in the parent." Shows: a repair in the open: name it, fix it, state the lesson.
7. Interviewer: "Now add free-delivery coupons." Candidate: "One new coupon class. But my discount method sees only the subtotal, so it cannot see delivery. I would pass the whole order." Shows: where the change lands, and an honest flaw.
8. Interviewer: "So your design was wrong." Candidate: "Too narrow, yes. Two classes change, and Cart stays the same. Next time I would pass the order from the start." Shows: the cost, sized correctly.
9. Interviewer: "Two coupons at once?" Candidate: "Cart would hold a list. The real question is order, because 10% then 50 off differs from 50 off then 10%. I would ask the business." Shows: a hidden decision, found and asked about.
10. Interviewer: "Anything you would improve?" Candidate: "A Money type instead of int, limits per user, and a test for the percent cap. Money first, because rounding errors cost real money." Shows: a closer: a ranked list with a reason.

Try it: build the diagram from a spoken prompt

Here is a prompt as an interviewer would say it:

"SwiftKart books delivery slots. A store offers slots, each a one-hour window that takes at most 20 orders. A customer books one slot for an order. A full slot cannot be booked. Gold members may book slots earlier than other customers, and ops will add more booking rules later."

Read it aloud once. Then draw the design below, and say your reasons as you place each class. Two phrases point to the seam: "earlier" and "more rules later".

📌 Summary: A design round grades your talking as much as your drawing. Use five phases with a clock, say reasons and costs aloud, answer "why not X?" without defending, and repair wrong turns openly.

What Arjun learns next

This is the last lesson of the course. Arjun now has the whole path, from requirements to classes, patterns, diagrams, thread safety, the 90-minute plan and the talking.

What he needs now is practice. Pick a problem from the problem library and set a 45-minute timer. Run the five phases and talk aloud, even alone. Then compare the model answer with what you said.

Check your understanding

1. Arjun draws a coupon hierarchy. The interviewer asks, "Why not one Coupon class with a type field?" He thinks the field is also fine. What is the best reply?
2. At minute 20, Arjun sees that he put the expiry date in both coupon subclasses. What is the best recovery?
3. Two candidates design the same system. A draws a perfect diagram in silence. B puts one class in the wrong place but states assumptions, names a cost for each choice, and repairs the error. Who is likely to score higher?
4. The interviewer says "now add free-delivery coupons", but your discount method takes only the subtotal. What is the strongest answer?