How would you architect Figma components and styles for light and dark themes?

WHAT THIS TESTS: The interviewer wants to see if you understand design-token architecture and Figma's variable scoping features at a senior level. They care about scalability, library maintenance, and designer ergonomics. Specifically, can you separate raw values from intent, avoid component duplication, and let consumers switch themes without breaking library links or detaching instances.

A GOOD ANSWER COVERS: First, establish a three-tier token strategy. Primitives define raw values like hex codes for blue-500 or neutral-900. Semantics map those primitives to intent like background-default or text-primary. Components bind only to semantic variables, never raw hex codes or primitives directly. Second, use Figma variables with modes. Create a color variable collection with two modes, light and dark. Assign each semantic variable the appropriate primitive value per mode. Third, publish the variable collection alongside the component library. When designers consume components, they apply the library file and switch the variable mode at the page or frame level, which cascades through every nested component automatically. Fourth, handle edge cases like elevation or inverse surfaces by creating additional semantic tokens rather than one-off overrides. Mention that spacing and typography can remain static or use separate variable collections if needed, but the core challenge is color.

COMMON WRONG ANSWERS: A red flag is proposing two parallel component sets, one for light and one for dark. This doubles maintenance and breaks consistency. Another red flag is using color styles instead of variables and suggesting designers manually swap style libraries, which is tedious and error-prone. Saying designers should detach instances to change colors is an immediate fail. Also, binding components directly to primitive variables shows shallow token knowledge because it prevents semantic remapping for brand or platform variants.

LIKELY FOLLOW-UPS: The interviewer might ask how you would handle a third theme like high-contrast or a white-label rebrand. Expect to explain adding another mode to the same collection or branching semantic collections. They might probe performance with hundreds of variables, so mention organizing collections by domain and documenting usage. Another follow-up is how developers consume these tokens, so briefly note syncing to JSON or Style Dictionary via a plugin or API pipeline.

ONE CONCRETE EXAMPLE: Imagine a button component. The button background uses the semantic variable action-primary-background. In light mode, that variable points to primitive blue-600. In dark mode, it points to primitive blue-400. The text on the button uses action-primary-text, pointing to neutral-0 in light mode and neutral-900 in dark mode. A designer places the button on a checkout page, sets the page-level variable mode to dark, and every button, input, and background on that page updates instantly without detaching or selecting individual layers.