Component questions vs app questions

Two prompts, one wrong answer

Picture two candidates on the same afternoon. The first gets "Design an autocomplete for a search box." The second gets "Design a news feed like the one on a social network." Both have studied the same notes, and both open with the same plan: a box for the browser, a box for the API server, a box for the database, a CDN in front.

The first candidate spends twelve minutes drawing servers for a widget that has one endpoint. The interviewer keeps asking "what does the parent page pass in?" and "what happens when I press the down arrow?" The candidate never reaches keyboard support, never names the combobox role, and never handles the race between two slow responses. The feedback says: "Strong backend instincts, didn't design the component."

The second candidate does the opposite mistake. They write a careful PostCard props type, discuss whether onLike should be a callback or an event, and debate slots for the footer. Thirty minutes in, they haven't said how the feed loads its second page, where posts are cached, or how a new post shows up. The feedback says: "Good React knowledge, no system design."

Why the shape of the prompt matters

Frontend system design prompts come in two main shapes. A component question asks for one reusable piece of UI that other engineers drop into their pages. An app question asks for a whole product with screens, a server, and data that changes while people use it. Each shape has a different main user, a different hard part, and a different place where your minutes should go.

The interviewer usually knows which shape they asked for, and their rubric reflects it. A rubric for a date picker has lines like "keyboard navigation", "controlled vs uncontrolled", and "locale and time zones". A rubric for a chat app has lines like "message ordering", "real-time transport", and "offline send queue". You score on the lines that exist.

Time spent on topics that aren't on the rubric is time you can't spend on the ones that are.

This lesson teaches you to spot the shape in the first minute, what to emphasize in each, how the RADIO time split moves with scope, and how to handle the prompts that sit in between. It builds on the RADIO framework lesson (Requirements, Architecture, Data model, Interface, Optimizations) and on What interviewers look for, by level. Read those first if the five steps are new to you.

The mental model: who is your user, and where is the hard part?

Think of a door handle and a house. An architect asked to design a door handle thinks about hands: the grip, how far it turns, whether a child or someone with arthritis can use it, and whether it fits doors made by other companies. An architect asked to design a house thinks about rooms, pipes, wiring, and how people move between spaces. The handle is one line in a long list.

Both are design, and both architects are skilled. But the questions they ask, the drawings they make, and where their hours go are completely different. Frontend prompts work the same way.

The two archetypes

A component question asks for one piece of UI with a public API: an autocomplete, an image carousel, a date picker, a data table, a modal dialog, a toast system. You are writing a small library, and the server is one endpoint or none at all.

Your first user is another developer, who passes in props and listens for events. Your second user is the person who clicks, types, or listens with a screen reader.

An app question asks for a product: a news feed, a chat app, an online store, a photo sharing site, an email client. You are the tech lead. Your user is the customer, on a slow phone, scrolling for twenty minutes. The hard parts are about data: where it comes from, how it's cached, how it stays fresh, and how the first page loads fast.

Between them sit feature questions: a comment section, a notification bell, a checkout flow, a file uploader with progress. They are a small app inside a bigger one. They need some API design and data flow, plus a component-style contract with the page that hosts them.

Two tests that sort almost any prompt

You don't need a long checklist. Two questions sort almost every prompt you'll get.

1. Who is the main user of my design? If it's a developer who will import it, you're designing a component. If it's a customer using a product, you're designing an app.
2. Where does the hard part live? If it lives inside one rectangle on the screen (keyboard, focus, rendering, timing), it's a component. If it lives between the browser and the server (loading, caching, syncing, scale), it's an app.

When both answers point the same way, you're done. When they disagree, you have a feature question or an ambiguous prompt, and you should ask (chapter 3 covers how).

Spotting the shape in the first minute

Most prompts tell you their shape in the words they use. You only need to listen for it, then confirm with one question. This takes under a minute and decides how you spend the next forty.

Signal words in the prompt

