Build a scalable Sass theming system

WHAT THIS TESTS The interviewer wants to see if you separate build-time authoring from runtime switching, and whether your approach scales past two themes without duplicating CSS.

A GOOD ANSWER COVERS Define each theme as a Sass map keyed by token name, for example a colors map and a spacing map. Write a mixin that iterates the active theme map and emits CSS custom properties scoped to a selector such as html[data-theme=dark] or a body class. Components never reference Sass variables directly for themeable values; they read var(--color-bg) so the browser resolves the right value at runtime. This means switching themes is a single attribute or class change with no recompile and no flash of restyling. Sass handles authoring, validation, and generation; custom properties handle runtime cascade.

COMMON WRONG ANSWERS Compiling a full separate stylesheet per theme doubles bundle size and breaks runtime switching. Using only Sass variables forces a rebuild to change themes since they resolve at compile time. Inlining colors in components defeats centralization. Toggling themes by swapping entire CSS files causes flashes and cache churn.

LIKELY FOLLOW-UPS How do you avoid a flash of the wrong theme on first paint? Set the attribute via an inline script before stylesheets load. How do you handle a third brand theme? Add another map and emit another scope. How do you type-check tokens? Validate map keys in a Sass function and error on missing tokens.

ONE CONCRETE EXAMPLE Define maps for light and dark, each mapping color-bg, color-fg, and color-accent. A mixin loops a passed map and prints each as a custom property. Call the mixin once inside :root for the default light theme and once inside html[data-theme=dark]. A button uses background var(--color-accent). Flipping data-theme on the html element instantly repaints every component with the dark values, no rebuild required.