Frontend Developer Interview Guide

Frontend interviews suffer from an identity crisis, and that's actually useful to know: different companies mean wildly different things by "frontend." One wants a JavaScript language lawyer. Another wants someone who can build a polished UI from a blank page in ninety minutes. The strongest candidates prepare for both — fundamentals deep enough to survive the trivia, and building skills sharp enough to ship on demand.

The core idea: Frontend engineering is state management over time — user input, async data, and rendering, all racing each other. Interviews test whether you can keep that race coherent.

The question taxonomy

• JavaScript, deeply. Closures, the event loop, this, prototypal inheritance, promises and async/await. Framework knowledge cannot paper over gaps here.
• Framework fluency. Usually React — hooks, rendering, state architecture. The React guide goes deep.
• Browser and rendering. The critical rendering path, reflow vs repaint, debouncing, lazy loading.
• CSS, honestly. Layout (flexbox/grid), specificity, responsive design. Many candidates bluff here and it shows within minutes.
• Build-a-thing. Autocomplete, modal, data table, or a small app — timed, with an interviewer watching.

Worked example: the event loop question

"What does this log, and in what order?" The classic — and the explanation matters more than the answer:

console.log('1');

setTimeout(() => console.log('2'), 0);

Promise.resolve().then(() => console.log('3'));

console.log('4');

// Output: 1, 4, 3, 2
// Sync code runs first (1, 4), then the microtask queue
// drains (promises: 3), then macrotasks (setTimeout: 2).

The follow-ups separate the prepared from the lucky: What happens if the promise handler itself schedules a timeout? Why does this matter for UI freezes (long synchronous work blocks everything)? Where does requestAnimationFrame fit? Practise explaining the why, not just reciting the order.

How answers get scored

In build-a-thing rounds, rubrics reward: a working result first, then polish — keyboard accessibility, loading and error states, and no unnecessary re-renders. In fundamentals rounds, explaining trade-offs (debounce vs throttle, controlled vs uncontrolled inputs) matters more than definitions. Accessibility knowledge has become a genuine differentiator; mentioning semantic HTML and ARIA unprompted marks you as a professional.

Common mistakes

• Explaining closures as "a function inside a function" without the crucial part: it captures its outer scope's variables by reference.
• Mutating arrays or objects in state and wondering why the UI doesn't update.
• Building for the happy path only — no loading state, no empty state, no error state.
• Memorising framework APIs while being unable to debounce an input in vanilla JavaScript.

Performance questions: answer with a measurement story

"The page feels slow — what do you do?" Weak answers list techniques: code splitting, lazy loading, memoisation. Strong answers start with measurement: which metric is hurting — time to first byte, largest contentful paint, interaction latency? Then a diagnostic order: network waterfall for slow assets and oversized bundles, long tasks on the main thread for scripting bottlenecks, layout thrash for janky scrolling. Only then the fixes, matched to the measured cause. Interviewers grade the sequence because it mirrors real work: optimising without measuring is guessing, and saying so out loud demonstrates you've actually chased a slow page before. Keep one honest story ready — a real performance problem you found, how you measured it, what you changed, and how you verified the improvement. One concrete story outweighs a catalogue of techniques every time, because it's proof rather than vocabulary.

FAQ

Vanilla JS or framework questions? Both. Framework questions dominate at product companies; vanilla JS questions are the filter everywhere. You cannot skip the fundamentals.

Do I need to know build tools and performance profiling? Conceptually, yes — bundling, code splitting, and reading a flame chart come up regularly for mid-level and above.

See the full picture in the full-stack tips, and build components under time pressure with Aissence's coding copilot.