How Figma interviews — Question to Offer

1. The shape of a Figma loop

Figma runs a small, design-led engineering organization. The loop is shorter than the FAANG average — typically four onsite rounds, sometimes five for senior staff. Two are system design, one is coding, one is behavioral with a strong "do you ship things" flavor. The whole loop fits in a day.

The interviewers are mostly product engineers and infrastructure engineers from the multiplayer team. They've been building one of the hardest collaborative-canvas products in the industry for a decade and they grade hard on whether you understand what that means.

The bar runs roughly L4 (early senior) at the bottom of the IC ladder to L6 (staff) at the top. They don't have a sprawling level system. The interviewers are looking for one thing more than anything else: do you think about multiplayer from the first sentence, or do you bolt it on at the end?

2. What Figma grades you on

The defining cultural rule inside Figma engineering is "make collaboration feel like there's no server." Every design round is graded against that rule, even when it's not explicitly the topic.

If the question is "design comments on a canvas," they want to hear how comments work when two people add them at the same time, what happens to a comment when the element it's anchored to gets moved, and how the comment surfaces in the other user's session within a few hundred milliseconds. If you spend twenty minutes on the comment-thread data model and then say "and we'd add real-time sync later," you've already lost.

The four signals they grade:

Multiplayer-first thinking. You bring up concurrent edits, presence, and conflict resolution in the first five minutes. If you wait for the prompt, you score lower.
Primitive fluency. CRDTs, version vectors, tombstones, WebSocket fan-out. These are everyday vocabulary at Figma. Know them by name and use them correctly.
Performance as a first-class constraint. The Figma canvas runs at 60fps with thousands of objects. Network and CPU budgets are real. "We'd cache it" is not an answer; you need a number.
Honesty about tradeoffs. Figma engineers are skeptical of clean answers. If you say "CRDTs are obviously the right choice," they'll push you on the memory cost. Have the inversion case ready.

3. What's different here

Multiplayer is the default constraint. At Google, the default constraint is scale. At Figma, the default constraint is what happens when two users do this at the same time. If your design doesn't answer that question by minute ten, the interviewer will ask, and you'll have already lost depth points.
The canvas changes the data shape. Figma is not a doc, not a feed, not a chat. It's a tree of vector objects with positions, parent-child relationships, and shared component references. Reaching for "store it in Postgres" without thinking about how the tree mutates is a junior tell.
The infrastructure is mostly custom. Figma built its own multiplayer server, its own CRDT, its own renderer. The interviewers expect you to be comfortable proposing custom systems when the off-the-shelf primitives don't fit. "We'd use Firebase" is not a strong answer here.
Performance budgets matter to second decimal places. The interviewer may ask "what's the per-cursor bandwidth at 60Hz?" Have a number. The Figma multiplayer team obsesses over kilobytes per session.
The interviewer will share the screen with code. In the coding round and sometimes in system design, they'll have you sketch real TypeScript or pseudocode. Be ready to write a function, not just talk about it.

4. The level bar

How the bar shifts:

L4 (entry senior) — design a single feature on the canvas with multiplayer awareness. You don't need to invent the CRDT; you do need to know it's there. Scope clean, one deep dive, name one tradeoff.
L5 (senior) — design a multi-system feature like comments or version history. You need to understand how multiplayer interacts with your subsystem (comments on a moving element, versions during active editing). Two deep dives, both with inversion cases.
L6 (staff) — design the multiplayer system itself or a system that interacts with it at the protocol level. You're expected to articulate why CRDTs over OT for canvas, the per-cursor bandwidth math, and the recovery model on server crash. Three deep dives, each surviving three pushes.

In this chapter the questions target L5 and L6, with the take-home explicitly at L6.

5. The Figma-flavored mistakes

Watch for:

Treating it like a doc. Figma is a tree of objects, not a stream of text. Reaching for OT (which works for text) on canvas problems is wrong. The right primitive is a CRDT designed for structured data.
Ignoring the local renderer. The Figma client does most of the work — local CRDT merge, local render at 60fps, local presence display. If your design has the server doing the merge and pushing the rendered state, you don't understand the product.
Underestimating the cursor problem. Live cursors are not a small feature. At a hundred concurrent editors moving their mice, the cursor stream is the dominant bandwidth on the wire. If you don't bring it up, the interviewer will, and they'll push hard.
Overusing "we'd just use Redis." Figma has its own in-memory state on the multiplayer server. Reaching for a generic cache without thinking about whether you actually need one signals shallow thinking.
Forgetting that this is a paid product. Brand fonts, design system libraries, and team plans all carry licensing and access-control constraints. If you propose a flat asset CDN with no per-team isolation, you've missed half the problem.

6. The seven scenarios in this chapter

Each unit dissects one question end to end:

23.1 Multiplayer — CRDT vs OT — the canonical Figma question. Why CRDT wins for the canvas. Often L6.
23.2 File storage and version history — per-file canvas state, auto-saves, named versions, branching. Often L5.
23.3 Comment threading on canvas — comments anchored to moving objects. The orphan problem. Often L5.
23.4 Font and asset delivery — fonts are heavy, brand licenses are restrictive. The CDN and manifest design. Often L5.
23.5 Live cursors and presence — high-frequency multiplayer state. Often L6.
23.6 Components and design systems — instances, overrides, cross-file libraries. The version-and-propagation model. Often L6.
23.7 Take-home — collaborative text editor with CRDT — code take-home. Build a CRDT-backed editor in TypeScript with tests proving convergence.

7. The next page

The first scenario: CRDT vs OT for multiplayer canvas. The question Figma's own engineering team has spent ten years answering, and the one they ask everyone who walks through the door.