• Component signals: "component", "widget", "for our design system", "reusable", "that other teams can use", "embeddable", or a noun that is clearly one piece of UI ("a date picker", "a modal", "a carousel").
• App signals: a product name ("Design Twitter", "Design YouTube"), "app", "platform", "site", "for millions of users", or a verb about people doing things ("users can post, follow, and comment").
• Feature signals: "a section of", "a page in", "add X to our product" ("add comments to our blog", "a checkout flow for our store").

Watch for prompts that name a product but ask for a part of it. "Design YouTube" is an app. "Design YouTube's video player" is a component, with a hard part (adaptive streaming, buffering states, captions, keyboard shortcuts) that lives inside one rectangle.

Questions that confirm the shape

Even when the words are clear, confirm in one sentence. It costs ten seconds and shows the interviewer you know the two shapes need different answers. Good confirming questions sound like this:

• "Is this a shared component for a design system, used by many teams, or a field in one form?" (for a date picker)
• "Should I treat this as a reusable editor component with a clean API, or as a product where documents are saved and shared?" (for a rich text editor)
• "Do you want the whole product, or should I focus on the feed page and treat profiles and messaging as out of scope?" (for Design Instagram)

Notice that each question offers a default. Interviewers often say "your call", and a candidate who picks a sensible scope and explains why scores better than one who waits for permission.

Prompts that could be either

Some prompts are open on purpose, to see whether you notice. The common ones, and a sensible default for each:

Component questions: think like a library author

In a component question, the interface is the product. The server is small, so the design lives in three places: the API another developer types, the behavior the end user feels, and how the component fits into pages you've never seen.

Props and events: the contract

Start the Interface step by writing the props as a type. Each prop is a decision you can defend in one sentence. What goes in (items, value, label), what comes out (onChange, onSelect, onOpenChange), and which defaults make the common case one line of code.

type AutocompleteProps<T> = {
  // Parent owns the network call; the component owns timing and keyboard.
  search: (query: string, signal: AbortSignal) => Promise<T[]>;
  getLabel: (item: T) => string;
  renderOption?: (item: T, state: { active: boolean }) => ReactNode;
  value?: T | null;          // controlled when given
  defaultValue?: T | null;   // uncontrolled otherwise
  onChange?: (item: T | null) => void;
  minChars?: number;         // default 2
  debounceMs?: number;       // default 200
  label: string;             // required: the accessible name
};

Controlled or uncontrolled is the first question every interviewer asks about state. Controlled means the parent owns the value and passes it in with value and onChange, like a React input with value. Uncontrolled means the component keeps its own value and the parent only reads it when needed, with defaultValue. Good shared components support both: controlled for forms that validate on every change, uncontrolled for the quick case.

A common mistake is to emit vague events. onChange(value) for a modal that can close five ways is not enough. Say why it closed: onOpenChange(false, { reason: "escape" }) lets a form warn about unsaved changes only when the user pressed Escape, not when they clicked Save.

Customization without forks

Every team that adopts your component will want it to look slightly different. If the only way to change the option row is to copy your code, you'll have twelve forks within a year. Pick how teams customize it, and say why.

States and accessibility

List every state the component can be in and give each a design: idle, loading, results, empty, error, disabled, and the awkward ones like very long text or 10,000 items. Interviewers notice when a candidate draws only the happy path.

Accessibility is almost always one of your deep dives. Name the pattern from the WAI-ARIA Authoring Practices Guide (APG): combobox with a listbox for an autocomplete, dialog for a modal, tablist for tabs. Then name the keyboard map (arrows, Enter, Escape, Home, End, Tab), where focus goes, and what a screen reader announces, for example through aria-activedescendant and a polite live region for the result count. The ARIA widget patterns lesson covers each pattern in depth.

Fitting any page

