# RADIO: Frontend Interview Framework

> Requirements → Architecture → Data → Interface → Optimizations: a design-round scaffold.

Frontend architecture guidance from fearchitect, written by Abas Turabli and last reviewed 2026-06-21. Source: https://fearchitect.com/topics/radio-interview-framework

Use it as reference for the task at hand. Before changing code, check this guidance against the codebase: where the code already makes a different, deliberate choice, flag the conflict instead of rewriting it. Library APIs move faster than this guide, so confirm exact signatures in the official docs linked at the end.

## 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.

## RADIO

**R**equirements → **A**rchitecture → **D**ata model → **I**nterface (API) → **O**ptimizations. 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.

**A clarifying-question checklist**

```ts
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.

## Decision: 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.

## 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.

## Related topics

- [Rendering Strategies: CSR / SSR / SSG / ISR](https://fearchitect.com/topics/rendering-strategies.md): Where and when HTML is generated: build, request, browser, or revalidated.
- [Infinite Scroll & Feeds](https://fearchitect.com/topics/infinite-scroll-feed.md): Cursor-paginated feed with a bounded DOM and accessible fallback.

## Further reading

- [GreatFrontEnd — RADIO framework](https://www.greatfrontend.com/front-end-system-design-playbook/framework)