The RADIO framework

Why you need a framework at all

Picture two candidates who get the same prompt: "Design a news feed." Both know React well, and both have built infinite scroll at work.

One gets a strong hire, the other gets a no. The difference is not what they know but what they did with 45 minutes.

The first candidate starts drawing components in minute one. By minute 15 they have a nice FeedItem with likes and comments. Then the interviewer asks "what if the feed has 5,000 posts?", and they realise they never asked how big the feed is. They rewrite the list, run out of time, and never reach performance, accessibility, or errors.

The second candidate spends five minutes asking questions, sketches the big parts in about eight, names the data and the API in under ten more, and then says: "The two hard parts here are long-list performance and keeping the feed fresh. Let me go deep on those." They spend 15 minutes there, and that is where the interviewer learns the most about them.

What goes wrong without a plan

A system design prompt is short and vague on purpose. There is no single right answer, and nobody hands you a spec. That freedom is the trap. Without a plan, people fall into the same four holes again and again.

• Designing the wrong thing. "Design an image carousel" can mean a hero banner with 5 slides or a product gallery with 200 zoomable photos. Skip the questions and you may solve a problem nobody asked about.
• Spending the clock badly. Twenty minutes on a button component, then three rushed minutes on the parts that were actually hard.
• Leaving holes. Forgetting the API, or never saying where data lives, so the interviewer has to drag it out of you, and that costs you points.
• Freezing. A blank whiteboard and a silent interviewer make it hard to know what to say next. A plan always gives you a next step.

What RADIO stands for

RADIO is a name for the five things every frontend design answer needs to cover. Each letter is one part, and each part builds on the one before it. The mnemonic comes from Yangshun Tay's front end system design playbook on GreatFrontEnd, linked in the references.

The order is not random. You cannot draw the right parts until you know the requirements, and you cannot name the data until you know the parts that hold it.

You cannot design an API until you know the data it carries. And you cannot choose good optimizations until you know where the system is under strain.

A checklist, not a template

Here is the most important idea in this lesson. RADIO is a checklist for running the interview, not a form to fill in.

Strong answers do not sound like "Section R. Section A. Section D." They sound like a story of decisions: "Because the feed can hold thousands of posts, I'll virtualize the list, which means the data layer must give me items by index, so the API returns pages with a cursor." To virtualize a list means to render only the rows on screen.

That is why the problem guides on this site are written as a chain of decisions and not as five fixed boxes. Each chapter makes one choice, weighs the options, and shows how it shapes the next choice. RADIO is still there underneath: every guide starts with requirements, sketches the parts, names the data and the API, and spends its longest chapters on deep dives. You just don't see the labels.

Use RADIO the way a pilot uses a pre-flight checklist. The pilot does not read it aloud to the passengers, but they never take off without touching every item. In the interview, glance at the five letters every ten minutes and ask yourself: "Have I covered this yet? Is it the most useful thing to talk about now?"

How to spend 45 minutes

Time is the one resource you cannot get back in an interview, so plan it before you need it. The calendar invite may say 45 or 60 minutes, but you never get all of it for design. Introductions take a few minutes at the start, and many interviewers keep the last five minutes for your questions.

So a 45-minute slot gives you about 35 to 38 minutes of real design time. A 60-minute slot gives you about 50. Every minute you plan below comes out of that budget.

A default split

Start from this split for a 45-minute interview and bend it to the problem. The numbers are a starting point that has worked for many people, not a law. Notice that the last part gets the most time: that is on purpose.

Why the last part gets the most time

Requirements, architecture, data, and interface are the parts most candidates get roughly right. They are necessary, but they rarely separate a mid-level engineer from a senior one. The deep dives are where you show real depth: why the list needs virtualization at 2,000 items, how you stop an old search response from overwriting a newer one, how focus moves in a modal.

So the goal of the first four parts is to be correct and quick. Cover them well enough that the deep dives rest on solid ground, then move on. If you are still on the data model at minute 30, the interviewer will have little to score you on in the area that matters most.

Bending the split to the question

Different questions put the weight in different places. A component question, like an autocomplete or a date picker, has a tiny server side and a rich component API, so Architecture shrinks and Interface grows. An app question, like a news feed or a chat app, has more moving parts, so Architecture and Data model grow. Try it in the planner below: the feature setting reproduces the table above, and the other two show how the split bends.

