Shared component library versus per-product builds

WHAT THIS TESTS The interviewer wants nuanced judgment about reuse. Sharing code is not free; it trades local autonomy for global consistency and creates a dependency every consuming team must manage. They want to hear you reason about when that trade pays off.

A GOOD ANSWER COVERS A shared component library reduces duplication, enforces visual and behavioral consistency, and lets one bug fix or accessibility improvement reach every product at once. The costs are real: you need semantic versioning, a release process, clear ownership, and a way to coordinate breaking changes across consumers who upgrade on different schedules. The API risks over-generalization, accumulating props and flags to satisfy every caller. Per-product builds are faster to ship initially and fully independent, but identical bugs must be fixed many times and the products visually drift apart. The decision hinges on how many products share the need, how stable the component is, and whether a team will own the library long-term.

COMMON WRONG ANSWERS Asserting reuse is always right, or always wrong. Ignoring versioning and the upgrade coordination tax. Forgetting that an unowned shared library rots faster than duplicated code.

LIKELY FOLLOW-UPS How do you roll out a breaking change across five consuming teams? Independent component versions or one monolithic library version? Who funds and staffs the library team?

ONE CONCRETE EXAMPLE Three products each need a date picker. A shared, versioned picker means an accessibility fix ships once to all three; but moving from v2 to v3 with a changed prop forces a coordinated migration. If only one product needed it, building natively would be faster and avoid the coordination cost entirely.