Component variants with BEM modifier classes

WHAT THIS TESTS The interviewer checks whether you can express a finite set of variants with maintainable CSS rather than copy-pasting styles or fighting specificity.

A GOOD ANSWER COVERS Use a base-plus-modifier structure. The block class, btn, holds everything common to all buttons: padding, border-radius, font, focus ring, and layout. BEM modifier classes capture only the differences: btn--primary sets the filled brand background and white text, btn--secondary uses an outlined or muted treatment, and btn--destructive applies the danger color. In markup you always apply the base and exactly one modifier, for example class equals btn btn--destructive. Because shared rules live once on the base and modifiers add only deltas, you avoid duplication and keep specificity flat, since everything is a single class.

COMMON WRONG ANSWERS Giving each variant a standalone class that re-declares all the shared styles, which causes drift when you change shared behavior. Nesting variants under high-specificity selectors that are hard to override. Allowing two modifiers like btn--primary btn--destructive together, producing ambiguous, order-dependent results. Encoding the variant in an element id or inline style instead of a class.

LIKELY FOLLOW-UPS How do modifiers interact with tokens? Modifiers should set color via semantic tokens like color-action and color-danger so variants stay on-brand. How do you handle states like disabled or loading? Add separate state classes such as is-disabled or use attributes, kept orthogonal to variant. How would this map to a component framework? A variant prop selects one modifier class, giving a typed API over the same CSS. How do you prevent invalid combinations? The component layer enforces a single variant value.

ONE CONCRETE EXAMPLE Define .btn with shared padding, radius, and a visible focus outline. Add .btn--primary { background: var(--color-action); color: #fff; }, .btn--secondary { background: transparent; border: 1px solid var(--color-action); color: var(--color-action); }, and .btn--destructive { background: var(--color-danger); color: #fff; }. A delete control renders class btn btn--destructive, inheriting all base structure and only swapping in the danger color, so adding a future btn--ghost variant means writing one small rule, not duplicating the entire button definition.