What to Expect in the Figma System Design Interview

Figma's system design interview covers the classic material (pub/sub, caching, rate limiting, sharded databases) with a company-shaped tilt: real-time collaboration. Figma's core product is a multiplayer editor whose synchronization engineering famously beat better-resourced competitors, and its design questions lean toward the problems that engineering implies: scaling WebSocket connections, routing clients with connection affinity, recovering state after disconnects, and fanning out updates with low latency. Senior candidates often get two design conversations in the onsite, one of which usually carries this real-time flavor.

The evaluation style matches the rest of Figma's loop: collaborative and product-aware. Interviewers expect you to ask what the user experience requires before architecting, engage with hints as a teammate, and connect technical choices to what users feel (latency you can see, edits that vanish, cursors that jump).

Commonly Reported Questions and Themes

• Design a real-time collaborative editing service. The signature theme, in various guises: a shared document, a whiteboard, a multiplayer canvas. Probes: how edits merge, what happens on conflict, and how a late-joining client catches up.
• Design presence and cursors. Show who is in the file and where they are pointing, for thousands of concurrent files: high-frequency ephemeral updates, where durability does not matter but latency does.
• Scale a WebSocket layer. Millions of concurrent connections: connection-affinity routing (a client must reach the server holding its session state), load balancing long-lived connections, draining servers during deploys, and reconnect storms after a network blip.
• State recovery on disconnect. A client drops for ten seconds or ten hours: snapshots versus operation logs, catch-up strategies, and when you give up and send the whole document.
• Classic infrastructure with product context. Rate limiters, notification fan-out, file version history, and comment systems, usually framed inside a Figma-like product.

What Interviewers Are Probing

1. Requirements through the user's eyes. The right opening questions are experience questions: how fast must a collaborator's edit appear (about 100 milliseconds before it feels laggy), what happens to unsent edits when a laptop lid closes, how many people share a document in practice. Deriving the technical targets from felt experience is the Figma-native move.
2. Conflict resolution literacy, not a CRDT lecture. You do not need to derive CRDTs on a whiteboard. You do need the practical landscape: last-writer-wins per property (Figma's actual approach for most document state) versus operational transforms versus CRDTs, and the honest tradeoff: simpler merge semantics that occasionally lose a concurrent edit versus heavy machinery that never does. Knowing why "per-property last-writer-wins with a server as the ordering authority" is often enough demonstrates more understanding than name-dropping the fancier options.
3. The stateful-connection problem. Real-time systems break the stateless-web playbook. Interviewers watch whether you handle it: sessions pinned to servers, what happens when that server dies (state handoff or client-driven recovery), and how you deploy without dropping everyone.
4. Fan-out mechanics. One edit, thirty subscribers, sixty times a second: batching and coalescing updates, per-client send queues with backpressure, and cutting update frequency for background tabs.
5. Degradation as product design. When the sync service struggles, what does the user see: read-only mode, local-only edits with later sync, or an honest offline banner? Designing the failure experience, not just the failure handling, earns Figma-specific credit.

Walkthrough Sketch: Multiplayer Document Sync

Scope it: documents with up to, say, 50 concurrent editors, sub-150-millisecond edit propagation, editors may disconnect and return, and history must be recoverable. Client model: each client keeps a local copy, applies its own edits optimistically (typing must never wait on the network), and sends operations to the server. Server model: one authoritative session per active document (single writer, which kills most coordination complexity), pinned via connection-affinity routing; the session orders operations, resolves conflicts per property with last-writer-wins, broadcasts accepted operations to subscribers, and appends to an operation log. Snapshots every N operations bound recovery time; a returning client sends its last-seen sequence number and receives either the delta or, past a threshold, the latest snapshot.

Failure paths: the session server dies, and clients reconnect through the router to a new server, which rebuilds from snapshot plus log; unacknowledged client edits are resent (operations carry client IDs and sequence numbers, so replay is idempotent). Reconnect storms after a network event get jittered backoff and connection-rate limiting so the fleet does not fall over twice. Presence and cursors ride a separate, cheaper channel with no durability, coalesced to 30 updates per second, because losing a cursor position costs nothing and this separation keeps the critical path lean. Close with what you monitor: end-to-end edit latency percentiles, catch-up durations, conflict rates, and concurrent connections per server.

How to Prepare

• Foundations and method: Grokking the System Design Interview and Grokking System Design Fundamentals cover the base; Grokking the System Design Interview II reaches the replication, consistency, and recovery depth that the multiplayer follow-ups touch.
• Study the real-time canon. WebSocket scaling patterns, presence systems, and collaborative editing approaches (last-writer-wins, OT, CRDTs at practical depth). Figma's own engineering blog post on how multiplayer works is the single best hour of Figma-specific preparation.
• Practice the disconnect drill. For any real-time design you practice, rehearse the three ugly cases: server dies mid-session, client offline for an hour, and a thousand clients reconnect at once.
• Anchor in user experience. Practice opening every design with felt requirements (what latency is visible, what loss is acceptable) before drawing anything. It is both good design and the register Figma grades for.

For the full loop, see What is the Figma interview process like?, prepare the collaboration rounds with Top Figma behavioral interview questions, and have your answer to "Why Figma?" ready before the recruiter call.