How the interviewer opens it
“Design a shared whiteboard where people draw, move objects, and add notes together. Users must see changes quickly and continue after a connection loss.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Scale
- Edit traffic
- Read and write mix
- Board size and history
- Latency
- Concurrent edits
- Disconnections
- Durability and availability
- Supported content
- Deployment
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Create and open a shared board
- Draw strokes, move objects, and edit plain-text notes
- Show edits to other users with low latency
- Restore the board and preserve local edits after a disconnect
Usually out of scope
- Edit note text character by character
- Upload images or video
- Manage accounts and permissions
- Replay the full board history
- Serve users from multiple regions
What interviewers ask about
- Concurrent changes
- Users can change the same object before they see each other's edits. Every client must resolve those changes consistently.
- Disconnections and return
- A returning client has old board state and local edits. It may also retry edits that the server already accepted.
- Saved edits and server failures
- A fast reply can hide an edit that exists only in memory. Failover can also let two servers accept incompatible histories.
- Large busy boards
- A single busy board can produce far more deliveries than edits. Slow clients and reconnect bursts can exhaust shared resources.
Common mistakes
- The design treats a WebSocket as a guarantee of order across users.
- The client replaces the whole board after each edit.
- The server acknowledges edits before durable storage.
- The design names a CRDT but does not define concurrent move and deletion rules.
- The client discards pending local edits when it loads a snapshot.
- The design ignores the delivery cost of one busy board.
The bar by level
- Senior (L5/E5)
- Define rules for moves, note text, and deletion. Explain durable acknowledgment, retries, snapshot boundaries, and replay without gaps. Prevent slow clients from delaying a board.
- Staff (L6+/E6+)
- Prove that writer failover cannot accept conflicting histories. Bound retained history and retry state without losing supported offline work. Quantify busy-board costs and justify the conflict model.