Component Architecture at Scale

The plain-language idea

Once a prompt's requirements are scoped, the next thing a strong candidate does is sketch a component tree — a rough box-and-line breakdown of the screen or feature, before touching data models or APIs. This is whiteboard-level architecture, not implementation: you're not writing component code, you're deciding where the seams go.

Two questions do almost all the work:

• Container vs. presentational. Which boxes own state and fetch data (containers), and which ones just receive props and render (presentational)? Naming this split out loud signals that you're separating "what data does this feature need" from "how does it get displayed" — two concerns that get tangled fast if every component fetches its own data independently.
• Where does shared state live? When two sibling components both need the same piece of state, it can't stay in either one alone — it has to move up to their nearest common ancestor, which then becomes the container that owns it and passes it down. This is the single most common structural decision in a whiteboard sketch, and getting it right is what separates a coherent tree from a tangle of ad hoc prop-passing.

A feature's natural boundary in the tree is usually wherever a self-contained container sits: the box that owns the state and the fetch, with everything below it just rendering what it's handed.

See it in a real thing: sketching a search feature

Say the prompt is "design a search-as-you-type feature: a text box and a results list below it." The instinct is to sketch two independent boxes, SearchBox and ResultsList, each seemingly self-contained.

Requirement: a search feature needs a SearchBox for typing a query and a ResultsList showing matches.

BackNext

The problem surfaces immediately: ResultsList needs the query text that SearchBox owns, to know what to fetch and render. That state can't live in either child alone — it lifts up to a new common ancestor, SearchFeature, which becomes the container: it owns the query state and the fetch, while SearchBox and ResultsList stay presentational, rendering only what they're given (an input value plus an onChange, and a results array, respectively). Saying this reasoning out loud — "these two need to share state, so it lifts to their common parent" — is exactly the signal an interviewer is listening for.

What people usually miss

Watch out

• Jumping straight to a global store for shared state is a common overreaction. State shared between two or three related components usually just needs to lift to their common ancestor — reaching for app-wide state management here is solving a smaller problem with a bigger tool than it needs.
• A container isn't always the whole feature. A large screen can have several nested containers, each owning the state that's actually local to its own sub-tree — flattening everything into one giant container that fetches for the entire page is itself a design smell.
• Presentational components should stay genuinely dumb. The moment a "presentational" component starts fetching its own data or reaching outside its props, the container/presentational separation has quietly broken down, and the tree stops being legible.
• This is a sketch, not a commitment to file structure. The whiteboard tree communicates responsibility boundaries; it doesn't need to map one-to-one onto actual files or folders in the eventual implementation.

Why this matters in interviews

Almost every "design this UI feature" prompt expects a component tree sketch early on, and the strongest signal a candidate gives is correctly identifying where state has to lift and why — not just drawing boxes, but explaining the forcing function behind each boundary.