Elegant

What frontend interviews actually measure

The Elegant team 5 min readinterview
What frontend interviews actually measure

A frontend interview can feel like a random quiz, but it is not. Each round is designed to probe a specific axis of competence, and the questions are just vehicles for measuring it. Knowing which axis a round is testing is half the battle, because it tells you what the interviewer is actually listening for — and lets you supply that signal on purpose instead of hoping your code speaks for itself. The four axes recur across companies: can you recall and wield the platform’s APIs, can you build a correct interactive component, can you model state cleanly, and can you reason about trade-offs at the system level.

The four axes an interview measures and the signal each one wants Four axes — API recall, UI construction, state modelling, trade-off reasoning — each paired with what the interviewer is listening for. API recallclosures, events,promises"do you know the platform" UI constructionbuild a widget,keyboard + a11y"can you ship correct UI" state modellingshape, transitions,no impossible states"can you tame complexity" trade-offsCSR vs SSR,cache vs fresh"can you decide"
Each round targets one axis and listens for one kind of signal. Name the axis and you know what to make loud.

Axis one and two: recall and construction

The API recall round hands you a small implementable problem and watches whether you know the language and platform well enough to build without a reference — and whether you find the edge cases:

// they're measuring: do you reach for the right primitive, and do you see the edges?
function once(fn) {
  let called = false, result;
  return (...args) => {
    if (!called) { called = true; result = fn(...args); }  // the edge: memoise the result
    return result;                                          // subsequent calls return it
  };
}

The UI construction round measures whether you can build a correct interactive component — and “correct” secretly includes keyboard operation, focus, and ARIA, not just the pixels. Supply that signal by building the invisible half out loud.

Axis three: state modelling

The state modelling axis is where senior signal concentrates. The interviewer watches how you shape state — whether you avoid impossible combinations, derive instead of duplicate, and keep the shape minimal. Reaching for a status enum over a pile of booleans is exactly the signal they want:

// weak signal: four booleans, most combinations invalid
// strong signal: one status the impossible states can't be expressed in
const state = { status: "idle", data: null, error: null };  // idle|loading|success|error

Modelling state well under time pressure is hard to fake, which is why this axis carries so much weight.

Axis four: trade-off reasoning, and using the map

The trade-off axis (usually the system-design round) has no right answer by design; it measures whether you can name a tension, pick a side, and defend it — CSR versus SSR, cache versus freshness, normalise versus embed. The practical payoff of knowing the four axes is that you stop treating every round the same. In the recall round, narrate edge cases; in the construction round, make accessibility audible; in the modelling round, justify your state shape; in the design round, talk trade-offs, not boxes. You are being scored on a specific axis each time, so supply that axis’s signal deliberately. The normalize-entities and accessible-combobox exercises drill the modelling and construction axes respectively, and design-search-experience is a rehearsal for the trade-off round.