Figma Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Figma. It is a browser running a 60fps multiplayer design tool, and that shapes everything.

• Built on a custom C++ rendering engine compiled to WebAssembly.
• A multiplayer layer keeps dozens of cursors in sync on the same document.
• That is not normal web work, and the loop reflects it.
• In the room I am not just checking "can you code." I am checking "does this person sweat the details and still ship."

Ship fast, but the pixels had better be right. That tension is the whole personality of the place.

2Getting the call (the part most guides skip)#

Figma gets a lot of inbound, so the front door is slow. Recruiters triage hundreds of applications per req, and a cold one has no advocate.

• The careers portal works, but it is the slow lane.
• A referral is worth far more than a polished PDF dropped into the void.
• If you know anyone there, ask with one honest line on why you fit the specific team.
• Referrals get a human set of eyes fast, often days instead of weeks.

No connection? LinkedIn is better than people expect. Find an engineer on the team you want and send something short and real.

• Not "please refer me."
• Try: "I'm applying for the web platform SWE role, I've built a collaborative editor side project, would you be open to a 10-minute chat about the team?"
• A good number say yes, and some offer the referral themselves.
• The hook is that you did the specific thing the team does, not a generic ask.

Your resume needs quantified bullets. Not "worked on the frontend." Instead:

Cut initial canvas load from 3.1s to 900ms for 50k-node documents by lazy-loading off-screen layers and moving tessellation to a Web Worker.

Why that line works:

• Shows scale (50k nodes).
• A before/after metric (3.1s to 900ms).
• A real technical decision (lazy loading plus a worker).
• An outcome. Write every bullet as action, the technical thing, a number.
• A reviewer spends about eight seconds on the first pass, so the numbers have to jump off the page.

Mirror the job description's words for ATS and the 8-second scan. Name only real work, in their language.

• Web/client roles: TypeScript, React, WebGL/WebGPU, WebAssembly, performance, real-time collaboration, rendering.
• Platform/infra: distributed systems, Postgres, caching, event-driven, multiplayer sync.
• AI roles: LLMs, inference, evals, retrieval.
• Do not invent anything. The first live round will expose a padded resume in two minutes.

3The loop at a glance#

The set flexes by track and level. Not everyone gets the identical rounds.

• Web and client candidates almost always get a real frontend/machine-coding round. You build something that runs in an actual browser, not pseudocode on a whiteboard.
• Senior folks carry more design weight. An E5 or E6 might get two design-flavored rounds and one pure algorithms round.
• New grads get more pure algorithms plus fundamentals.
• The onsite is usually one virtual day of back-to-back rounds, roughly 4 to 5 hours with short breaks. The debrief where interviewers compare notes happens the same week.

4The coding rounds#

This is the core, so get it right.

Difficulty is solid LeetCode medium, with a hard-flavored twist in one round. Figma is not trying to beat you with an obscure segment-tree monster.

• They reuse patterns that map to real work on a canvas editor.
• The question often has a thin layer of product dressing: nodes, frames, selections, shapes.

Patterns that show up again and again:

• Hash maps and frequency counting. The bread and butter. Know them cold. Expect to pair a map with another structure, for example a map from node id to node plus a traversal.
• Trees and graphs. The Figma document is a tree of layers and frames. Expect traversal (BFS/DFS), finding ancestors, moving/reparenting nodes, detecting a cycle when you reparent, topological ordering. If one theme is worth over-preparing, it is tree and graph manipulation, and reparenting-without-creating-a-cycle is close to a Figma classic.
• Intervals and geometry-lite. Overlapping rectangles, bounding boxes, "which shapes are inside this selection," merging ranges, hit-testing a click against a stack of shapes. Very on-brand for a design tool.
• Two pointers and sliding window. Substring and array problems, longest-window-with-a-constraint shapes.
• Strings and parsing. Tokenizers, expression evaluation, path normalization, parsing a simple serialized node format.
• Design-y coding. Implement an LRU cache, an undo/redo stack, an in-memory layer tree, an event system. Half algorithm, half clean modeling. Undo/redo comes up more here than almost anywhere else, because it is a real problem they live with.
• Matrix / grid traversal. Flood fill, connected components, pathfinding.

Two tests worth memorizing cold:

• Rectangle overlap: two boxes overlap when a.minX < b.maxX && a.maxX > b.minX and the same on Y.
• Undo/redo: two stacks (undo and redo) where each entry is a reversible command, not a full document snapshot.

Heap and binary search round it out. You do not need deep DP mastery. A couple of classic 1D/2D DP problems (coin change, edit distance) is enough insurance.

How to practice: 80 to 120 mediums with intent, not 400 on autopilot.

• After each one, ask "could I explain this out loud and have someone follow?" If not, you are not done.
• Redo the ones you fumbled a week later from scratch.
• Recognition is not the same as being able to produce the solution cold.

The part that actually decides the round. When I run a coding loop I score four things, and most rejections lose points on the non-code ones.

