Elegant

How to prepare for a frontend interview without boiling the ocean

The Elegant team 5 min readcareer
How to prepare for a frontend interview without boiling the ocean

Most people prepare for a frontend interview by grinding random problems and hoping the overlap is enough. It rarely is, because a frontend loop is not one skill — it is a small set of distinct rounds, each testing a different muscle. Prepare against the structure of the loop rather than a pile of problems, and the work becomes finite and legible: figure out which rounds you will face, and drill the specific thing each one measures. That turns “study everything” into a short, targeted list, which is the difference between preparation that fits in two weeks and preparation that never feels done.

The four rounds of a frontend loop and the muscle each drills Four boxes — JS utilities, UI component, system design, behavioural — each labelled with the skill it tests and how to practise it. JS utilitydebounce, curryrecall + edge cases UI componentcombobox, tabsbuild + a11y system designa feed, a searchtrade-offs behaviouralconflict, impactstories (STAR) prepare per round — each drills a different muscle
Four rounds, four muscles. Preparing against this structure — not a random problem pile — is what makes the work finite.

Map your loop, then drill per round

Before grinding, find out the loop’s shape — recruiters will usually tell you. Then assign practice per round rather than in general. For the utility round, drill the classic implementable primitives until they are muscle memory, edge cases included:

// the kind of thing the utility round wants — write it, then handle the edges
function debounce(fn, wait) {
  let t;
  const debounced = (...args) => { clearTimeout(t); t = setTimeout(() => fn(...args), wait); };
  debounced.cancel = () => clearTimeout(t);   // the edge case that scores: cancellation
  return debounced;
}

For the component round, practise building an accessible widget end to end — not just the visible part but the keyboard and focus behaviour, because that is where these rounds are won.

Practise output under a clock, not just input

The biggest preparation mistake is passive input — reading solutions and nodding — when the interview tests output under time pressure. Simulate it: set a timer, build the thing from an empty file, and only then compare to a reference. A rough schedule that respects the round structure:

Week 1  utilities: debounce/throttle, curry, deepClone, EventEmitter, promise pool
Week 2  components: combobox, tabs, modal, data table — build each timed, a11y included
Week 3  system design: 3 features (feed, search, chat) — practise the trade-off talk
Ongoing behavioural: 6 STAR stories written out, one per common theme

The point is coverage of rounds, not volume of problems.

Don’t neglect the two rounds people skip

Two rounds get under-prepared because they feel un-drillable, and both are learnable. System design has no right answer, so candidates freeze — but the score is your reasoning, so practise narrating trade-offs (CSR vs SSR here, and why) rather than memorising an architecture. Behavioural gets waved away as “just talking,” but a rambling answer to “tell me about a conflict” sinks strong engineers; write six concrete stories in STAR form ahead of time. Prepare against the four rounds, drill output under a clock, and cover the two everyone skips, and you have a plan that ends — rather than an ocean you keep bailing. The debounce-utility and accessible-combobox exercises are the highest-yield reps for the first two rounds, and design-search-experience is a full system-design rehearsal.