How do Figma Variables and component properties enable theme switching?

WHAT THIS TESTS: This question evaluates whether you understand Figma's design-token architecture and can bridge abstract variable collections with concrete component instances. Senior candidates should demonstrate how to bind semantic tokens to layers, propagate changes through modes, and avoid redundant component bloat.

A GOOD ANSWER COVERS: First, create a variable collection such as Theme and define modes like Light and Dark. Within that collection, build semantic tokens for example bg-primary or text-default and assign mode-specific values. Second, apply those variables directly to component layer properties including fills, strokes, effects, and auto-layout spacing rather than hard-coding values. Third, keep component properties reserved for structural logic such as boolean visibility, instance swaps, or text content while letting variables own all visual theme data. Fourth, place instances inside frames and switch the mode at the frame or instance level so the theme cascades without detaching or duplicating masters.

COMMON WRONG ANSWERS: A major red flag is proposing separate Light and Dark master components for every element, which doubles maintenance and negates the purpose of variables. Another mistake is suggesting that component properties should store color values or hex codes directly, confusing structural props with design tokens. Candidates who claim mode switching requires manual overrides on every instance also reveal a shallow understanding of Figma's cascade behavior.

LIKELY FOLLOW-UPS: Interviewers often ask how you would handle nested components when a child needs a different mode than its parent, such as a dark card sitting on a light page. They may probe your migration strategy for moving an existing style-based library to variables without breaking published components. You might also be asked how to structure collections when supporting multiple brand themes beyond simple light and dark, or how variables interact with library publishing and permissions.

ONE CONCRETE EXAMPLE: Consider a primary button component. Its rectangle fill uses a variable named action-primary-background from the Theme collection. In Light mode the value is blue-500, and in Dark mode it is blue-400. The button also has a component property to toggle an icon. When a designer drops the button into a dashboard frame and sets that frame's mode to Dark, every button instance automatically shows the blue-400 fill while the icon toggle remains independent of the theme. If the designer overrides a single button instance to Light mode, only that button changes, demonstrating the flexibility of the variable-mode system.