Figma Coding Interview Questions

Open a Figma file and you are looking at a tree of objects on an infinite canvas, edited live by everyone else in the room, with their cursors moving in real time. The coding loop borrows that world for its problems. The algorithms underneath are the standard medium set every product company tests, but they arrive in a different vocabulary. A layer tree replaces a generic n-ary tree, and canvas coordinates replace an anonymous grid. A styled-text range stands in for a bare interval, and a command history for two abstract stacks. Your job is to hear the plain structure through the editor noun.

The rounds run on CoderPad, live and executable, so your code has to actually run and pass its cases. A phone screen carries one coding round of about sixty minutes; the onsite adds one, and for some roles and higher levels a second. Difficulty sits at LeetCode medium, occasionally medium-hard, on the order of a Google L4 or L5 bar. TypeScript is the common language and reads as fluency for frontend work, Python is welcome, and Rust or C++ show up for rendering and infrastructure candidates. This lesson maps the recurring surface onto five coding lessons and names the handful of things that make the loop specifically Figma.

The Figma angle

The framing is the signature here, not harder algorithms. Instead of "implement an LRU cache" you get "model a document with layers and properties and add undo and redo." Instead of "sort these points" you get "print the objects on a canvas in reading order, left to right and top to bottom." The data-structure move is the same one you already know; the value is recognizing it fast once it is wrapped in a product context, and modeling the messy state correctly. Because the problems mirror real editor features, product understanding reads as signal. Showing you know why a feature behaves the way it does is a genuine differentiator. Say why a fresh edit has to clear the redo stack, or why the layer tree can never contain a cycle. If the base patterns feel shaky, the free Foundations course drills each one from the ground up so these lessons can stay on what makes Figma Figma.

What the coding rounds actually test

The recurring problems draw from the design-editor domain, and the same building blocks come back. Nested groups and frames are a layer tree, so tree traversal, a Premium question, path-to-root, and permission propagation all live there. Objects with coordinates and sizes turn geometry and sorting into a canvas problem. A Premium question are intervals with a payload to merge, split, and normalize. Components and their instances form a graph with cycles to detect, and undo and redo are two stacks plus inverse operations. The algorithms are ordinary; correct state modeling under a live follow-up is where the difficulty sits.

The Figma angle

The document-with-layers problem that pairs undo and redo is the one to expect, and it comes straight from the product. You model a scene tree of objects, each with a stable id and a bag of properties, then implement apply(op) to mutate a property, undo() to revert it, and redo() to reapply it. The invariant worth stating before anyone asks: a fresh apply() clears the redo stack, because a new edit invalidates the branch you undid past. That history model is not academic. It mirrors how the real multiplayer editor keeps state. A central server assigns the order of concurrent edits and resolves collisions one property at a time by last writer, not the peer-to-peer conflict-free structure many candidates reach for. The hard extension is a Premium question: a beginBatch/commitBatch pair collapses many operations into one atomic history entry, so a single undo reverts the whole group. Get the empty-history and unknown-id cases right, and say the invariants out loud.

Where the emphasis sits

The chart below splits the recurring problems across the five families this guide is built around, with restated variants of one problem counted once. Figma doesn't publish these numbers, so read the ordering as relative emphasis, not a rate any single loop will match. The shape is the useful part. Hash-map and data-structure design leads, because the document model is the signature. Intervals carry more weight than usual because interval questions keep surfacing as a Premium question. Dynamic programming is real but light: the myth that Figma never asks it is wrong, but it is rare, and trees, graphs, and design come up far more.

The Figma angle

Passing every test case is necessary, and it is not sufficient. One reported phone screen had a candidate turn every case green, communicate throughout, and still get a no. The round runs closer to pairing than to a silent whiteboard. The interviewer pushes on naming, extracts a helper alongside you, and drops a new edge case or a follow-up in mid-solution, so brittle code that cannot be extended hurts you even when it works. What earns the pass is stating tradeoffs, invariants, and edge cases before you are asked, then taking the nudges gracefully. A candidate who silently lands the optimal answer scores below one who narrates a slower path and treats the interviewer as a thinking partner. Talk through the messy state, name the invariant, then write the obviously-correct version before the clever one.

The frontend and Product Engineer layer

Figma's identity is product craft and a custom rendering engine, and frontend-leaning and Product Engineer loops add a browser-runtime layer on top of the algorithms. It does not replace them. The algorithm families stay, and a build-a-feature or build-a-component task in TypeScript and React joins the mix, graded on state management, correctness, and product-quality detail rather than framework trivia.

The Figma angle

For these roles, real opinions about the rendering layer are part of the grade. Figma paints its canvas with a custom tile-based WebGL engine rather than the DOM. Expect to reason about canvas versus DOM versus WebGL and WebGPU, when the browser reflows versus paints versus composites, IME composition and focus handling, and memory profiling for a long-running single-page app. "React is fast, just memoize it" is treated as a red flag. Reports conflict on whether a given frontend screen is editor-focused TypeScript work or a general algorithm problem. Prepare both: the data-structure spine every candidate gets, plus a build-a-thing task and a genuine point of view on the rendering pipeline. The command-pattern undo you build for the document problem is the same one that anchors a client-side history stack here.

How these lessons are organized

Each lesson below takes one part of the map and works the recurring problems as runnable code, with the Figma framing and the follow-ups the room adds live. Where a lesson rests on a base data-structures idea, the deep walkthrough lives in the free Foundations course so these pages can stay on what is specifically Figma. Start with arrays and strings, the widest warm-up bucket, then move to the design lesson that carries the signature.

Common questions