Summary
RADIO is a repeatable scaffold for any frontend system design round. It forces you to scope before you build, propose a component architecture, define the data that flows through it, design the APIs between pieces, and only then optimize. Following it keeps a 45-minute interview from sprawling.
Jump to the interview angleRADIO
Requirements → Architecture → Data model → Interface (API) → Optimizations. A repeatable scaffold for any frontend system design round: scope before you build, then spend the most time where it counts. Following it keeps a 45-minute interview from sprawling.
The five stages
- 1
Requirements (~15%)
Clarify functional scope, non-functional needs (performance, a11y, i18n, devices), and constraints. Restate them, get agreement, and call what's out of scope.
- 2
Architecture (~20%)
Sketch the component tree and major boxes (client, BFF, services). Name responsibilities and how components compose. This is where you draw.
- 3
Data model (~15%)
Define entities, fields, and which component owns vs renders each. Separate server state from client/UI state.
- 4
Interface / API (~15%)
Specify the contracts: the network API (endpoints, shapes, pagination) and the component API (props/events).
- 5
Optimizations (~35%)
Performance (CWV, virtualization, code-splitting), accessibility, error/loading/empty states, and the interviewer's follow-ups. Where seniority shows.
Scope as a checklist
Model requirements as data in the first five minutes — it's the artifact you confirm before drawing a single box.
type Requirements = {
functional: string[]; // "infinite scroll", "like a post"
nonFunctional: {
performance: string; // "60fps scroll, LCP < 2.5s on 4G"
a11y: string; // "WCAG 2.2 AA, screen-reader feed"
offline?: string; // "read cached feed offline"
};
outOfScope: string[]; // say it out loud: "auth, search — skipping"
};The outOfScope line is the highest-signal sentence in the round — it proves you can prioritize.
Reallocate, don't recite
Treat the percentages as defaults, then shift time to whatever the interviewer probes. Reciting the acronym mechanically reads as junior — keep it invisible scaffolding.
Interview angle
Interviewers use RADIO (or a variant) as the hidden rubric, so mapping your answer onto it raises your score. They probe two things: can you scope (ask about scale, devices, a11y first) and can you prioritize (spend time where it matters).
Soundbite: "Scope with RADIO — requirements, architecture, data, contracts — then spend most time on optimizations and the deep dive they care about."
Key terms
- Functional requirements
- What the user can do — the features in scope.
- Non-functional requirements
- Qualities the system must have: performance, accessibility, i18n, offline, device support.
- Deep dive
- A focused exploration of one sub-problem (e.g. infinite scroll) where you demonstrate depth.