CSS custom properties versus Sass for theming

WHAT THIS TESTS The interviewer checks whether you understand the fundamental timing difference: Sass runs before the browser, CSS custom properties run in the browser. That distinction decides which fits dynamic theming.

A GOOD ANSWER COVERS Explain that Sass variables are resolved at compile time. They are excellent for authoring conveniences, loops, mixins, and arithmetic, but they do not exist in the shipped CSS, so you cannot change them at runtime; switching themes would require recompiling and reloading stylesheets. CSS custom properties live in the cascade at runtime: they inherit, can be scoped to selectors, can be read and written by JavaScript, and recalculate instantly when changed. That makes them the right tool for dynamic theme switching like light and dark mode or per-user themes. They also work with calc for math. The mature approach uses Sass for build-time structure and custom properties for the values that must change at runtime.

COMMON WRONG ANSWERS Saying Sass variables can be swapped to change theme live, which is impossible since they are gone after compilation. Claiming custom properties cannot do calculations. Treating the two as mutually exclusive rather than complementary.

LIKELY FOLLOW-UPS What are the browser support and performance characteristics of custom properties? How do you do math with custom properties? When would you still reach for Sass in 2026?

ONE CONCRETE EXAMPLE With Sass you write $primary: #0A74FF and it bakes that color into the output, so a dark mode would need a second compiled file. With custom properties you write --primary: #0A74FF on :root and override it under [data-theme=dark]; a single line of JavaScript toggling the attribute switches the entire theme instantly, no recompile, no reload.