• Performance inside the box: debounce typing, virtualize long lists, lazy-load hidden slides, avoid layout shift when the popup opens.
• Theming: CSS custom properties or design tokens, so teams change colors without overriding your selectors.
• Layout edges: popups that flip near the viewport edge, right-to-left languages, phone keyboards that cover half the screen.
• Rendering: works with server rendering (no window access during render) and doesn't break hydration.
• Bundle size: a shared component ships on many pages, so 20 KB of extra JavaScript is paid by every one of them.

App questions: think like a tech lead

In an app question, the hard parts live between the client and the server. Props still exist, but nobody will grade the props of your PostCard. The challenge is breadth: more parts, more data, more ways to fail. You won't cover everything, so the skill is picking what matters and showing how it fits together.

The client-server contract

In an app question, the Interface step is mostly the network API. Name the two or three calls the main screen needs, with their payload shape, how they page, and how errors come back. You don't need every field; you need the fields that drive decisions.

GET /api/feed?cursor=eyJpZCI6OTg3fQ&limit=20

200 OK
{
  "items": [
    { "id": "p_981", "authorId": "u_12", "text": "...",
      "media": [{ "url": "...", "width": 1080, "height": 1350 }],
      "likeCount": 42, "likedByMe": false, "createdAt": "2026-10-19T09:12:00Z" }
  ],
  "users": { "u_12": { "name": "Asha", "avatarUrl": "..." } },
  "nextCursor": "eyJpZCI6OTYxfQ"
}

Say why you picked REST, GraphQL, or a backend-for-frontend (a thin server shaped for one client). For a feed, a single REST endpoint with a cursor is a fine default. GraphQL earns its place when many screens need different slices of the same data. The interviewer cares that you chose on purpose, not which one you chose.

Data flow and the client store

Next, say where server data lives on the client and how it moves. The usual answer is a query cache (TanStack Query, SWR, or RTK Query) keyed by request.

For data that appears on many screens, add normalization: each post and user stored once by id, and lists holding only ids. Then a like on a post in the feed also updates the same post on the profile page, because there is only one copy. Apollo Client and Relay normalize automatically for GraphQL; with TanStack Query or SWR you add a small merge step or a separate entity store.

Separate the kinds of state out loud: server state (posts, users), UI state (which menu is open), URL state (the current tab, a search query, a selected post), and form state (a half-written comment). Each lives in a different place, and saying so shows you know why.

Freshness, loading, and failure

• Freshness: how new content arrives. Polling (typically every 30 to 60 seconds), server-sent events, or WebSockets, and why. Most feeds show a "New posts" pill instead of pushing content under the reader's thumb.
• The user's own actions: optimistic updates for likes and comments, with rollback when the server says no.
• First load: server rendering or streaming for the first page, code splitting by route, images sized and lazy-loaded, and how Core Web Vitals look on a mid-range phone.
• Long sessions: virtualizing a list that grows to 2,000 posts, and dropping media that scrolled far away.
• Failure: retries with backoff, an offline banner, a send queue for chat, and what the page shows when one service is down.

How scope changes the RADIO time split

RADIO works for both shapes. The five letters stay; the minutes move. The RADIO framework lesson gives a default split for a 45-minute round: about 3 minutes of hellos, then 5 for Requirements, 8 for Architecture, 4 for Data model, 5 for Interface, and 15 for Optimizations, with 5 left for your questions. That default fits a feature question, which sits in the middle.

For the two archetypes, shift minutes from the parts that shrink to the parts that grow. The total design time stays at about 37 minutes.

Why each step grows or shrinks

• Requirements stay about the same. Both shapes need the same short list: functional, non-functional, out of scope. The content differs (props and devices versus users and scale), not the length.
• Architecture halves for a component. Three or four boxes inside the browser (input, popup list, controller, cache) take four minutes. An app needs the client layers, the API, a CDN, a real-time channel, and arrows between them.
• Data model grows a little for an app. A component has internal state: query, activeIndex, isOpen, status. An app has entities and relations, a normalized store, and URL state.
• Interface flips. For a component it's the main event: props, events, slots, and the keyboard map. For an app it's two or three endpoints with their paging and errors; component props get a sentence.
• Deep dives keep the largest share in both. That's where levels are separated. A component's deep dives are inside the box (accessibility, races, virtualization). An app's are between client and server (pagination, caching, freshness, first load).

