Layer Trees & Graph Templates

A Figma file is a tree before it is anything else. The page holds frames, a frame holds groups, a group holds shapes and text, and any of those can nest again to whatever depth a designer builds. That scene tree is the model the editor walks every frame to lay out and paint, and it is the model the coding round reaches for again and again. When a prompt talks about layers, frames, groups, or components, it is almost always asking you to traverse a tree or a graph and combine something as you go.

The rounds run on CoderPad, live and executable, and they often open with a blank file. No TreeNode class, no adjacency list, no parser to turn the input into a structure. You define the node, you build the test input, then you solve. The bar sits at a solid medium. The set is standard once you see past the framing: depth-first and breadth-first traversal, each iterative and recursive, plus the two graph workhorses of reachability and dependency ordering. What makes it Figma is the wrapper, a layer tree in place of a generic n-ary tree and a component graph in place of an anonymous set of edges.

The Figma angle

Type the structure first, before you touch the algorithm. When the editor is blank, start with the scaffold. That means a node with an id and a list of child pointers, a children list built from parent indices, or a defaultdict(list) for a graph. Say why as you build. A layer holds any number of children, so this tree is n-ary. A component graph needs a visited set because instances can point back at shared components. This is partly a real-skill check and partly a Figma habit, because the product itself is a scene tree to the core and the editor never stops walking it. An interviewer who watches you lay down a clean structure in twenty seconds is watching someone who has modeled data before, not only memorized answers.