Frontend Developer Interview Questions — The Five Types That Keep Coming Up, and How Deep to Go

Five: JavaScript internals, browser rendering, state and re-renders, performance, and CSS layout. On top of those sits a deep-dive into whatever is on your resume, plus live coding or a take-home review depending on the company. The questions converge on those five because of what the job is: you build screens on devices and networks you don't control, inside a runtime someone else wrote. Interviewers check whether you write code knowing what the browser does underneath — which is why you get far more 'how does this work' questions than 'how do you use this library' questions.

How the coding portion is run varies by region. In a January 2026 survey of 400 engineering leaders across the US, India, and China, technical interview platform Karat found live technical interviews used by 79% of US organizations and 87% of Chinese ones, automated code tests by 63% in the US versus 49% in China, and take-home projects by 45% in the US against 20% in China. Read the company's process description before deciding where your practice hours go.

So instead of growing your list of expected questions, attach one piece of your own code to each type. A bug caused by async ordering for the event loop. A wasted re-render you tracked down for state. A before-and-after pair of numbers for performance. Answers with a case behind them survive two or three follow-ups; answers without one stop at the first.

The stack questions layered on top follow the team you're applying to. In Devographics' State of JavaScript 2025 survey, of the 10,934 respondents who answered the JavaScript-versus-TypeScript question, 4,367 (about 40%) said they write all of their code in TypeScript, while 661 (about 6%) write plain JavaScript only. If TypeScript is in the posting, generics and narrowing aren't bonus points — they're the baseline.

Until three slots are full: a one-line definition, why it behaves that way, and a case you personally hit. Leave the third slot empty and even a correct definition sounds memorized.

The event loop is the standard example. Start from why a single-threaded language can do async work, walk through the call stack, the task queue, and the microtask queue, and land on why `setTimeout(fn, 0)` and `Promise.then()` don't run in the order people expect. Follow-ups arrive as 'so which queue does `async/await` use' and 'where does rendering fit between them.' Wherever you stall is your study list.

Closures land better as usage than as definition. After the one line — a function remembers the scope it was created in — explain why that keeps things alive in memory, then bring up the bug where an event handler held onto a stale state value. Prepare `this` binding, the prototype chain, and shallow versus deep copy the same way.

What to avoid is keyword recitation. 'Hoisting moves declarations to the top' collapses under one question: 'are `let` and `const` hoisted too?' Fewer topics you can explain down to why the language was designed that way beat a long list you can only name.

If you can answer 'when and why does this screen get drawn again' in one sentence, most of this type is covered. Browser rendering and framework re-rendering are different layers, and interviewers often chain them together.

At the browser layer, be able to walk the pipeline out loud: DOM and CSSOM, render tree, layout (reflow), paint, composite. The reliable follow-up is 'why animate with `transform` instead of `top` and `left`?' The answer — changing `top` forces layout to be recalculated, while `transform` and `opacity` only touch compositing — gets stronger if you attach the janky scroll you actually fixed with it.

At the framework layer, the questions are what triggers a re-render (state change, parent re-render, a new context value) and how you cut them down (memoization, moving state down to the component that uses it, stable list keys). `useEffect` gets probed hardest. React's own docs, in 'You Might Not Need an Effect,' put it flatly: "If there is no external system involved (for example, if you want to update a component's state when some props or state change), you shouldn't need an Effect." Draw that line — values you can compute during render versus values that genuinely need to sync with an external system — and this whole family of questions sorts itself out.

State management library questions are about your reasoning, not the API. 'Why Redux here?' 'Why did server data end up in global state?' 'How would you split it today?' Having your own working distinction between server state and client state is what carries this axis.

The Core Web Vitals thresholds, plus one before-and-after pair you measured yourself. Google's web.dev documentation sets them at the 75th percentile of field data: LCP within 2.5 seconds, INP at or below 200 milliseconds, CLS at or below 0.1. The INP docs define the metric as "a metric that assesses a page's overall responsiveness to user interactions."

It's worth knowing how few sites clear that bar. The performance chapter of the 2025 Web Almanac, built by HTTP Archive on July 2025 CrUX data, found 48% of mobile sites and 56% of desktop sites passing all three. On mobile, LCP was the drag at 62% rated good, against 77% for INP and 81% for CLS. Asked which metric you'd look at first, naming LCP with that reasoning behind it is a solid answer.