Checkpoints, not a stopwatch

You can't stare at a clock while you think, so use two or three checkpoints instead. A simple set for 45 minutes: requirements written down by minute 8, a box diagram by minute 16, and deep dives started by minute 25. If you miss a checkpoint by more than a few minutes, cut something, out loud.

Saying it out loud matters. "We're at 22 minutes and I haven't touched performance, so I'll keep the API short: one paginated endpoint, and I can expand it later if you want" sounds like someone who is in control. Quietly running over sounds like someone who is lost.

R: Requirements

Requirements turn a one-line prompt into something you can design. You get them by asking questions, even when the prompt seems clear. The answers decide almost everything that follows, so this is the cheapest place to avoid a wrong turn.

Sort what you learn into three lists and write them where the interviewer can see them. Written requirements become your contract: later, when you choose between two designs, you point back at them.

Functional requirements: what it does

Functional requirements are the things a user can do. Write them as short user actions, three to six of them, most important first. For a news feed: "see a list of posts from people I follow", "scroll to load older posts", "like a post", "create a text post with an image".

Keep the list short on purpose. Each item becomes a part of your design, so ten items means ten parts and no time for depth. If the interviewer lists many features, ask which three matter most and put the rest under out of scope.

Non-functional requirements: how well it works

Non-functional requirements describe quality: speed, scale, devices, accessibility, reliability. They are where frontend interviews are won, because they decide the deep dives. Give each one a number whenever you can. "Fast" means nothing; "first posts visible in under 2.5 seconds on a mid-range phone on 4G" is something you can design for.

You do not need the interviewer to give you the numbers. If they say "you decide", propose them yourself: "I'll aim for the Core Web Vitals good thresholds: LCP within 2.5 seconds, INP within 200 ms, CLS at most 0.1." Proposing a sensible number shows you know what good looks like.

The questions that change the design most

Some questions matter far more than others, because one answer changes the whole design. Ask those first. A good test: if both possible answers lead to the same design, the question can wait.

Out of scope: say what you will skip

The third list is just as useful. Out of scope is what you and the interviewer agree not to design today: login, the admin panel, payments, server databases. Saying it protects your time and shows you know those parts exist. Without it, a vague prompt grows until it eats the interview.

A: Architecture

Architecture is the big picture: the main parts of the system, what each one is responsible for, and how data moves between them. In a frontend interview it is a drawing of boxes and arrows, and it should fit on half a whiteboard. If it needs the whole board, the boxes are too small.

The boxes most frontend designs share

Most frontend designs, from a widget to a whole app, use the same handful of boxes. Learn them as a starting kit, then rename and add to them for each problem.

• Server or API. Where the data comes from. One box is usually enough. Add a CDN (content delivery network, servers near the user that serve static files and cached responses) if images or scripts matter.
• Data layer or API client. The only part that talks to the network. It builds requests, handles retries and errors, and turns responses into the client's data shape.
• Store or cache. Where the client keeps data it has fetched, so two views showing the same post share one copy. In code this may be a library like TanStack Query, Redux, or a simple context.
• Controller or container. The glue for one feature: it reads from the store, tells the data layer what to fetch, and passes plain data down to the views.
• Views. The components the user sees. Given data and callbacks, they render. They do not fetch.

For each box, say its job in one sentence as you draw it. "The feed store holds posts by ID and the order of IDs for the feed." If you need "and" three times, the box does too much: split it. If two boxes have the same job, merge them.

Client versus server: where does each part run?

A frontend design is mostly about the client, but it must say where the line with the server sits. Two decisions draw that line. First, where the HTML is rendered: on the server for fast first paint and search engines, or in the browser for rich, app-like screens. Second, where the logic sits: filtering 50 items can happen in the browser; ranking a feed of a million posts belongs on the server.

You can also add a thin server that belongs to the frontend team, often called a backend for frontend (BFF). It calls several backend services and returns exactly what one screen needs in one response. Mention it when a screen would otherwise need five requests to draw.

Data flow: draw the arrows with a direction

Arrows matter as much as boxes. Draw them with a direction and say what travels on them. A good default for the client is one-way flow: user events go up from views to the controller, the controller asks the data layer, the data layer updates the store, and the store's new data flows down into the views.