1. Clarify first. Before you write a line, restate the problem and ask about edges. Empty input? Duplicates? Cycles in the graph? Negative coordinates? A million-node tree that blows the recursion stack? This is not stalling. It tells me you will not build the wrong thing on a real team.
2. Communicate while you think. Say the plan before you type. "I'm thinking a hash map from node id to node, then DFS from the root, O(n) time and space. Reasonable?" Four silent minutes of typing is the single most common thing that sinks an otherwise-fine candidate.
3. State complexity, unprompted. Time and space, every time, and know why. If you say O(n log n), be ready for me to ask what the log factor is.
4. Test your own code. Walk a real example through line by line, and pick one that hits an edge, not the happy path. Catch your own bug before I do. That maps directly to whether you would ship a bug to a million users.

5System design and the frontend round#

Two different beasts depending on your track. Most web/client candidates get both a frontend machine-coding round and, at E4 and up, a system design round.

The frontend / machine-coding round. This is where Figma stands out. You often build a working component in a real editor and browser.

• Typical builds: an autocomplete with debouncing, an infinite-scroll list, a small Kanban board with drag-and-drop, a nested comment tree, a simple drawing canvas.
• What I watch: do you structure state sensibly, do you think about re-renders and performance (memoize the right thing, avoid re-rendering 500 rows when one changes), do you handle async and edge cases (loading, empty, error, a request that resolves after a newer one), and is your code something a teammate could read tomorrow.
• Talk through component boundaries and state before you write anything.
• Managing cursor position, selection, or undo state cleanly earns real points, because that is the actual product.
• Accessibility and keyboard handling are a quiet plus. Add a role, handle Escape and arrow keys, and I notice.

The system design round (E4+). Open prompts, usually something that smells like Figma's actual problems.

• "Design a real-time collaborative document editor."
• "Design the multiplayer cursor and presence system."
• "Design a comments/notifications service."
• "Design an image/asset upload pipeline."
• "Design a URL-safe short link or a rate limiter."

Given what Figma is, collaborative editing prompts are the most likely, so be ready on conflict resolution.

• You do not need to implement a CRDT.
• You do need to reason about concurrent edits, ordering, and what the user sees when two people drag the same rectangle at once.

Use a simple framework and narrate it:

1. Requirements. Functional first, then non-functional (scale, latency, consistency). Nail numbers: concurrent editors per doc (say up to 50), edits per second per doc, read vs write ratio, target cursor-update latency (under 100ms feels live). Drive this yourself. A senior candidate scopes the problem instead of waiting for me to feed numbers.
2. API. The handful of endpoints or socket messages. For real-time, define message shapes, for example op {docId, clientId, seq, payload} and a presence cursor {userId, x, y}.
3. Data model. What you store and where. For a doc editor: the operation log, periodic snapshots, the document tree, and who has which doc open.
4. High-level diagram. Client, WebSocket gateway, the collaboration/sync service, storage, cache. Draw the happy path first.
5. Deep dive. Pick the hard part. For collaborative editing: how concurrent ops converge, how you handle a client that went offline for a minute and reconnects with queued ops, how you compact the op log with snapshots so it does not grow forever.
6. Scale and failure. Shard by document so one doc lives on one sync process, replicate, cache presence in memory. When the sync server dies mid-session, clients hold unacked ops locally and replay them on reconnect against the latest snapshot, so nobody loses edits.

Here is the shape of that collaborative-editor answer:

What separates a pass from a strong pass is tradeoffs. Do not just name a technology.

• Weak: "I'll use CRDTs."
• Strong: "I'll use a CRDT here because clients can go offline and I want them to converge without a central authority. The cost is larger metadata per object and trickier garbage collection, which I'd manage with periodic compaction."
• That sentence is the whole round. The strong version defends each choice and names what it gives up.

Be solid on fundamentals across all levels. They come up as quick probes inside other rounds.

• How a hash map resizes and why average lookup is O(1).
• Process vs thread.
• What a database index does to a query (turns a table scan into a B-tree lookup, at the cost of slower writes).
• TCP vs UDP and why WebSockets sit on TCP.
• The browser event loop, repaint vs reflow, eventual vs strong consistency.
• For web roles: how the event loop, microtasks (promises), and rendering interact, and why a long synchronous task drops frames. Not optional at a company whose product lives or dies on frame rate.

6Behavioral and culture fit#

People underprepare this round and it quietly fails them. Figma weights it seriously, and a weak behavioral can sink a loop where the coding was fine.

Figma's values run along a few clear themes:

• "Play": take the work seriously without taking yourself too seriously.
• "Grow as you go": learn in the open, be comfortable not knowing.
• "Love your craft": care about quality and the details.
• "Hold it loosely": be flexible and low-ego about your own ideas.
• A strong bias toward doing the right thing for the user.

What I listen for in the room. The tone is collaborative, curious, and allergic to ego.

• Do you take real ownership.
• Can you disagree and then commit.
• Did you actually drive something or just ride along.
• Do you talk about teammates generously.
• Do you light up about the craft of what you built.
• If you describe a win and never mention a single teammate by name, that reads as someone who will not share credit.

Prepare 6 to 8 STAR stories. A conflict, a failure you owned, a project you led, a time you influenced without authority, a time you obsessed over quality, a tight deadline where you cut the right corner.

