Super button versus composition: discuss trade-offs and scalability
Tests combinatorial explosion and API trade-offs in design systems. Contrast the super button's exponential growth with composition's explicit APIs and linear scalability, noting governance needs. Red flag: absolutism or ignoring type safety and tree-shaking.
What's really being asked
This question probes your systems thinking about component API design and whether you recognize the difference between configuration and composition. Interviewers want to see that you understand combinatorial explosion, can weigh maintainability against consumer convenience, and know how design decisions in Figma translate to code complexity. It also surfaces your opinions on type safety, tree-shaking, and cross-functional collaboration with designers.
The full answer
First, articulate the super button trap: dozens of boolean and enum props create an exponential state space that is impossible to test exhaustively, hard to type strictly, and brittle when designers add one more variant. Second, explain why composition wins for scale: small single-purpose components combine into predictable patterns, keep bundle sizes lean via tree-shaking, and mirror how modern frameworks expect UI to be built. Third, admit the cost: composition requires more boilerplate, disciplined naming, and governance to prevent every screen from reinventing the wheel. Fourth, mention the handoff: Figma variants have practical limits and map poorly to a single mega-component, whereas composable containers and slots align design files with code. Fifth, propose a pragmatic middle path such as a few curated high-level components for the 80 percent use case built atop low-level primitives.
The mistakes people make
A red flag is insisting the super button is simpler because consumers only import one thing; this signals shallow experience with long-term maintenance. Another mistake is treating composition as a free lunch and ignoring the need for documentation, lint rules, or design tokens to keep composed UIs consistent. Avoid saying Figma variants should drive code architecture one-to-one; tools have different constraints. Also suspicious is framing this as purely a visual choice rather than an API surface and bundle size decision.
What usually comes next
The interviewer may ask how you enforce consistency when anyone can compose components differently. They might probe whether there is ever a case for a monolithic component, such as a highly constrained button with only two approved variants. Expect questions about performance, specifically whether many small components hurt render budgets compared to one large conditional component. You might also be asked how design tokens and theming interact with each approach.
A concrete example
Consider a list item that needs a leading icon, trailing chevron, toggle, or subtitle. In the super component model you end with props like hasIcon, iconPosition, trailingType, and showSubtitle, producing dozens of invalid combinations such as a toggle and chevron together. In the composition model you create a ListItem container with consistent padding and background states, then accept children such as a Leading visual, Title text, and Trailing action. Designers build the same way in Figma using auto-layout and component properties for the container while swapping nested instances for content, which keeps design files and code in sync.
Interview question
A Button component has 12 boolean props and 5 enums, creating hundreds of untested states and bundle bloat. Which strategy best addresses root causes without shifting burden entirely to consumers?
- a.Add runtime prop validation and visual regression tests for every possible combination
- b.Split into single-purpose composable primitives and offer curated high-level patterns for common casesCorrect
- c.Refactor into a single component driven by a strict Figma variant mapping to ensure visual parity
- d.Replace the component with fully open composition, providing only raw HTML primitives and no guidance
Why? this is the answer
Composable primitives eliminate invalid prop combinations and enable tree-shaking, while curated high-level components preserve consumer ergonomics. Exhaustive testing of every combination is a superficial fix that fails to reduce the exponential state space.
Just read this? Test yourself on what you have been reading.
Read the original → smashingmagazine.com
- #design systems
- #component architecture
- #scalability
- #composition
- #ui design
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design systems — each one lists the topics its interview covers.
See open roles