Then add the second kind of flow if the problem has it: data the server pushes without being asked, such as new chat messages over a WebSocket. Draw it as its own arrow into the store, because it arrives at any time and must merge with what is already there.

D: Data model

The data model is the list of things the client knows about, their important fields, and where each piece of state lives. It is short, but it is the step people skip most, and skipping it makes the API and the deep dives vague.

Entities: the nouns of the problem

An entity is a kind of thing with an identity, like a Post, a User, or a Message. Find them by reading your functional requirements and underlining the nouns. Most frontend questions have two to five.

For each entity, list only the fields that drive a decision. A Post has dozens of fields in real life; in the interview, id, author, createdAt, body, imageUrl, and likeCount are enough, because they decide sorting, rendering, image loading, and the like button.

type User = { id: string; name: string; avatarUrl: string };

type Post = {
  id: string;
  authorId: string;      // points to a User, not a copy of it
  createdAt: string;     // ISO date, used for order and "2h ago"
  body: string;          // user text: render as text, never as HTML
  image?: { url: string; width: number; height: number };
  likeCount: number;
  likedByMe: boolean;    // drives the button state
};

type FeedState = {
  postIds: string[];     // the order, from the server
  nextCursor: string | null;
  status: "idle" | "loading" | "error";
};

Where each piece of state lives

This is the part that shows real frontend thinking. The same value behaves very differently depending on where you keep it. There are five common homes, and choosing well removes whole classes of bugs.

Two rules cover most cases. First, keep server state (copies of server data) apart from UI state (what the user is doing right now). They change for different reasons and need different tools.

Second, store shared entities once, by ID, and let lists hold IDs. A store kept this way is called normalized. Then a like on a post updates the feed, the post page, and the profile at the same time, because there is only one copy.

I: Interface

The interface is how the parts talk to each other. In a frontend design there are two kinds. The server API is the contract between the client and the server: requests and responses. The component API is the contract between a component and the code that uses it: props in, events out.

App questions lean on the server API. Component questions, like "design a date picker", lean almost entirely on the component API, because the component may never call a server itself. Know which one your question needs and spend your minutes there.

The server API: one or two calls, done well

You do not need every endpoint. Pick the one or two calls that the hard parts depend on and give each one four things: the method and path, what it sends, what it returns, and how it fails. Name the fields that drive a decision, like the cursor for paging or the version number for conflict checks.

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

200 OK
{
  "posts": [ { "id": "p_9f1a", "authorId": "u_7", ... } ],
  "users": { "u_7": { "name": "Asha", "avatarUrl": "..." } },
  "nextCursor": "p_9e77"   // null when there are no older posts
}

POST /api/posts/p_9f1a/like      -> 204 No Content
DELETE /api/posts/p_9f1a/like    -> 204 No Content

Say why you chose the shape. "Cursor and not page number, because new posts are added at the top while the user scrolls, and page 2 would then repeat posts from page 1." One reason like this is worth more than five extra endpoints.

The component API: props in, events out

For a component, the interface is its props. Group them into three kinds: the data it shows, the events it reports, and the options that change how it looks or behaves. Then decide one key question: is it controlled (the parent owns the value and passes it in) or uncontrolled (the component keeps the value itself)? Good library components support both.

type AutocompleteProps<T> = {
  // data
  fetchSuggestions: (query: string, signal: AbortSignal) => Promise<T[]>;
  getLabel: (item: T) => string;
  // controlled or uncontrolled value
  value?: T | null;
  defaultValue?: T | null;
  // events
  onSelect: (item: T) => void;
  onQueryChange?: (query: string) => void;
  // options
  minChars?: number;     // default 2
  debounceMs?: number;   // default 200
  renderItem?: (item: T, active: boolean) => React.ReactNode;
  label: string;         // required, for screen readers
};

O: Optimizations and deep dives

Optimizations are where the interview is decided. By now you have a design that works. This part shows whether you can make it work well: fast on a cheap phone, usable with a keyboard and a screen reader, safe, and calm when the network fails.

The trap is to list everything you know: "lazy loading, code splitting, memoization, CDN, compression, service workers...". A list like that takes a minute and earns almost nothing, because it shows you have heard of things, not that you can use them. Instead, pick two or three areas and go deep.