Same letter, different drawing

The bigger change isn't the minutes. It's what you put on the whiteboard for each letter. A candidate who keeps the app-style drawing for a component, even with the right minutes, still spends Architecture drawing servers nobody asked about.

Worked example: an autocomplete, minute by minute

Here is how a strong 45-minute answer to "Design an autocomplete for our design system" spends its time. The full design is in the Design an autocomplete guide; this chapter shows only the shape of the answer and why each minute goes where it does.

Minutes 3 to 8: requirements

Confirm the shape first: "This is a shared component that many teams will drop into search boxes and forms, right?" Then ask about the data (local list or a server search, how many results, how fast the endpoint is), the inputs (keyboard, touch, screen readers), the browsers, and the bundle budget. Write down a short list:

• Functional: show matches as you type, select with mouse, touch, or keyboard; works with a local list or a server search; custom option rows.
• Non-functional: suggestions within 400 ms after typing stops on 4G; full keyboard and screen reader support (APG combobox); under 10 KB gzipped; works with server rendering.
• Out of scope: the search backend and its ranking, multi-select chips (offer them as an extension).

Minutes 8 to 16: architecture and state

The architecture is four boxes, all in the browser: the input, the popup with its list, a controller that owns timing and the keyboard, and a small cache. One arrow leaves the browser, to the search function the parent passes in. That takes four minutes, and that's correct: there's nothing more to draw.

The state is just as small: query, items, activeIndex, isOpen, status (idle, loading, success, empty, error), and a cache of recent queries mapped to results. Say that the selected value can be controlled by the parent, which leads straight into the interface.

Minutes 16 to 23: the interface

This is the longest early step, and it should be. Write the props type from chapter 4, then the events, then the keyboard map: Down and Up move the active option, Enter selects, Escape closes the popup (and clears the box on a second press), Home and End move the cursor in the text, Tab leaves without selecting. Say how customization works (renderOption, a slot for the empty state).

Minutes 23 to 40: deep dives

Pick three, say why, and go deep. Each one is about something that happens inside the box:

1. Stale responses. The user types rea, then reac; the rea response arrives last and overwrites the better list. Fix: abort the old request with AbortController and ignore any response whose query doesn't match the current one.
2. Fewer requests. Debounce typing by about 200 ms, wait for 2 characters, and cache recent queries so backspacing is instant. Typing javascript drops from 10 requests to 1 or 2.
3. Accessibility. Focus stays in the input; the active option is pointed to with aria-activedescendant; aria-expanded and aria-controls link input and list; a polite live region says "5 results". Test it with VoiceOver and NVDA, not only with a linter.

If time is left, mention long lists (cap at 10 or virtualize), popup positioning near the screen edge and above a phone keyboard, and input methods for Chinese or Japanese, where you must not search during composition. The Design a modal dialog guide follows the same shape: a tiny architecture, a large API section (open state, close reasons, initial focus), and deep dives on focus trapping, returning focus, and scroll locking.

Worked example: a news feed, minute by minute

Now the same clock for "Design a news feed". The full design is in the Design a news feed guide. Compare where the minutes go with the autocomplete: Architecture more than doubles, the Interface shrinks to the network API, and the deep dives move from inside the box to between client and server.

Minutes 3 to 8: requirements

Cut scope early, because an app has more features than you can design: "I'll focus on reading the feed, liking, and commenting. Posting with media gets a short section. Profiles, messaging, and ads are out of scope." Then ask about scale and devices, and use a quick estimate (the Back-of-the-envelope numbers for frontend lesson shows how).

• Functional: infinite scroll of posts with text and images; like and comment; see that new posts exist without losing your place.
• Non-functional: first posts visible in under 2.5 seconds on a mid-range phone on 4G (LCP); smooth scrolling through 1,000+ posts; works on flaky networks; images don't shift the layout.
• Out of scope: ranking (the server decides the order), ads, messaging.

