Figma SWE Interview: Onsite Coding Guide

Estimated read time: 7-9 minutes

Summary: Figma onsite coding is a deeper practical implementation round, commonly reported around 45-60 minutes per round. The source supports DSA implementation, practical product coding, frontend state/update work, performance optimization, tests, and edge cases, but exact questions are sparse. Expect interactive coding where collaboration, maintainability, and product constraints matter.

TL;DR + FAQ (read this first)

At-a-glance takeaways

• Onsite coding validates implementation skill across a deeper loop.
• Expect practical tradeoffs, collaboration, edge cases, and test discussion.
• Frontend/product roles may emphasize state updates, UI behavior, and performance.
• Infrastructure or collaboration systems roles may tilt toward data flow and distributed-state thinking.
• The source is partial, so confirm exact role focus with the recruiter.

Quick FAQ

How is this different from the coding screen?
It can go deeper into implementation quality, interaction, and follow-up constraints.

Is this pair programming?
The source supports shared editor/video formats, but exact setup is not verified.

Should I expect UI coding?
Possible for frontend/product roles, but not guaranteed for every SWE loop.

What matters most?
Maintainable code, practical tradeoffs, testing, and collaboration.

---

1) What onsite coding measures

Onsite coding measures whether your implementation choices hold up beyond a simple first pass. The source points to maintainable code, practical tradeoffs, collaboration, edge cases, decomposition, and testing.

At Figma, a practical implementation task may involve product constraints such as document state, collaborative updates, rendering order, or performance. Even if the problem is general, show the interviewer how you reason about future changes.

---

2) What practical implementation depth looks like

A strong solution has clear data structures, small helper functions, named invariants, and tests. If the interviewer changes the requirement, update the design deliberately rather than patching random lines. If performance matters, identify the expensive work and reduce it without making the code unreadable.

Collaborative coding also means making the interviewer part of your process: state assumptions, explain tradeoffs, and invite clarification when the product behavior is ambiguous.

---

3) Questions to practice

These are representative tasks based on source themes, not confirmed verbatim Figma wording.

• Implement a layer tree API with add, remove, move, hide, and list-visible operations. Now handle moving a parent with children.
• Build a command history for editor operations with undo and redo. How do you represent operations cleanly?
• Given collaborative edits to a document, apply operations in timestamp order and detect conflicts.
• Optimize an update function that recalculates too much state after a small change.
• Implement a practical DSA problem, then extend it when the input becomes large or partially invalid.
• Given an existing implementation with poor decomposition, refactor enough to add one new behavior safely.
• Write tests that cover deleted nodes, hidden layers, duplicate ids, invalid moves, and large documents.

---

4) Level-specific expectations

The slug table lists intern through senior as relevant, with Staff+ possible or role-dependent. Figma-specific level labels were not verified.

• Intern and New Grad: show fundamentals, steady implementation, and ability to use feedback.
• Junior and Mid-Level: show decomposition, tests, debugging, and practical product thinking.
• Senior: show abstraction judgment, performance awareness, and product impact.
• Staff+: if included, implementation may support broader domain or architecture discussion.

---

5) Common failure modes

Poor collaboration. Onsite coding is interactive. Explain decisions as you go.

Untested code. Name the cases that prove the behavior works.

Ignoring product constraints. State, performance, and user experience can matter in practical implementation.

Weak decomposition. If adding a follow-up requires rewriting everything, the first design may be too rigid.

Overgeneralizing from sparse reports. Let the actual role guide the depth of frontend, infra, or product focus.

---

6) How to prepare

• Practice product-shaped coding tasks with trees, maps, operations, undo/redo, and state updates.
• Prepare to refactor small code safely under time pressure.
• Add tests after every implementation.
• Practice explaining performance tradeoffs in plain language.
• Clarify team-specific expectations before the onsite.

---