Design the public API for a reusable Button component

WHAT THIS TESTS: This question evaluates your ability to design a stateless, framework-agnostic API surface for a primitive UI component. Interviewers want to see that you distinguish between presentational concerns and application logic, that you prefer composition via slots over configuration via dozens of props, and that you respect platform semantics by leveraging native HTML rather than reimplementing it. They also care whether you understand encapsulation and avoid breaking it with escape hatches.

A GOOD ANSWER COVERS: First, a minimal prop set of roughly five to seven presentation controls such as variant, size, disabled, and type. Second, event design that forwards or emits native click events rather than inventing high-level action handlers like onSave or onCancel. Third, composition via slots for text labels and optional leading or trailing icons so the consumer controls content without dedicated icon props. Fourth, a strict boundary that keeps routing, form submission, and styling escape hatches outside the component, aligning with the guide's warning against semantic obfuscation and escape hatches.

COMMON WRONG ANSWERS: A red flag is exposing application-coupled props such as route, to, or onSubmit, which forces the button to know about routing or form logic. Another anti-pattern is a catch-all class or style prop used to override internal styling, which breaks encapsulation and makes the component impossible to maintain at scale. Candidates also stumble by omitting disabled or loading states, or by accepting a label prop instead of a slot, which limits composition. Suggesting the component internally switches between a button and an anchor tag based on an href prop without preserving accessibility semantics is another serious misstep.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle navigation use cases if the component should not own routing. They might probe how you support a loading state that disables the button without breaking native form submission. You could also be asked how to type event payloads in TypeScript, or how to forward ref and focus events to preserve accessibility. Another common pivot is asking how you would allow consumers to add arbitrary data attributes or ARIA properties without resorting to a spread-all escape hatch.

ONE CONCRETE EXAMPLE: Imagine a design system button used in three contexts. For a login form, the consumer writes Button variant primary type submit disabled isLoading and listens for the native click event to trigger validation. For a cancel action, the consumer uses Button variant secondary type button and wires the click event to close a modal. For navigation, the consumer does not pass an href to the button; instead, they compose a router link or anchor around the button, or they use a separate Link component, preserving the button's semantic purity and avoiding the escape hatch anti-pattern described in the reference guide.