The areas to choose from

How to pick the two or three

Pick the areas where this problem is under the most strain. Three questions find them quickly, and each one points back at earlier RADIO steps. That is why the earlier steps matter: they tell you where to dig.

1. Which non-functional requirement is hardest to meet? "5,000 items" points at rendering. "Messages within 1 second" points at the push channel and reconnects. "Works offline" points at storage and sync.
2. What is special about this problem? Every app needs loading states. Only an autocomplete has out-of-order responses on every keystroke; only an editor has two people typing in the same place. The special part is the most interesting deep dive.
3. What is the interviewer hinting at? If they asked twice about mobile, or said "lots of users", they are telling you what they want to score. Follow the hint.

The shape of a good deep dive

A deep dive is a small story, and it has the same five beats every time. Practise them until they are automatic. With two or three deep dives in about 15 minutes, each beat gets about a minute.

1. The problem, with a number. "Rendering 5,000 post cards creates about 200,000 DOM nodes, and scrolling janks on a mid-range phone."
2. The options. "Paginate with a Load more button, use content-visibility: auto, or virtualize the list."
3. Your choice and why. "Virtualize, because the feed is endless and we need steady memory."
4. How it works, briefly. "Render only the rows in view plus a few above and below, measure each row once, and keep scroll position when new posts load."
5. The cost and how you'd check it. "Find-in-page and screen readers can't see unrendered rows, so I'd keep aria-setsize and aria-posinset on each row. I'd check with a performance trace on a throttled phone."

Adapting RADIO to component and app questions

Frontend design questions come in roughly three sizes, and RADIO bends to each. A component question asks for one reusable piece of UI: an autocomplete, a modal, a date picker, an image carousel. An app question asks for a whole product: a news feed, a chat app, an email client. A feature question sits in between: a comment section, a notification bell, a checkout form inside a bigger site.

The five letters stay the same. What changes is how much time each one gets and what you draw for it. Spot the size in the first minute, because it tells you where to spend the next 40.

Component questions: think like a library author

For a component, your user is two people: the developer who drops it into their app, and the person who clicks it. The developer cares about the props, how to style it, how big it is, and whether it works with their state. The end user cares about keyboard support, screen readers, touch, and speed.

So the Interface step becomes the centre of the design, and accessibility is almost always one of your deep dives. A good check: could another team use your component without reading its source? If the answer needs "well, you'd have to...", the API needs work.

App questions: think like a tech lead

For an app, the challenge is breadth. There are more parts, more data, and more ways to fail, and you will not cover them all. Requirements must cut scope hard, Architecture must show the whole system in one picture, and the deep dives pick the two or three places the app is under strain.

App questions also bring up decisions that component questions never do: how pages are rendered (server or client), how routes are split into bundles, how the store is shaped across features, and how the client gets updates. You do not need to deep dive all of them, but you should name your choice for each in a sentence.

Driving the conversation, and the mistakes that sink people

An interviewer can only score what they hear and see. A great idea you keep in your head counts for nothing. So the skill here is not only designing, but designing out loud in a way that is easy to follow and easy to steer.

Good candidates drive. They say where they are going, check in at the end of each part, and invite the interviewer to redirect them. The interviewer becomes a teammate in a design review, not an examiner waiting for mistakes.

The loop: propose, explain, check in

Each RADIO part runs through the same small loop. You propose something concrete, explain the reason and the main trade-off, then check in. If the interviewer agrees, you move on; if they push back or hint, you adjust and loop again. The check-in is one sentence, not a request for permission.

Phrases that do real work

Taking hints

Interviewers drop hints when they want you somewhere else. "Interesting, and what if the user is on a train?" means "talk about offline and flaky networks". "How would that feel with 10,000 rows?" means "talk about rendering performance". Treat each question as a direction, not a test of your first answer.

When a hint shows your design has a hole, say so plainly and fix it: "Good point, my current design would re-render every row on each like. Let me change the store so each row subscribes only to its own post." Changing your mind with a reason is a strong signal. Defending a weak choice is a weak one.

Mistakes that sink good candidates

