Process for adding a new component

WHAT THIS TESTS The interviewer wants a concrete, repeatable workflow showing you balance speed for the requesting team against quality and reuse for everyone else. They are listening for triage, ownership, and a way to unblock the team while the proper component is built.

A GOOD ANSWER COVERS Start with intake and triage: capture the use case and confirm whether this need is shared across teams or local to one. Check whether an existing component or composition already solves it. If a new component is justified, move to design and specification, defining variants, states, tokens, and accessibility requirements up front. Build it with automated tests, accessibility checks, and visual regression coverage. Write documentation with code examples and do-and-don't guidance. Version it under semantic versioning and ship it through your package release pipeline. Critically, give the requesting team an interim path, such as a local implementation or a beta build, so they are not blocked while the canonical version matures.

COMMON WRONG ANSWERS Immediately writing code without confirming the need is shared, producing bloat. Skipping accessibility and documentation, which makes the component unusable by others. Blocking the team for weeks with no fallback. Adding the one-off directly to core without governance.

LIKELY FOLLOW-UPS What if only one team will ever use it? How do you decide core versus local? How do you keep the requester unblocked during the wait?

ONE CONCRETE EXAMPLE A team needs a date-range picker. You triage and find two other teams want it too, so it qualifies for core. You spec variants and keyboard behavior, build it with unit and visual tests, document it in Storybook, ship version 1.4.0, and meanwhile hand the requesting team a feature-flagged beta package so they ship on schedule.