How would you structure a flexible Card component API?

WHAT THIS TESTS: This question evaluates whether you think in terms of composable contracts rather than monolithic configuration. Interviewers want to see that you understand a Card is a container with a predictable behavior contract, not a fixed visual template. The goal is an API that is easy to use, predictable, and maintainable for both designers and developers, which means consumers control layout by assembly rather than by toggling props.

A GOOD ANSWER COVERS: First, propose a compound component pattern. Expose subcomponents such as Card, Card.Title, Card.Image, and Card.Body so consumers compose them in any order and omit any piece by simply not including it. Second, mention a slots-based alternative where the Card accepts named render props or slot elements if the framework favors that model. Third, emphasize predictable contracts: each subcomponent should have a narrow, well-defined prop surface. Fourth, discuss avoiding prop drilling by having subcomponents consume context or by keeping data flat at the composition site. Fifth, note that styling responsibility belongs to the subcomponents, so reordering does not break spacing or borders.

COMMON WRONG ANSWERS: A red flag is suggesting a single Card component with boolean flags like showTitle or showImage and a layout enum such as layout equal to image-top. This creates a configuration explosion and forces the library to own every possible arrangement. Another red flag is using a single children prop with no structure, which pushes layout burden onto consumers without giving them reusable building blocks. A third is ignoring accessibility by omitting heading levels or alt text contracts on the image subcomponent.

LIKELY FOLLOW-UPS: The interviewer may ask how you would enforce that a Card.Title is only used inside a Card. They might ask how you handle spacing between rearranged elements, or how the API changes if the design system requires a specific footer action bar. They could also probe performance, asking whether context causes unnecessary re-renders, or ask how you would document the component in Storybook so designers see valid compositions.

ONE CONCRETE EXAMPLE: Imagine a news feed and a product grid both needing cards. With a compound API, the news card renders Card.Image followed by Card.Title and Card.Body. The product card renders Card.Title first, then Card.Image, then Card.Body, and skips the image on out-of-stock items by conditionally rendering nothing. Both use the same import set and the same spacing tokens, but the product team never needs to ask the design system team for a new layout variant.