Frontend interview questions you'll actually get in 2026

You can probably answer most of these questions in your head. That’s not the problem. The problem is that knowing the answer and being able to say the answer clearly, under pressure, in 60-90 seconds — those are two different skills. And the second one is what actually gets tested in interviews.

What follows are 15 frontend questions you’re likely to encounter in 2026, organized by category. For each one: what the interviewer is probably evaluating, a rough structure for a verbal response, and the mistakes that sink candidates.

This isn’t a 100-question dump. It’s opinionated, built for speaking out loud.

JavaScript fundamentals

These never go away. Frameworks change; the language stays. I’ve seen interviewers at every level of company still ask these because they reveal how deeply you actually understand the tools you use daily.

1. “Explain the difference between let, const, and var.”

This one feels like it should be easy, and that’s the trap. Most candidates say “var is function-scoped, let and const are block-scoped” and stop there, which is technically fine but doesn’t show much.

The thing that actually trips people up: const doesn’t mean the value can’t change. It prevents reassignment. You can still push to a const array, mutate a const object. If you get this wrong, the interviewer will push on it, and then you’re flustered for the next question.

Start with scope (block vs function), give one concrete example — var inside a for loop leaking — mention hoisting and the temporal dead zone, close with your default: “const by default, let when reassignment is needed, var never.” About 60 seconds.

2. “What is the event loop? How does it work?”

This separates people who’ve debugged race conditions from people who’ve only read about promises.

Start concrete: “JavaScript is single-threaded, so it uses an event loop to handle async operations without blocking.” Name the pieces: call stack, Web APIs (or Node APIs), callback queue, microtask queue. Walk through one example — setTimeout(() => console.log('a'), 0) followed by Promise.resolve().then(() => console.log('b')) — and explain why b prints first. The microtask queue drains completely before the next macrotask runs.

The mistake that immediately flags you: forgetting the microtask queue entirely. If you only talk about “the callback queue,” the interviewer knows your mental model has a hole in it. Promises, queueMicrotask, and MutationObserver callbacks all go through microtasks. About 90 seconds for this one.

3. “Explain closures. When would you use one intentionally?”

They don’t want the textbook definition. They want to see if you recognize closures in real code.

Define it in one sentence: “A closure is a function that retains access to variables from its outer scope even after that outer function has returned.” Give a use case: a factory function like createCounter() that returns an object with increment and getCount methods sharing a private count variable. Then mention where closures bite you: stale closures in React useEffect when dependencies aren’t listed correctly.

The mistake here is giving the definition and stopping. The interviewer asked “when would you use one” — skip the second half and you look like you memorized without understanding.

For more on structuring answers about React-specific concepts, see how to explain React hooks in interviews.

4. “What’s the difference between == and ===? When would you ever use ==?”

The sneaky part is the second question. Most candidates say “never,” which is technically a safe answer but shows you’ve absorbed a linting rule without understanding why it exists.

=== checks value and type, == coerces types before comparing. "5" == 5 is true, "5" === 5 is false. The honest answer about when to use ==: checking for null or undefined simultaneously — value == null catches both, which is cleaner than value === null || value === undefined. Strict equality everywhere, with the null check as the one exception you’ll defend. 45 seconds.

React and framework questions

React still dominates frontend interviews in 2026. Even companies using Vue, Svelte, or Solid will often ask React questions because it’s the common denominator.

5. “Walk me through what happens when state changes in a React component.”

The first 30 seconds of your answer here really determine whether the interviewer sees you as junior or mid-level.

State update is scheduled, not synchronous — React batches updates. React triggers a re-render of the component and its children. During re-render, the component function runs again, producing a new virtual DOM tree. React diffs the new tree against the previous one (reconciliation). Only the diffed changes are applied to the actual DOM. Worth mentioning that React 18+ batches updates across event handlers, timeouts, and promises — this wasn’t always true.

If you say state updates are synchronous, you’re done. They’re not. If you setState and then immediately read the state variable, you’ll get the old value. This is one of those things where a lot of developers use it correctly but explain it incorrectly.

6. “When would you use useRef instead of useState?”

useState triggers a re-render when updated; useRef doesn’t. That’s the whole thing. Use useRef for values you need to persist across renders but that don’t affect the UI: timer IDs, previous values for comparison, DOM element references. A concrete example: storing an AbortController for a fetch request so you can cancel it on unmount without causing unnecessary re-renders.

