Figma interview, decoded.

Three to five weeks is the usual span, and candidate accounts agree on the sequence even where they differ on which onsite rounds appear for which track. Recruiter screen: Background, why Figma, and whether you use the product. Accounts agree that a candidate who has never used Figma seriously struggles later, because the product-sense round will find it. Hiring manager call: How you make decisions: trade-offs on past projects, how you work with designers, and what you would build first in the role. Short stories with the scope, your part and the outcome in numbers. Technical phone screen: One problem, usually medium to hard, in TypeScript, Python or Rust depending on the role, and often with an applied twist: a cache with specific eviction rules, a structured event stream to parse, a small state machine. Say the approach out loud and name the edge cases before you are asked. Take-home: Reported as variations on building a small collaborative editor or implementing undo and redo over a data model. What sinks people is polishing style while leaving the real cases unhandled: concurrent edits, a disconnect, an undo that crosses a sync. Write the notes as if a reviewer will read every line, because they do. Coding, onsite: One conventional data-structures problem and one applied one: a piece of a text editor, a selection system, an event dispatch mechanism, a command-pattern undo. Interviewers collaborate, push on naming and ask for another edge case live. System design, onsite: The multiplayer round, and for backend tracks a distributed-systems round with a real-time tilt: live cursors, conflict resolution for simultaneous edits, presence for a large concurrent population, WebSocket scaling, what happens when a client reconnects after an hour offline. The section below covers what a strong answer holds. Frontend deep dive: Browser rendering and the mental model behind it: what forces a synchronous layout, which properties stay on the compositor, canvas against DOM against WebGL and the failure mode that decides between them, bundle splitting with the metric you are cutting, and finding a leak in a long-running application with heap snapshots. Craft and product sense: You are shown a part of the product and asked what you would change. Have opinions about five features, and know why this product won multiplayer design while others did not. Behavioural and project deep dive: Design and engineering partnership, ambiguity, performance work with before and after numbers, and one project you can defend until the follow-ups run out.

Figma's engineering culture is unusually tied to its design culture, and the loop keeps checking for the same handful of things. Treating design as a partner rather than a ticket queue, with a story where you pushed back for an engineering reason and the outcome improved Genuine use of the product, which the craft round exposes in about a minute Depth on rendering and real-time systems rather than framework familiarity Measured performance work: the profile, the fix, the before and after Shipping under an unclear spec by narrowing scope and validating a small reversible bet Clear communication to people outside your team, since most interviewers will not be from the team you join

The behavioural questions below are the ones candidates report most; the technical themes are the ground the coding, design and frontend rounds cover. Why Figma, and what would you change about the product? Tell me about working with a designer on a hard problem, and a time you pushed back. Describe something you made measurably faster, with the numbers before and after. How do you ship when the spec is not clear yet? When do you pay down technical debt, and when did you decide not to? Applied data structures State machines Multiplayer sync Rendering Measurement

The prompt arrives in one of a few shapes: design the backend for live cursors, design conflict resolution for simultaneous edits, design presence for a very large number of concurrent users. Most candidates answer with the word CRDT and a generic pub/sub diagram, and the interviewer pushes until something specific arrives. The thing worth knowing is that Figma published how its own system works, and the post says plainly that Figma is not using true CRDTs: it is a centralized client-server system inspired by them. Being able to explain why a central server lets you delete most of the machinery is a better answer than naming three algorithms. The points below are from that post. Why not operational transforms, and why not a real CRDT: Operational transforms define operations by their offsets in text and, in the post's judgement, are powerful, complicated and hard to implement correctly, which is overkill for a tool that is not a text editor. True CRDTs are built for decentralized systems with no central authority and carry performance and memory overhead to get there. Figma's server is that authority, so the system keeps the ideas and drops the cost. Say that trade-off out loud and the round changes character. The document as a two-level map: Every document is a tree of objects, each with an ID and properties: think of it as a map from object ID to a map from property to value, or a table of object, property and value rows. The server keeps the latest value any client sent for a given property on a given object, so two clients editing different properties of the same object never conflict, and the conflict case is the same property on the same object, where the last value to reach the server wins. That is a last-writer-wins register without needing a timestamp, because the server defines the order. Why simultaneous text editing does not merge: Changes are atomic at the property boundary, so the eventual value of a property is always one client's value. If one person changes B to AB while another changes it to BC, the result is AB or BC and never ABC. This is a deliberate choice for a design tool rather than a limitation to apologise for, and saying so shows you understand where the system's line is drawn. Flicker, and why the client discards some server updates: The client applies local changes immediately so the tool feels instant, but then an older acknowledged value arriving from the server can briefly overwrite a newer unacknowledged local one, which shows as flicker. The fix is to discard incoming changes that conflict with unacknowledged local ones, because the local change is the best prediction of the eventually consistent value. Interviewers press on this class of problem: what the user sees while the system converges. Trees, reparenting and cycles: The parent link is stored as a property on the child, so identity survives a move and an object cannot end up with two parents. That leaves the graph free to form a cycle when two clients each make the other's object their parent; the server rejects any parent update that would create one, and the client, which cannot reject the server, temporarily removes the pair from the tree until the rejection arrives. Ordering among children uses fractional indexing, a position between zero and one where inserting between two objects means averaging their positions, and the parent link and position are stored as one property so they update together. Undo in a multiplayer document: Single-player undo means put back what I did, which in a shared document can overwrite what somebody else did afterwards. The principle Figma settled on is that undoing a lot, copying something and redoing back to the present should leave the document unchanged, which is why an undo modifies the redo history at the time of the undo and a redo modifies the undo history at the time of the redo. A candidate who raises this unprompted is answering a question most people do not know is there. Offline, reconnection and deletion: A client may be offline for an arbitrary time; on return it downloads a fresh copy, reapplies its offline edits on top and resumes syncing, which keeps reconnection simple and puts the complexity in live updates. Deleting an object removes its properties from the server entirely, with the data kept in the deleting client's undo buffer, so documents do not grow forever. Clients generate their own object IDs with a client ID baked in, because creation has to work offline.

Read Figma's own post on how its multiplayer technology works, and be able to say why the system is inspired by CRDTs rather than being one. Build a small collaborative editor once, a few hundred lines, so the vocabulary is something you have used rather than something you have read. Use the product seriously before the loop, including dev mode, prototyping and variables, and have opinions about five features you would change. Practise the applied coding shapes in TypeScript: a text buffer, an interval structure for selection, an undo stack with explicit transitions, a structured event stream. For a frontend role, be able to name what forces a synchronous layout, which properties stay on the compositor, and how you found a leak in a long-running application. Bring one performance story with a profile, a fix and numbers on both sides, and expect to be asked how you measured it.