Figma System Design Interview Questions

Figma's system design interview questions center on one hard problem: keeping a shared canvas in sync across many live editors. Most loops carry two design rounds, one framed over Figma's component model and one bending toward your track. The prompts that recur are multiplayer editing, live presence and cursors, real-time comments, version history, and the canvas rendering engine.

Figma is a real-time collaborative design tool, so its system design round asks you to reason about the exact problem the product solves. That problem is keeping one document in sync across many people editing at once, fast enough that it feels like everyone is in the same room. Most software loops here carry two design sessions of roughly an hour each, and they are the place a senior verdict is made. The first is framed as a feature over Figma's own component model, and candidates are typically sent a short public guide to Figma components to read beforehand. The second bends toward the work you would actually do, backend distributed systems or frontend client and rendering, so the prompt tracks your specialty. For the other two rounds in the loop, see the Figma coding interview questions and behavioral interview questions sections.

The Figma angle

Treat real-time synchronization, low latency, and concurrency as the primary axis from your first sentence. The failure mode reported again and again is a candidate who reaches for a generic microservices sketch (a load balancer in front of stateless app servers in front of a sharded database). They never engage the thing that makes the problem hard. A strong answer opens on the constraints that are specific to a live canvas. Those are many editors on one file, ephemeral cursor state changing dozens of times a second, and offline edits that have to merge back on reconnect. A per-document coordinator also has to survive a crash. Latency and convergence are not a section near the end. They are the shape of the whole answer.

The round, and the two forms it takes

The format is conversational and, fittingly, often run inside Figma or FigJam rather than a generic whiteboard, so being comfortable diagramming in the product itself helps. One open prompt, a shared canvas, an interviewer who interrupts and hands you a new constraint partway through to watch you adapt. The two design slots differ in what they are testing, and the grid below is their shape. Figma does not publish a question list, so read this as a steer toward where preparation pays off rather than a bank to memorize.

• Round 1: Feature over components. Design a feature that lives inside a Figma file, framed around the Figma component model (Figma equates a component to a class). The reported example is a poll inside a file with many concurrent users, with follow-ups on scaling and storage. Candidates are usually sent a public components guide to read first.
• Round 2: Role-specific. Bends toward your track. Backend is classic distributed systems with a real-time tilt: pub/sub, caching, rate limiting, sharded stores, WebSocket fan-out. Frontend is client architecture and the rendering engine, a genuinely rare form of design round that Figma is one of the few places to run.
• Run inside Figma: Diagram in-product. The design sessions are often conducted in Figma or FigJam rather than a third-party whiteboard. Be ready to lay out boxes and arrows in the product without fighting the tool. A small, real, and easy-to-miss part of the format.
• Graded live: Collaborative narration. How you think with the interviewer is scored, not just the end state. A candidate who narrates a slightly slower path, asks clarifying questions, and treats the interviewer as a thinking partner scores higher than one who reaches the answer in silence. This is a real Figma signal, not generic advice.

The Figma angle

The conflict-resolution model is where credibility is won or lost, and the popular answer is the wrong one. Reach for "just use a CRDT" and the round tightens, because Figma deliberately uses neither operational transforms nor a pure CRDT. Operational transforms were judged too complex for the problem. Pure CRDTs are built for decentralized peers with no coordinator, and Figma has a central server per document that can simply define the order of events, so their overhead buys nothing. What Figma actually keeps is a last-writer-wins register per property, with no timestamp needed because the server orders writes. Arriving at that, and being able to say why the two textbook options were rejected, is the single clearest way to read as someone who has thought about the real system.

Where the prompts cluster

Across candidate reports and role-specific guides, the prompts concentrate in the real-time-collaboration family. The percentages below are relative weightings across the pooled evidence, not measured ask-rates, so treat them as editorial guidance about where the depth is. Every one of these leans on the same substrate, a WebSocket connection layer and a per-document coordinator. So be fluent in the connection layer even when it is not the headline prompt.

What the round rewards, past drawing the right boxes, is three things. First, sync reasoning: can you order concurrent writes, apply a local change optimistically, and reconcile the stream from the server without flicker. Second, conflict resolution stated concretely, at the right atomicity boundary (Figma resolves at the property level, so two people editing one text value do not merge, one full value wins). Third, client performance, because a design tool lives or dies on staying at sixty frames per second while a large document is panned and zoomed. Weak answers stop at availability and throughput. Strong ones name the failure modes a live canvas actually hits: partition recovery, cursor storms, offline merges, and per-document memory bounds.

The Figma angle

The rendering engine is a frontend design round almost no other company runs, and it is a real edge if your track lands there. Figma draws a large vector document at sixty frames per second in the browser by shipping a custom tile-based engine on WebGL, now WebGPU, compiled from C++ to WebAssembly. If your loop is frontend or core-engine, the design prompt can be the client itself. Be ready to say why the browser 2D canvas is immediate-mode and re-uploads geometry every frame, and why a retained-mode engine caches geometry on the GPU instead. Explain how viewport culling and level-of-detail keep only visible tiles at the current zoom on screen, and why a pre-allocated heap matters to dodge garbage-collection pauses inside the frame budget. Most candidates have never prepared a rendering answer, so arriving with real opinions on it stands out.

The reference spine most Figma answers share

The most useful mental template is the split below, because it encodes the insight that separates a senior Figma answer from a generic one: different kinds of data ride different paths with different guarantees. Document edits are durable and ordered. Cursors are ephemeral and lossy. Comments and notifications are relational data surfaced by a live read layer. Draw the whole split before you zoom into any one path.

Read the spine in chips. An editor client holds a socket to the WebSocket gateway, which routes edits to a single per-doc process that orders writes into document state and rebroadcasts them. A separate cursor fan-out carries lossy presence back to clients, and LiveGraph surfaces comments and notifications by tailing Postgres. The instinct to carry from this: name the three regimes early, keep them separate, and never let comments or cursors drift into the document-sync path where they do not belong.

Running a Figma design

Five phases carry any of these prompts without thrashing. First, pin the real-time constraints and the numbers you are designing for. How many concurrent editors share one file, how often does a cursor move, how fresh must a comment feel, and what happens after thirty minutes offline? Nail scale and one or two hard guarantees before you draw. Second, lay out the whole spine, the three data paths above, so the interviewer sees the machine before you zoom in.

Third, commit to a conflict-resolution model and defend it: server-ordered last-writer-wins at the property level, and why not operational transforms or a decentralized CRDT. Fourth, tell the failure story, because it is where seniority is read. What happens when the per-document process crashes (recover from a snapshot plus the operation log), or when five hundred people join one file (per-document memory bounds)? What happens when a deploy reconnects everyone at once (a thundering herd on the gateway), or when two branches touched the same component? Fifth, close on cost and the metrics that decide success, bandwidth per cursor and per-document memory ahead of raw requests per second. Go deep on one stage and keep the rest brisk.

The worked designs

Five designs follow, each mapped to a reported prompt and grounded in a system Figma has actually published. Start with multiplayer editing: it is the flagship, the most-reported prompt, and the one whose architecture the rest of the section builds on.

Each design assumes the fundamentals from the System Design course. Use the scaling playbook for read and write paths, and the toolbox for when to reach for a log, a cache, a queue, or an index. These pages stay on the real-time-collaboration shapes Figma actually tests and leave the general mechanics to those.

Common questions