Only mentioning DOM refs is the common trap. Yes, useRef gives you access to DOM elements, but that’s the beginner use case. If you only say “it’s for accessing DOM elements,” you’ve answered maybe 30% of the question.

7. “How do you decide between client state and server state?”

This reveals whether you’ve thought about data ownership or just throw everything into Redux.

Server state is data that lives on the backend and is fetched/cached on the client — user profiles, lists of items, API responses. Client state is UI-specific data that doesn’t exist on the server — modal open/closed, form input before submission, sidebar collapsed. Name your tools: TanStack Query or SWR for server state, Zustand or Context for client state.

Why does the distinction matter? Server state needs cache invalidation, background refetching, optimistic updates. Client state doesn’t. Mixing them creates complexity that doesn’t need to exist. I’ve worked on projects that had the entire API response shoved into Redux, and honestly, the amount of boilerplate just to keep that cache in sync with the backend was absurd. Purpose-built tools like TanStack Query handle all of that — saying “I use Redux for everything” in 2026 signals you haven’t kept up.

8. “Explain React Server Components. How are they different from SSR?”

This has gone from “nice to know” to “expected” in 2026, and most candidates still confuse the two.

SSR renders your components to HTML on the server, sends that HTML, then hydrates with JavaScript on the client — the component code still ships to the browser. Server Components run only on the server. Their code never reaches the client bundle — zero JavaScript cost for those components.

Here’s the distinction that matters: SSR is a rendering strategy (same components, different execution timing). Server Components are a component type (some components never leave the server). A Server Component can directly query a database or read the filesystem. Mention the 'use client' directive as the boundary marker. They’re complementary, not competing — you can use SSR with Server Components. Saying “Server Components replaced SSR” reveals you haven’t actually worked with them.

Browser and performance

These questions test whether you’ve ever opened DevTools for more than console logging.

9. “A page is loading slowly. Walk me through how you’d diagnose it.”

They’re testing your process, not your knowledge of performance APIs.

Start with measurement, not guessing: open Lighthouse, check Core Web Vitals (LCP, INP, CLS). Identify the bottleneck category: is it network (large bundles, too many requests), rendering (layout thrashing, expensive repaints), or JavaScript (long tasks blocking the main thread)? For network: check the Network tab waterfall, look for render-blocking resources. For JavaScript: profile with the Performance tab, look for long tasks (>50ms).

The mistake that kills you here: jumping straight to “I’d add lazy loading and code splitting.” That’s a solution, not a diagnosis. I’ve done this myself — reached for code splitting as a reflex before even checking whether the bundle was the problem. Turns out the issue was an unoptimized image. Embarrassing, but it taught me to measure first.

10. “What are Core Web Vitals and why should a frontend developer care?”

Name the three: LCP (Largest Contentful Paint — loading speed), INP (Interaction to Next Paint — responsiveness, replaced FID in March 2024), CLS (Cumulative Layout Shift — visual stability). Google uses them as a ranking signal, they correlate with conversion rates. Give one concrete example per metric: LCP — a hero image that takes 4 seconds to load. INP — a button click that freezes the UI for 300ms. CLS — an ad that loads late and pushes content down.

Still mentioning FID instead of INP? Your knowledge looks stale. FID was replaced in March 2024. Small detail, but interviewers notice.

11. “Explain how the browser renders a page from receiving HTML to pixels on screen.”

This is one of those questions where most candidates know more than they think — they just can’t get the steps in order under pressure.

Parse HTML to build the DOM tree. Parse CSS to build the CSSOM tree. Combine DOM + CSSOM into a Render tree (only visible elements). Layout: calculate exact position and size of each element. Paint: fill in pixels — colors, images, text, borders. Composite: layer ordering, GPU-accelerated transforms.

Mention that JavaScript can block parsing unless async or defer, which is why script placement matters. And know the difference between reflow and repaint: changing geometry triggers layout + paint + composite; changing only color triggers paint + composite. Stopping at “it parses HTML and CSS and shows the page” is just restating the question.

12. “What’s the difference between async and defer on a script tag?”