Minutes 8 to 17: architecture

Draw the whole system in one picture: the browser with its view layer, a client store (query cache with normalized posts and users), a data layer that talks to the feed API, a CDN for images and static files, and a channel for new-post notices. Mark which page is server rendered. This takes about nine minutes, and every box will come back in a deep dive.

Minutes 17 to 26: data model and API

Name the entities: Post, User, Comment, and the feed as a list of post ids with a nextCursor. Say they're normalized, so a like updates the post everywhere it appears. Then give the API from chapter 5: GET /feed?cursor=...&limit=20, POST /posts/:id/like, GET /posts/:id/comments?cursor=.... Two sentences on why a cursor beats an offset: new posts at the top would shift offset pages and cause duplicates.

Note what isn't here: no PostCard props type, no keyboard map. If the interviewer wants a component, they'll ask, and you can zoom in later.

Minutes 26 to 40: deep dives

1. Loading and pagination. An IntersectionObserver sentinel near the bottom starts the next page before the reader gets there; the cursor guarantees no duplicates; one page in flight at a time.
2. Long sessions. Virtualize the list so only the 10 to 20 posts near the viewport are in the DOM; reserve image space from the API's width and height so nothing jumps.
3. Freshness. Poll a cheap "anything new?" endpoint (typically every 30 to 60 seconds) or listen on server-sent events; show a "New posts" pill instead of inserting posts above the reader.
4. Instant likes. Optimistic update in the normalized store, rolled back with a toast if the request fails.

That's four deep dives in fourteen minutes, so each gets three or four minutes. That is normal for an app: breadth is part of the signal, and you go deepest on the one or two the interviewer leans into.

Feature questions, zooming, and the mistakes that cost points

Real prompts don't always sit at either end. Feature questions mix both shapes, and good answers move between levels on purpose. This chapter covers the middle ground, how to switch levels cleanly, and the mistakes interviewers see most often.

Feature questions: two interfaces

A feature like a comment section has two interfaces. Facing the server, it needs an API: list comments with a cursor, post a comment, maybe a stream of new ones. Facing the host page, it's a component: postId, currentUser, an onCountChange event so the page header can update its comment count. Sketch both, briefly, and spend the deep dives on what makes this feature hard: threaded replies, optimistic posting, moderation states.

Zooming in and out on purpose

Strong candidates change level during the round, and say when they do. In an app question, zoom into one component for a deep dive once the data flow is clear: the feed's virtualized list, the chat composer's send button states. In a component question, zoom out briefly to show where its data comes from, then come back.

The rule is to finish the level you're on before you leave it, and to announce the switch: "The data flow is in place. I'd like to zoom into the feed list for a few minutes, because that's where scrolling performance is won or lost." Without the announcement, the interviewer loses the thread, and a zoom looks like drifting.

Mistakes that cost points

• Servers for a widget. Drawing a load balancer, database, and cache cluster for a date picker. The interviewer can't score any of it.
• Props for a product. A careful PostCard type at minute 20 of a news feed while pagination and caching are still blank.
• Happy path only. A component with no loading, empty, or error state, or an app where nothing ever fails.
• Accessibility as a footnote. "And we'd add ARIA" at minute 44. In a component question, it's a main deep dive; in an app, at least name focus handling for route changes and dialogs.
• Never confirming the shape. Spending ten minutes on the wrong kind of answer for an ambiguous prompt, when one question would have fixed it.

What changes with seniority

Junior candidates are expected to cover the basics of the shape they're given: a sensible props type, or a sensible API and box diagram. Mid-level candidates should pick the right emphasis without being told and handle the main states and failures. Senior and staff candidates spot the shape and scope it in the first minute, offer a default for ambiguous prompts, explain trade-offs before being asked, and zoom between levels cleanly. The What interviewers look for, by level lesson covers these signals in detail.