• Designing before asking. Answering the wrong question well scores worse than answering the right question roughly.
• Going silent. Long pauses leave the interviewer with nothing to score. Think out loud: "I'm weighing pagination against virtualization..."
• Using RADIO as a script. Reading out headings and filling each one equally sounds rehearsed and wastes time on easy parts.
• Listing instead of choosing. Naming ten techniques is not a design. Pick one, say why, and name its cost.
• Designing the backend. Twenty minutes on database sharding in a frontend interview is twenty minutes not spent on what they came to score.
• Only the happy path. No loading, empty, error, or offline states. Real products spend much of their code on these.
• Buzzwords you can't defend. If you say "islands architecture" or "CRDT", expect a follow-up. Only use terms you can explain in two sentences.
• Ignoring the clock. Reaching deep dives at minute 38 leaves no room for the part that decides the level.

A worked example: "Design a search autocomplete"

Let's run the whole framework on one small question, with the minute marks, so you can see how the parts connect and how little time the basics need. The prompt: "Design the search box with suggestions for our online bookshop." The step-through below follows the same run.

Minutes 3 to 7: requirements

The candidate asks five questions and writes down the answers. It is a feature in the shop that should be reusable later, and it suggests book titles and authors, up to 8.

Half the traffic is mobile. Speed is left to the candidate ("you decide"), and the interviewer asks them to assume the site must meet WCAG AA.

• Functional: show up to 8 suggestions as the user types; pick one with mouse, touch, or keyboard; pressing Enter with no pick runs a full search.
• Non-functional: suggestions within 400 ms after typing stops on 4G; no flicker or wrong results; full keyboard and screen reader support; under 10 KB of gzipped JavaScript.
• Out of scope: the search results page, the ranking algorithm on the server, spelling correction.

Minutes 7 to 12: architecture

Four boxes. The input reports what the user types. A controller debounces typing (waits until typing pauses), checks a small cache, and calls the suggest API through a data layer. A listbox popup shows the results.

Data flows one way: keystrokes go up to the controller, suggestions come down to the popup. The server is one box labelled "suggest API, behind a CDN".

Minutes 12 to 20: data model and interface

The state is small: query, items, activeIndex (which suggestion is highlighted, or -1), isOpen, and status (idle, loading, error). A cache maps each query to its items, keeps the last 50, and drops the oldest first. The query does not go in the URL; the results page will put it there.

GET /api/suggest?q=harr&limit=8

200 OK
Cache-Control: public, max-age=300

{ "query": "harr",
  "items": [ { "id": "b_101", "label": "Harry Potter and the...", "kind": "book" },
             { "id": "a_42",  "label": "Harriet Evans", "kind": "author" } ] }

The component API takes fetchSuggestions, onSelect, label, and an optional renderItem, as in the interface chapter. The candidate says one sentence on why fetchSuggestions receives an AbortSignal: so old requests can be cancelled.

Minutes 20 to 40: three deep dives

The candidate proposes three deep dives, and the interviewer agrees. Each follows the five beats from the optimizations chapter: problem, options, choice, how it works, cost.

1. Request count. Typing "harry potter" is 12 keystrokes, which could be 12 requests. A 200 ms debounce plus a 2-character minimum and the cache usually cut it to 2 or 3. Cost: 200 ms of added delay, which leaves about 200 ms for a request served from the CDN and still fits the 400 ms target.
2. Out-of-order responses. The response for "har" can arrive after the one for "harr" and overwrite it. Fix: abort the old request with AbortController, and also drop any response whose query does not match the current input. Cost: almost none.
3. Accessibility. Use the combobox pattern from the WAI-ARIA Authoring Practices (the W3C guide to accessible widgets): the input has role="combobox", aria-autocomplete="list", aria-expanded, and aria-controls pointing at a role="listbox" of role="option" items; arrow keys update aria-activedescendant to the highlighted option, so focus stays in the input; Escape closes; a polite live region says "8 suggestions". Cost: careful testing with a screen reader such as VoiceOver or NVDA.

Just before minute 40, the candidate names what they would do next: highlight the matched letters using text nodes, never innerHTML, so a book title cannot inject script; and keep the popup inside the viewport on small screens. Then they sum up in one sentence. Notice that no step was skipped, yet the basics took 17 minutes and the deep dives took 20.