Describe a robust architecture for implementing theming using design tokens
Tiered token separation and runtime strategy for multi-theme systems.
Three tiers, CSS custom properties for live switching, and layered overrides.
Hardcoded colors in components or CSS rebuilds on theme change.
What's really being asked
This question evaluates whether you can architect a separation of concerns between visual identity and UI implementation. The interviewer wants to see that you understand design tokens as an abstraction layer rather than just variables, and that you know how to make theme switching performant at runtime in a production application. They are looking for familiarity with token taxonomy, build-time transformation, and runtime delivery mechanisms.
The full answer
First, describe a three-tier token architecture. Tier 1 contains raw primitives like color-brand-green or border-radius-large. Tier 2 provides semantic mapping such as theme-color-primary-background or theme-border-radius. Tier 3 binds those semantics to specific components like button-primary-background or card-border-radius. This insulates components from raw values. Second, explain build-time token management using a tool like Style Dictionary to generate platform-specific outputs from JSON source files. Third, address runtime performance by emitting CSS custom properties from the tokens so the browser can swap themes instantly via a class or data attribute on the HTML root element without React re-renders or JavaScript style recalculation. Fourth, discuss theme composition where core tokens are shared and brand, sub-brand, or white-label themes are layered as overrides, preventing duplication and enabling per-customer configurations.
The mistakes people make
A major red flag is suggesting Sass or LESS variables alone for runtime theming because they compile to static values and require rebuilding stylesheets to change themes. Another mistake is putting hex codes directly in component files rather than referencing tokens. Proposing that every component subscribes to a theme context and recalculates styles in JavaScript is also wrong because it destroys performance by forcing layout thrashing across the tree. Finally, suggesting a single flat token file shows lack of experience with scaling across multiple brands or platforms.
What usually comes next
The interviewer may ask how you would handle theme switching without a flash of unstyled content on server-rendered applications. They might probe how to support high-contrast or accessibility modes within the same architecture. Another common follow-up is how you would version and distribute tokens across micro-frontends or native mobile apps. You should also be ready to discuss how designers consume these tokens in Figma or Sketch.
A concrete example
Imagine a banking white-label platform. The core theme defines spacing and elevation. The base brand theme maps Tier 1 colors to Tier 2 semantic names like action-primary. A specific bank white-label theme overrides only Tier 1 color values and a few Tier 2 mappings. At build time, Style Dictionary generates CSS custom properties for each theme. At runtime, the app injects the correct theme stylesheet or toggles a data-theme attribute. The result is a single component library that renders Chase branding for one route and Wells Fargo for another with no component code changes and zero runtime JavaScript style overhead.
Interview question
Which strategy correctly separates visual identity from UI implementation while enabling instant runtime theme switching without forcing React re-renders?
- a.Emit CSS custom properties from a three-tier token system and toggle themes via a data attribute on the HTML root.Correct
- b.Compile per-theme Sass files from Tier 1 primitives and swap the stylesheet link tag when the brand changes.
- c.Flatten all tiers into a single token set and distribute it to components through a reactive store that updates inline styles.
- d.Import Tier 3 tokens as JavaScript constants and compute style objects in a React context provider.
Why? this is the answer
A three-tier token system insulates components from raw values, and CSS custom properties let the browser switch themes instantly via a root attribute without JavaScript recalculation or React re-renders. Option D is tempting because React context is a standard state pattern, but it forces layout thrashing by recalculating styles across the entire component tree.
Just read this? Test yourself on what you have been reading.
Read the original → bradfrost.com
- #design systems
- #design tokens
- #theming
- #css architecture
- #performance
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design systems — each one lists the topics its interview covers.
See open roles