Whiteboarding UI Components
How to whiteboard frontend components — API design, state diagrams, layout boxes, and a11y — when code editors are limited.
- interview
- whiteboarding-ui
Not every FE interview lets you type in a full IDE. Whiteboarding (or Excalidraw / Google Doc) tests API design, state thinking, and communication without hiding behind autocomplete.
What interviewers score
- Component API — props that age well
- State model — events and transitions
- Composition — slots vs prop explosion
- Edge cases — empty, overflow, async
- A11y & responsive called out explicitly
30-minute skeleton
| Minutes | Output on board |
|---|---|
| 0–4 | Requirements + MVP checklist |
| 4–10 | Component tree + prop sketches |
| 10–16 | State machine / data flow |
| 16–24 | Key interaction algorithms |
| 24–28 | A11y, layout, failure modes |
| 28–30 | Stretch & tradeoffs |
Pair with Machine coding framework when you do get an editor.
Start with the public API
Write props before internals:
<DateRangePicker
value={{ start, end }} // controlled
onChange(next)
minDate?
maxDate?
isDateDisabled?(date)
timeZone?
/>
Discuss controlled vs uncontrolled — Controlled vs uncontrolled.
Avoid boolean soup: size="sm" over isSmall.
Draw the tree
DateRangePicker
├── InputGroup (start / end fields)
├── Popover
│ └── Calendar
│ ├── MonthHeader
│ └── DayGrid
└── HelperText / Error
Composition patterns: Composition vs inheritance · Children patterns.
State diagram (high leverage)
closed --open--> open
open --select start--> selectingEnd
selectingEnd --select end--> closed (commit)
open --escape--> closed (cancel)
Async example (typeahead):
idle --type--> debounceWait --fetch--> loading
loading --200--> openResults
loading --err--> error
Algorithms to sketch (not perfect code)
| Component | Sketch |
|---|---|
| Autocomplete | debounce → fetch → merge race (ignore stale) |
| Virtual list | scrollTop → startIndex → slice window |
| Infinite scroll | IntersectionObserver → page++ |
| Drag reorder | indices, placeholder, onDrop commit |
| Nested comments | tree flatten / depth indent |
Practice builds: Autocomplete · Infinite scroll · DnD list · Nested comments.
Layout boxes
Draw:
- Flex toolbar vs Grid page
- Overflow scroll region
- Sticky header
- Mobile stacked variant
CSS interviews: CSS interview questions.
Accessibility on a whiteboard
Always list:
- Roles (combobox/listbox/dialog)
- Keyboard map (Tab, Arrows, Enter, Esc)
- Focus move on open/close
- Labels / error association
- Reduced motion if animating
References: Accessible combobox · Accessible modal · Focus management.
Verbal patterns while drawing
- “I’ll lock MVP: single month, no time zones.”
- “Prop
valueis controlled so forms own state.” - “Race: sequence number drops stale responses.”
- “Stretch: range presets, localization.”
Common whiteboard fails
| Fail | Fix |
|---|---|
| Jump into CSS details | API + state first |
| No empty/error | Add to checklist |
| God component | Split list/item/chrome |
| Ignore keyboard | Explicit key map |
| Perfect code handwriting | Pseudocode OK |
Example mini-walkthrough: tabs
- API:
tabs[{id,label,panel}],value,onChange - State: selectedId; optional controlled
- A11y:
tablist/tab/tabpanel, arrows,aria-selected - Lazy panels: mount on first activate
- Stretch: overflow scroll buttons
Learn: Accessible tabs.
Related on this site
- Machine coding framework
- System design FE framework
- React interview questions
- A11y talking points
- Machine coding hub
- Interview hub
Further reading
Whiteboard rounds are design conversations. Draw boxes, name states, and keep inviting the interviewer into choices.