Figma SWE Interview: Onsite Coding Guide

Estimated read time: 7-9 minutes

Summary: Figma software engineer (SWE) onsite coding is a deeper practical implementation round, commonly around 45-60 minutes per round. Prepare for data structures and algorithms (DSA) implementation, practical product coding, frontend state/update work, browser or rendering performance, tests, and edge cases. 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, user interface (UI) behavior, complex in-memory models, and performance.
• Infrastructure, artificial intelligence (AI)/platform, or collaboration systems roles may tilt toward data flow, reliability, and distributed-state thinking.
• The format can vary, so confirm 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?
Prepare for shared editor/video formats, and confirm setup with your recruiter.

Should I expect user interface (UI) coding?
Frontend and product roles are the safest places to prepare for UI work. Ask the recruiter whether it applies to your 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. Prepare to show maintainable code, practical tradeoffs, collaboration, edge cases, decomposition, and testing.

At Figma, a practical implementation task may involve product constraints such as in-memory document state, collaborative updates, rendering order, media handling, 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) Practice themes

Use these themes to build Figma-relevant coding fluency and adapt to the role focus your recruiter confirms.

• SceneGraph-style layer operations: practice add, remove, move, hide, traversal, and invalid-parent cases.
• Command history: practice undo, redo, operation representation, and clean state transitions.
• Collaborative edits: practice ordering, deduplication, conflicts, and invalid references.
• Performance optimization: practice reducing unnecessary recalculation, rendering work, or media processing after small updates.
• Core DSA: practice extending a first solution when input grows or becomes partially invalid.
• Refactoring: practice improving decomposition enough to add one new behavior safely.
• Testing: cover deleted nodes, hidden layers, duplicate ids, invalid moves, and large documents.

---

4) Level-specific expectations

Treat intern through senior as relevant, with staff-level expectations depending on role scope. Ask your recruiter how Figma maps level for your opening.

• 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 one role path. Let the actual role guide the depth of frontend, infrastructure, or product focus.

---

6) How to prepare

• Practice product-shaped coding tasks with trees, maps, operations, undo/redo, state updates, and rendering or media constraints.
• 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.

---