How to Use a Whiteboard in System Design Interviews

You've got forty-five minutes, an empty canvas, and a question broad enough to fill a week. How much of that time should go into drawing, and how much into talking?

The answer is less drawing than most candidates expect. A diagram in a system design interview is a shared reference for a conversation, not a deliverable. Nobody scores your rectangles. What they score is whether the picture let them follow your reasoning, and whether you kept talking while you made it.

Pick a tool and practice in it

Whatever tool you use on interview day should be one your hands already know. Fumbling with a shape menu while the interviewer waits is a self-inflicted wound, and it's entirely avoidable with an hour of practice.

• Excalidraw is our primary recommendation, and it's what we use in Exponent mocks and practice tools. It's free, needs no account, opens instantly in a browser, and its rough hand-drawn style keeps you from fiddling with aesthetics. Learn four keyboard shortcuts for rectangle, ellipse, arrow, and text, and you can draw as fast as you talk.
• Whimsical is worth knowing because some companies name it directly. Stripe's interview guide recommends it for virtual interviews, so if you're interviewing there, practice in it.
• Built-in editors in CodeSignal, CoderPad, and HackerRank show up in remote loops. They're usually more limited than Excalidraw. Ask your recruiter which platform the round uses so there are no surprises.
• A physical whiteboard still appears in onsite loops. The constraints are different enough to practice separately: you can't undo, you can't drag things around, and erasing is expensive.

Leave yourself room

The single most common whiteboard mistake is starting too big in the top-left corner and running out of space exactly when the design gets interesting.

Systems grow rightward and downward as you add caches, queues, replicas, and workers. So start small and start left. Draw your first components at maybe half the size that feels natural, and keep the right two-thirds of the canvas empty. On a physical board, physically stand back for a second before your first stroke and decide where the main flow will live.

Two habits that buy you room:

• Zoom out, don't cram. In a digital tool, zooming out and continuing beats squeezing three boxes into a corner. On a physical board, use the whole surface rather than one quadrant.
• Give deep dives their own space. When the interviewer asks you to go deep on one component, don't annotate the main architecture until it's unreadable. Move to a clear area and draw that piece in detail, keeping the overview intact for reference.

Use consistent shapes

You don't need a formal notation, but using the same shape for the same kind of thing every time means the interviewer stops decoding your diagram and starts following your argument. This is the convention we use throughout this course:

• Rectangles for services, app servers, and workers, meaning anything that executes code.
• Cylinders for anything that stores data: databases, caches, object storage.
• Rounded capsules for queues and message brokers, which reads as "things flow through this."
• Hexagons or a small clock icon for scheduled and timed processes, so a cron-driven component is visually distinct from a request-driven one.
• A cloud or plain circle for external systems you don't control, like a payment provider or the public internet.

Two more conventions that pay for themselves. Label every arrow with what actually flows along it: not just a line from service to queue, but OrderCreated or publish. And distinguish synchronous from asynchronous, with solid arrows for a caller waiting on a response and dashed for fire-and-forget. That one visual difference answers a question interviewers ask constantly.

Writing out a data schema

Schemas get messy fast, and a messy schema is worse than none. Keep them compact and consistent.

For most interviews, a simple list per table is enough. Write the table name, then the fields that matter, marking the key and any index you're relying on:

Order
  id            PK
  user_id       FK, index
  status        enum: pending | paid | cancelled
  created_at    index (user_id, created_at)

Three rules keep this readable under time pressure:

• Only include fields that matter to the design. Nobody needs updated_at on every table. Include the fields you'll actually reference when discussing queries, indexes, or partitioning.
• Mark keys and indexes explicitly. The index is often the point you're making. Writing index (user_id, created_at) next to the table shows you've thought about the query that reads it.
• Draw relationships as arrows between tables, not as a formal ER diagram with crow's feet. An arrow labeled "1:N" carries the same information in a tenth of the time.

If you're partitioning, note the partition key right on the table. One line, partition by: event_id, usually prevents a long back-and-forth later.

Keep talking while you draw

The most common failure isn't a bad diagram. It's silence. Candidates go quiet for ninety seconds while carefully positioning boxes, and the interviewer learns nothing during that time. Worse, a candidate who draws in silence and then presents a finished design has skipped the part interviewers actually score: the reasoning.

The habit to build is say it, then draw it. Announce what you're about to add and why, then add it. "Reads are going to dominate here, so I'm putting a cache in front of the database. I'll come back to invalidation in a minute." Now the drawing takes ten seconds and the interviewer already knows what it means.

This has a second benefit. If your interviewer disagrees with a component, you find out before you've spent two minutes drawing it, rather than after.

A few more speaking habits worth practicing:

• Narrate the flow, don't inventory the parts. Walk the interviewer along a request: "a write comes in here, the service validates it, writes to the primary, and publishes an event that these three consumers pick up." That's more useful than listing every box on the canvas.
• Say when you're deliberately deferring something. "I'm going to draw this as a single database for now and come back to sharding once we've talked about scale" tells the interviewer it's a choice rather than an oversight.
• Check in after the first pass. Once the high-level architecture is on the board, stop and ask: "does this look like the right scope, or would you rather I go deeper on a particular piece?" Interviewers usually have a component they want to probe, and asking gets you there sooner.

Practice before interview day

Draw three architectures from this course end to end, in whichever tool you'll be using, while narrating out loud as if someone were watching. Time yourself. Most people find that the high-level diagram should land in five to eight minutes, leaving the rest of the interview for the deep dives, which is exactly the ratio you want.

If you can, record one and watch it back. The gaps you notice, whether long silences, unlabeled arrows, or a diagram crammed into a corner, are the same ones an interviewer would notice.