Both download the script in parallel with HTML parsing. async executes as soon as downloaded, pausing HTML parsing — execution order is not guaranteed. defer waits until HTML parsing is complete, then executes — execution order preserved. defer for scripts that depend on the DOM or on each other, async for independent scripts like analytics. Default choice: defer is almost always what you want.

Saying both are “the same thing” or that async waits for the DOM — it doesn’t. If your async script tries to query a DOM element that hasn’t been parsed yet, it fails silently, and that’s the kind of bug that takes hours to track down because there’s no error.

TypeScript questions

TypeScript is no longer optional in frontend interviews. If the job posting mentions it — and in 2026, most do — expect at least one question.

I’ll say something that might be unpopular: TypeScript interview questions are often the weakest signal of actual TypeScript ability. The difference between someone who can explain interface vs type and someone who can actually model a complex domain with discriminated unions and conditional types — it’s massive, and these standard questions don’t really capture it. But they’re what you’ll get asked, so.

13. “Explain the difference between interface and type in TypeScript.”

Both can describe object shapes — for basic use, they’re interchangeable. Key differences: interface supports declaration merging (declaring the same interface twice merges them). type supports union types, intersection types, and mapped types. interface can be extended with extends, type uses & for intersection.

Your heuristic: “I use interface for object shapes that might be extended, especially in public APIs. type for unions, intersections, and anything that isn’t a plain object shape.” Don’t say “always use type” or “always use interface” without justification — the interviewer wants to see you’ve actually thought about it.

14. “What are generics? Give me a practical example.”

Generics let you write functions, classes, or types that work with multiple types while preserving type safety. A practical example: an API response wrapper — type ApiResponse<T> = { data: T; error: string | null; loading: boolean } — reusable across every endpoint while keeping the data field strongly typed. Mention constraints: <T extends string | number> limits what types can be used, preventing runtime errors.

Whatever you do, don’t explain generics with function identity<T>(x: T): T. The interviewer has seen it a thousand times and it tells them nothing about whether you use generics in real code. API wrappers, form handlers, component props — anything from actual application code.

Behavioral-technical crossover

These trip people up most. They sound behavioral but require technical depth. Not rambling is especially important here.

15. “Tell me about a time you improved performance on a frontend application.”

This is a behavioral-technical crossover. You need a story, not a lecture. For a deeper look at answering this type of question, see what interviewers mean by “tell me about a technical challenge”.

Rough structure for ~90 seconds: situation (what was slow and why it mattered), diagnosis (what you measured and what you found), action (what you specifically did — name the techniques), result (numbers). “I made it faster” means nothing. “I reduced LCP from 4.2s to 1.8s” is concrete. If you don’t have exact numbers from a real project, approximate — the interviewer cares about the structure of your thinking more than the precision.

How to actually prepare

Reading these questions and nodding is worth approximately nothing. You’ve read through 15 questions. You understand the concepts. But here’s the test: pick question #2 (the event loop) right now. Set a 90-second timer. Explain it out loud.

If your explanation was clean and structured on the first try, you’re ahead of most candidates.

If you stumbled, repeated yourself, or went silent trying to remember the difference between the microtask queue and the callback queue — that’s normal. That’s the gap between reading and speaking. And that gap only closes with practice.

Practice verbally, not mentally. Thinking through an answer in your head uses different cognitive pathways than saying it out loud. Your mouth will betray you in an interview if you’ve only ever rehearsed silently. As we covered in why explaining out loud beats reading, the act of speaking forces you to linearize your knowledge — you can’t hand-wave past the fuzzy parts.

Record yourself. It’s uncomfortable. Do it anyway. Listen for filler words, unexplained jargon, and moments where you lose the thread.

Time yourself. After 90 seconds on a single question, you’re either rambling or going too deep. Practice hitting the key points within 60-90 seconds, then stopping.

Practice daily, not in bursts. One question per day for three weeks beats cramming 20 questions the night before.

This is what Prepovo is built for. You get a technical question, explain your answer out loud, and receive AI-powered feedback on your verbal structure, accuracy, and clarity. Five minutes a day. The skill of articulating complex concepts clearly compounds faster than you’d expect.

Pick three questions from this article — one from each category. Tomorrow morning, set a timer for 90 seconds and answer each one out loud. No notes. Record yourself if you can stand it.

Then listen back and ask: “Would I hire someone who gave this answer?”

If not — you know what to work on.