What is component nesting? Build a profile header from nested components.

WHAT THIS TESTS: The interviewer wants to know if you understand component nesting as a design system scalability pattern, not just a Figma feature. They are checking whether you think in atomic design terms by breaking complex UI into reusable, independently maintainable instances that compose together. Senior designers and engineers care about propagation, consistency, and reducing manual update debt across large teams.

A GOOD ANSWER COVERS: First, a crisp definition: nesting means placing instances of base components inside a larger parent component so the parent behaves as a unified element while each child remains linked to its source. Second, a concrete composition story: for a user profile header, you would nest an Avatar instance, a Text instance for the name and role, and a Button instance for actions like Edit or Follow. Third, the maintenance benefit: because each piece is an instance, a branding update to the Avatar base component or a text style change pushes globally without manually hunting through screens. Fourth, override behavior: mention that nested instances preserve local overrides, so one header can show a different name or button state without detaching from the system. Fifth, instance swap flexibility: the Avatar slot could be swapped for a team logo or the Button swapped for an icon button depending on context, all without breaking the header structure.

COMMON WRONG ANSWERS: A major red flag is describing the header as a single flattened group or frame with raw vector shapes and text layers. This signals you do not design for reuse and will create maintenance nightmares. Another mistake is confusing nesting with simple grouping; grouping layers does not create reusable linked instances. Some candidates also forget to mention overrides or instance swaps, suggesting they have only used components statically. Saying you would duplicate the header and manually change each copy is the opposite of what a senior interviewer wants to hear.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle nested instances if the child component has conflicting constraints or auto layout settings. They might probe how you structure variants, for example whether the profile header itself should have variants for different states or whether state should be managed through nested button and avatar variants. They could also ask about performance or library organization at scale, such as how many levels of nesting become unwieldy in a multi-file design system.

ONE CONCRETE EXAMPLE: Imagine a habit tracking card in a mobile app. Instead of drawing a bell icon and a checkmark button directly into the card frame, you turn the bell and checkmark into separate components and nest their instances into the card component. When the company rebrands and the icon library updates, changing the base bell icon once updates every habit card across every screen. If one card needs a star icon instead, you use instance swap on that specific nested layer without detaching the card or creating a duplicate component.