Structure the answer as diagnosis, action, measurement. 'I reduced the bundle size' is weak. 'The LCP element was the hero image, so I preloaded it and switched formats, taking it from 4.1 to 2.3 seconds' is strong. If you don't have numbers, run Lighthouse or the DevTools Performance panel this week and get some.

Follow-ups arrive as trade-offs. 'You code-split and the first paint got faster, but navigation got slower — now what?' 'What breaks if you lazy-load every image?' Almost every performance fix trades one thing for another, so naming only the gain and not the cost reads as shallow.

Deep enough to explain why a layout resolves the way it does. Whatever the framework doesn't write for you becomes the question. In the 2025 Stack Overflow Developer Survey, among respondents who answered the technology-use question, 61.9% reported using HTML/CSS — second only to JavaScript at 66%, and ahead of TypeScript at 43.6%. Framework generations turn over; this layer stays.

The recurring questions are a narrow set: the box model and `box-sizing`, what each `position` value is positioned against, why `z-index` isn't working (stacking contexts), how you choose between flex and grid, margin collapsing, and media queries versus container queries for responsive work. More teams now add accessibility — semantic markup, focus order, color contrast.

The trick is to answer with your diagnostic process. The right answer to 'what do you do when `z-index` doesn't work' isn't a bigger number — it's 'I check in DevTools whether an ancestor created a stacking context with `transform`, `opacity`, or `filter`.' What's measured is where you start looking when the screen doesn't match the intent.

On the browser side, event bubbling and capturing, event delegation, and CORS come up constantly. Don't stop CORS at 'the server didn't send the right headers' — carry it through to when a preflight is triggered and how you worked around it with a dev proxy.

Juniors are asked whether they know it, mid-levels why they did it that way, and above that what they gave up. The wording of the question barely changes; the bar for passing does.

For entry level, it's fundamentals plus the project deep-dive. Answer the internals questions precisely, and justify the technology choices in what you built. Project scale isn't the bar — even a clone project works as material if you have 'what I implemented differently from the original and why' and 'where I got stuck and how I got out.'

One to three years in, questions move to problems you hit in production: how you reproduced an incident and narrowed the cause, what you gave and got in code review, in what order you touched legacy code. 'That's how the team decided to do it' is a dangerous answer here — even if you weren't in the decision, explain how you understood it. Past four years, it's design judgment and blast radius: why the state architecture is split the way it is, what criteria pulled something into a shared component, how you set and held a performance budget. There, naming what you gave up matters as much as naming why you chose it.

One axis has grown recently regardless of level: whether you can explain code an AI tool wrote. In the same Karat survey, 71% of the 400 engineering leaders said AI is making it harder to assess candidates' technical skills, and 62% of their organizations still prohibit AI use during technical interviews. Whatever produced the code, not being able to explain why it's structured that way shows up immediately in the room.

Four slots: conclusion, mechanism, your case, trade-off. A re-render question runs as 'the first move is pushing state down to whoever uses it (conclusion) — because a parent re-render redraws its children (mechanism) — on a list screen I moved filter state into the item component and cut render counts (case) — the cost was scattered state that's harder to trace, so I kept only widely shared values up top (trade-off).'

Week one (D-14 to D-8) is for building material. Pull about six expected questions per type, thirty total, and match each to a piece of your own code. The questions where nothing attaches are your weak spots, exactly. If you have no performance numbers, measure this week, and build a why-alternatives-result Q&A for every technology on your resume.

Week two (D-7 to D-3) is for saying it out loud. Take one type per day and answer each question three times aloud — concepts that felt solid while reading will refuse to come out of your mouth, and that gap is the point. The catch with practicing alone is that no follow-up ever comes; a tool like preterview, which runs a spoken back-and-forth and turns it into a report, lets you repeat the same question until the answer is smooth, and signing up includes one free pass — a portfolio review's worth — so you can see the output first. Treat any AI's technical judgment as a reference and verify facts against MDN and the framework's own docs.

The last two days (D-2 to D-1) are for doing nothing new. Touching a new concept now only adds anxiety. Polish the five answers that stalled you, then open the company's product and poke at it in DevTools — what framework it runs, how images load. Ten minutes there usually produces a question worth asking them.