There's a predictable mismatch in frontend interviews. Candidates spend their preparation on the framework they use every day, and then lose the loop on the layer underneath it — the language, the box model, the browser.
It makes sense: your framework is what you touch daily, so it feels like the thing you're being hired for. But interviewers already assume you can use React. What they're checking is whether you understand what it's doing on your behalf.
| Where preparation usually goes | Where the loop is actually decided |
|---|---|
| Framework APIs and hook rules | Closures, this, and the event loop |
| Component patterns | Why the cascade picked that rule, and what made a stacking context |
| State management libraries | What the browser does between your code and a painted pixel |
| Building the happy path fast | Keyboard access, focus, and what happens on a slow connection |
That's the shape of this list. The framework section is here, but it's deliberately not first.
JavaScript fundamentals
The filtering round. Asked at every level, and where most rejections happen.
- Explain closures — and tell me somewhere you've actually used one.
- What is the event loop? Walk me through what happens with a
setTimeoutof zero. - What's the difference between
==and===, and where does coercion surprise people? - What is
thisbound to, and how do arrow functions change that? - What is event delegation, and why does it matter on a large list?
Saying it out loud: question 1 has a textbook answer that everyone gives and nobody gets credit for. The half that actually scores is the second half of the question — the part most candidates don't register as part of the question at all.
The definition alone
“A closure is a function that has access to variables in its outer scope, even after that outer function has returned.”
Correct, and identical to what the previous four candidates said. The interviewer learns nothing about you and moves on.
Definition plus a scar
“…and I got bitten by it once — I built handlers in a loop with var, so every one of them closed over the same variable and they all fired with the last value.”
Now they know you've written closures, not read about them. Ten extra seconds, completely different signal.
CSS and layout
The round frontend candidates skip in preparation and then fumble. Asked at every level.
- How does the cascade decide which rule wins?
- Flexbox or Grid — when do you reach for each?
- What creates a new stacking context, and why does
z-indexsometimes do nothing? - How would you build a responsive layout without a single media query?
Saying it out loud: question 8 is a favourite because it separates people who've fought a real layout bug from people who've only read specs. Answer it as a debugging story, not a spec recital: "Usually it's that the element is in a different stacking context than you think — a parent has a transform, or an opacity below one, or a filter, and any of those create one. So your z-index of 9999 is competing inside that parent, not against the page." The list of things that create a context is the knowledge; naming why the 9999 didn't work is the experience.
The browser and performance
Middle to Senior. Increasingly common as Core Web Vitals became a business metric.
- What happens between a user typing a URL and seeing the first pixel?
- What is layout thrashing, and how do you avoid causing it?
- A page feels janky while scrolling. How do you diagnose it?
- Debounce or throttle — what's the difference, and when do you use each?
Saying it out loud: question 10 is enormous, and the mistake is trying to cover all of it. Scope out loud first: "I can go from DNS all the way down, or focus on the rendering side — which is more useful to you?" Then, if they let you pick, go where you're strongest. Interviewers ask deliberately broad questions to see whether you can manage scope; a candidate who talks for six minutes and never arrives anywhere scores worse than one who asks and then goes deep on one thing.
A pattern worth noticing: questions 8 and 12 reward narrating a debugging process, and question 10 rewards narrating how you'd scope one. Either way it's the same underlying test — can you think out loud in a structured way, rather than recite a fact? Frontend loops lean on this hard, because most of the job is working out why something renders wrong, not writing new code.
Framework questions
Where preparation usually starts. Weighted less than candidates expect.
- What actually causes a re-render, and how do you stop the unnecessary ones?
- Why can't hooks be called conditionally?
- How do you think about server state versus client state?
- When is client-side rendering the wrong choice?
Saying it out loud: question 14 rewards precision over enthusiasm. The weak version lists optimisation APIs by name; the strong version starts from the cause: "A component re-renders when its state changes, its parent re-renders, or its context value changes. Most unnecessary renders I've seen come from the second one — a parent re-rendering and passing a new object or callback identity every time. So I'd look at what's being recreated before reaching for memoisation, because memoising around an unstable prop just adds cost." Naming the cause before the fix is what makes it sound like judgment instead of a checklist.
Accessibility and the live coding round
A11y shows up at every level now. The live round is where nerves do the most damage.
- What do you actually check for accessibility — concretely?
- How do you make a custom dropdown usable with a keyboard?
- In a live coding round: what do you do when you get stuck?
Saying it out loud: question 20 is often not asked directly — it's observed. Getting stuck in a live round is normal and expected; going silent while stuck is what damages you, because the interviewer loses all visibility into your thinking and can't help. The move is to narrate the stuck-ness itself: "Okay, I'm blanking on the exact API here. What I'm trying to do is debounce this so it only fires after the user stops typing — let me write the shape of it and come back to the exact method name." You've kept them with you, and you've shown you know what you're reaching for even when the name won't come.
Practical target: for the fundamentals rounds, prepare one scar per topic — a closure bug, a z-index fight, a scroll performance problem you traced. Definitions are free and everyone has them. Stories are the only part of your answer another candidate can't also give.
The round that punishes silence
Frontend is unusual among engineering loops in how much of it happens live and out loud — a shared editor, someone watching, and a question you half-know while your working memory is busy with the language you're speaking.
That's the exact condition under which people blank. It isn't a knowledge problem, and preparing more facts doesn't fix it. We wrote about what's actually happening and how to recover in Why your mind goes blank during interviews.
The practical version: take three questions from this page and answer them out loud, at speaking pace, without writing anything first. The ones where your explanation falls apart out loud — but felt clear in your head — are exactly the ones to work on.
