Deciding whether a one-off variant belongs in core

WHAT THIS TESTS The interviewer wants to see that you protect the core library from becoming a dumping ground while still keeping teams unblocked. The decision framework matters more than the verdict.

A GOOD ANSWER COVERS The pros of adding it to core: if others later need it, it is reusable, stays consistent with the visual language, and is centrally maintained, tested, and accessible. The cons: it enlarges the public API surface the core team must support forever, adds maintenance and documentation burden, and risks bloat when only one team uses it, making the library harder to learn. The decision process: apply a shared-need bar, typically requiring at least two independent consumers before promotion. In the meantime, enable local extension through composition, slots, render props, or a sanctioned escape hatch so the team builds their variant on top of core primitives without polluting it. Document the local pattern, and promote to core only when a second team genuinely needs it.

COMMON WRONG ANSWERS Adding every requested variant to core, which bloats the API and burdens the team. Flatly refusing any extension, which pushes teams to fork or hand-roll, causing drift. Deciding by who asks loudest rather than by shared need.

LIKELY FOLLOW-UPS How many consumers justify promotion? What is a good escape-hatch design? How do you migrate a local variant into core later?

ONE CONCRETE EXAMPLE One team wants a button with an inline countdown. Only they need it, so you keep the core Button clean and let them compose the countdown using the Button's slot API. If a second team later needs the same pattern, you promote it to a documented core variant in a minor release.