• Reuse them across questions.
• Keep each to about two minutes spoken.
• Land the result and its number last so it sticks.

One full worked STAR:

Situation: Our editor dropped frames badly whenever a document hit a few thousand elements, and users on older laptops were filing complaints weekly. Task: I picked up the performance work for the quarter and owned getting us back to a smooth 60fps on large files. Action: I profiled first instead of guessing, and found we were re-rendering the entire scene on every tiny change. Some folks wanted to throw more caching at it. I pushed back gently and argued we should fix the root cause: dirty-rectangle rendering so we only repaint what changed. I wrote a short proposal, got two senior engineers to poke holes in it, and shipped it behind a flag with before/after frame-time metrics. Result: Median frame time on large documents dropped from about 28ms to 11ms, we held 60fps on the test laptops, and the weekly performance complaints basically stopped.

Why that shape works:

• I own it with "I."
• I name a disagreement and handle it without being a jerk ("pushed back gently").
• I show the low-ego move of inviting two seniors to break my plan.
• The result has a number.
• If your story has no number and no moment of tension, pick a different story.

7Your prep plan#

4-week plan

• Week 1: 25 mediums across arrays, hash maps, two pointers, strings. Relearn Big-O out loud so you can state complexity without thinking.
• Week 2: Trees, graphs, heaps, intervals, basic geometry (rectangle overlap, bounding boxes). 25 more mediums. Start narrating your plan before coding, every single problem.
• Week 3: Design-y coding (LRU, undo/redo, in-memory layer tree) plus the frontend round: build 4 small components in a real browser. Begin system design, one full design a day written out with a diagram.
• Week 4: Mock interviews with a human, ideally one who will interrupt you. Write your 6 to 8 STAR stories. Review fundamentals. Redo problems you failed cold.

2-week plan

• Days 1 to 5: 8 mediums a day, weighted to trees, graphs, intervals, strings. Always narrate.
• Days 6 to 9: 4 frontend components in a browser + 3 system design prompts (collaborative editor, presence, notifications).
• Days 10 to 12: Write and rehearse STAR stories out loud. Fundamentals pass, especially the browser event loop and rendering.
• Days 13 to 14: Two full mock loops. Fix weak spots.

2-day crash plan

• Day 1: 15 mediums covering hash maps, tree/graph traversal, intervals, string parsing. Review complexity for each.
• Day 1 evening: Build one small interactive component (autocomplete with debounce, or a todo with drag) in a real browser. Write 4 STAR stories with numbers.
• Day 2 morning: One system design walkthrough out loud (collaborative editor), one undo/redo implementation with two stacks.
• Day 2 afternoon: Redo 5 problems you fumbled. Practice clarifying out loud. Sleep, because a tired brain goes silent, and silent is the failure mode here.

8Why people get rejected at Figma#

1. Coding in silence. The most common reason by far. Great code, zero narration, mediocre score, because I grade the thinking I can hear.
2. Jumping to code without clarifying. You solve a problem that was not asked, or miss an edge I clearly hinted at, like a cycle in the reparenting graph.
3. A frontend round that works but is a mess. Component glued together, state scattered, every keystroke re-renders the whole list, no thought to edge states. Figma cares about craft, and this round is where craft shows or hides.
4. No tradeoffs in system design. You draw boxes and name technologies but cannot say why one over another, or what breaks under concurrent edits.
5. Behavioral answers with no ownership. Everything is "we," no clear "I," or you blame a teammate. Reads as high-ego and low-trust, the opposite of "hold it loosely."
6. Not testing your own code. You say "done," I run an example, it breaks on empty input, and you look surprised. Shows you would ship bugs.

9The offer, comp and negotiation#

Rough 2026 total comp, cash plus equity plus bonus:

• US, E4/E5: ~$190k to $370k. Base commonly $160k to $215k, the rest RSUs and bonus.
• US, Staff E6: ~$400k to $600k+.
• UK (London): £90k to £160k+ total depending on level.
• India: ₹35L to ₹80L+ total at mid-level, higher for senior. Figma's India presence is newer and smaller, so ranges move around and a given band can swing more than in the US.
• Canada: where hiring happens, expect roughly 70 to 80% of the US dollar numbers, in CAD.

Figma equity is real RSUs now that it is public, so you can value the grant at today's share price instead of guessing at a private 409A.

Three tips:

1. Get the level right before you argue numbers. The level sets the band, and the bands above overlap only at the edges. If you think you are being leveled low, make the case with scope and impact from your STAR stories: team size you influenced, systems you owned, decisions that were yours.
2. Negotiate equity and sign-on, not just base. A big chunk of the package is RSUs. Recruiters usually have more room on the equity grant and signing bonus than on base, since base is boxed in tighter by the band.
3. Use competing offers honestly and be concrete. "I have an offer at X total with Y equity" moves things. "I could get more elsewhere" does not. Stay warm. The recruiter is your advocate inside the committee, not your opponent, and they relay your case to the people who actually set the number.

10FAQ#

Want this turned into a dated, day-by-day plan around your actual interview date? Map your weeks backward from the onsite and start with the pattern you are weakest at.