React Interview Questions for Experienced Developers (2026)

If you're an experienced React developer preparing for an interview, the questions change a lot between two and five years, and again at senior level. Early on, interviewers check whether you really understand how hooks, state and rendering behave. From around five years, they check judgment: can you make a good call when there are three reasonable ways to build something, and explain why you picked one? This guide covers React interview questions for experienced developers at three levels (2–3 years, 4–5 years and senior 5+ years), with what interviewers are actually listening for.

What Actually Changes at This Level

A junior interview checks whether you can build a working component from a spec. A senior interview assumes you can already do that, and instead checks what happens when the spec is ambiguous, the requirements change halfway through, or two valid approaches trade off against each other in ways that aren't obvious. Interviewers are listening for the reasoning behind your answer as much as the answer itself — a confident wrong tradeoff analysis is more concerning to them than admitting you'd need to profile something before deciding.

React Interview Questions for 2–3 Years of Experience

At two to three years, interviewers expect you to build features on your own. The questions move from what a hook is to why something behaved the way it did, with a lot of weight on effects, state and re-rendering.

How does useEffect behave with an empty dependency array, with dependencies, and with none?

With an empty array the effect runs once after the first render. With dependencies it runs after the first render and again whenever one of them changes. With no array it runs after every render. Interviewers usually follow up about cleanup functions and what happens when you leave a dependency out, which is how stale values sneak in.

What causes a stale closure in a component, and how do you fix it?

A function created during one render keeps the values from that render. If an effect or timer is set up once and reads state inside it, it keeps seeing the old value. You can fix it by adding the value to the dependency array, using the functional form of the setter (for example setCount(c => c + 1)), or keeping the latest value in a ref.

When would you use useMemo or useCallback, and when is it unnecessary?

They help when you pass an expensive calculation or a function to a memoized child or to another hook's dependency array, so its reference stays stable. They add cost and noise when used everywhere by default. A good answer says you would measure first and use them where they fix a real re-render or calculation problem.

Why do list items need keys, and why is using the array index risky?

Keys let React match items between renders so it can update, move or remove the right ones. With index keys, inserting or reordering items shifts the indexes, which can make React reuse the wrong component state, for example a typed value ending up in the wrong row. Stable unique ids avoid this.

What is the difference between controlled and uncontrolled components?

In a controlled component, React state is the source of truth for the input value and changes go through onChange. In an uncontrolled component the DOM holds the value and you read it with a ref when needed. Controlled inputs make validation and instant feedback easier, while uncontrolled ones can be simpler and avoid re-rendering on every keystroke.

Practice effects, stale closures and custom hooks with real tests. Try the React hooks practice problems →

React Interview Questions for 4–5 Years of Experience

By four to five years, questions move from how a feature works to how you build and maintain one in a real codebase: data fetching, testing, error handling and structure.

How do you handle data fetching and caching in a React app?

For simple cases, fetch inside an effect with loading and error state, and make sure a stale request can't overwrite a newer one. For larger apps, a library such as React Query or SWR handles caching, refetching and request deduplication for you. A strong answer explains what problem the library solves, not just its name.

How do you test React components?

A common approach is React Testing Library with Jest or Vitest: render the component, interact with it the way a user would (click, type), and assert on what the user sees instead of on implementation details. Mention what you would mock, such as network calls, and how you decide which tests are worth the maintenance.

What are error boundaries, and when would you use them?

An error boundary catches errors thrown while rendering its children and shows a fallback UI instead of crashing the whole app. It doesn't catch errors in event handlers or async code. Place boundaries around sections that can fail independently, such as a widget or a route, and log the error to a monitoring tool.

How would you structure a large React project?

There is no single right answer. Common choices are grouping by feature (each feature folder holds its components, hooks and tests) instead of by file type, keeping shared UI in a common folder, and keeping state close to where it is used. The interviewer wants your reasoning about keeping the code easy to find, test and change as the team grows.

How do you make a React app accessible?

Start with semantic HTML (buttons for actions, labels for inputs), make everything usable with a keyboard, manage focus for modals and route changes, and add ARIA attributes only when native elements aren't enough. Test with a keyboard and a screen reader, and use lint rules that flag common problems.

Want the full list of React interview questions with answers and code? Browse all React interview questions →

Senior Developer Questions (5+ Years)

From here on, the questions are senior level: architecture, performance, internals and collaboration.

Architecture and State Management Questions

How would you decide between Redux, Context, and a library like Zustand for a large app?

There's no universally correct answer here, and interviewers know that — they're checking whether you reason about tradeoffs instead of reciting a preference. A strong answer separates state by how often it changes and who needs it: Context works fine for state that changes rarely (theme, auth session) but re-renders every consumer on every update, which becomes a real cost for frequently-changing state. Redux or Zustand add overhead but give you selective subscriptions, middleware, and predictable debugging for state that's shared widely and changes often.

When would you split a large app into micro-frontends, and when is that overkill?

Good answers focus on organizational boundaries, not technical ones. Micro-frontends earn their complexity when multiple independent teams need to ship on separate timelines without blocking each other — not just because an app is "big." For a single team, even a large codebase, a well-organized monolith with clear module boundaries is usually faster to build and easier to maintain than the deployment and versioning overhead micro-frontends introduce.

How do you decide between client-side rendering, SSR, and static generation for a given page?

This comes down to how often the content changes and how much SEO or first-paint speed matters. A marketing page that rarely changes is a static-generation candidate. A logged-in dashboard full of user-specific data gains little from SSR and is usually fine client-rendered. A product page that needs to be crawlable and fast on first load is the classic SSR case. The strongest answers name the actual constraint driving the decision instead of defaulting to "SSR is just better."

Performance Questions

Walk me through how you'd diagnose unnecessary re-renders in a large app.

Interviewers want a process, not a guess. A solid answer: reach for the React DevTools Profiler first and record an interaction, look at which components re-rendered and why the panel gives for each one, then check whether it's a new object/array/function reference being passed as a prop, state living higher in the tree than it needs to, or a missing memoization boundary. Fixing it blindly with useMemo everywhere before profiling is exactly the wrong instinct to describe out loud.

How would you handle rendering a list with tens of thousands of items smoothly?

The keyword interviewers are listening for is windowing or virtualization — rendering only the rows currently visible in the viewport (with a small buffer) instead of the entire list, using something like react-window or react-virtual. A good answer also mentions that this only helps if the list itself is the bottleneck — it's worth confirming with a profiler before restructuring a whole component around it.

When does code-splitting help, and when does it actually hurt?

Code-splitting a rarely-visited route or a heavy modal that most users never open is a clear win — smaller initial bundle, faster first load. Splitting something the user needs immediately, like the first thing rendered above the fold, just adds a network waterfall and a loading flicker where none existed before. The judgment is in knowing which parts of the app are "pay for it later" and which are "pay for it now, every time."

React Internals Questions

At a high level, what problem does the Fiber architecture solve?

Before Fiber, React's rendering work was synchronous and couldn't be paused — a big update could block the main thread and freeze the page mid-interaction. Fiber restructured rendering into interruptible units of work, so React can pause, prioritize, and resume rendering, keeping the app responsive even during expensive updates. You don't need to recite the internal data structures — showing you understand why it exists is what matters.

What's the practical difference between concurrent rendering and the older synchronous rendering model?

Concurrent rendering lets React prepare multiple versions of the UI and abandon in-progress work if something more urgent comes in — like a user typing while a large list is still rendering in the background. Practically, this is what powers features like transitions, where you can mark an update as non-urgent so a laggy list doesn't block a text input from feeling instant.

How does automatic batching in React 18+ change behavior compared to older versions?

Older React only batched state updates inside React event handlers — an update inside a setTimeout or a promise callback would trigger a separate re-render for each setState call. React 18 extended batching to cover those cases too, so multiple state updates anywhere get grouped into a single re-render. The gotcha worth mentioning: this can surprise code that was relying on the old behavior to read updated state mid-function, which is a real bug some teams hit during upgrades.

System-Design-Style Questions

Design a real-time notification feature for a dashboard app. What are the tradeoffs?

A strong answer opens with the actual tradeoff: polling is simple to build and debug but wastes requests and adds latency; WebSockets give instant updates but add connection-management complexity and a server-side component that has to scale differently. From there, cover what happens on reconnect, how you'd avoid duplicate notifications, and whether optimistic UI updates make sense for actions the user takes locally (like marking something read) versus waiting on server confirmation.

How would you design a shared component library used by multiple teams?

This question is really about API design and versioning discipline, not component code. Good answers mention semantic versioning so consuming teams aren't broken by silent changes, a clear deprecation process instead of removing props outright, and keeping components unopinionated about styling/business logic so they stay reusable across teams with different needs.

Judgment and Collaboration Questions

Senior loops almost always include a few questions that aren't about React syntax at all — they're checking how you operate on a team, since that's most of what "senior" actually means day to day.

• How do you handle a disagreement with another senior engineer about architecture? — Interviewers want to hear that you'd bring data or concrete tradeoffs to the table, not just push a preference harder.
• A junior engineer's pull request works but won't scale well. How do you review it? — This checks whether you can give feedback that teaches, without blocking progress over a non-critical style opinion.
• How do you decide when to introduce a new pattern or library into an existing codebase? — Good answers mention team buy-in and migration cost, not just "it's better."

"A senior engineer isn't the one with the most opinions — it's the one who can tell you which tradeoff actually matters for this specific problem."

How to Actually Prepare for a Senior Interview

Reading a list of questions like this one gets you familiar with the shape of what's coming, but it won't build the instinct these interviews are testing. That instinct comes from having actually hit these tradeoffs somewhere — in a side project if not at work. If you haven't personally dealt with a re-render problem, profiled a slow list, or had to choose a state management approach under real constraints, the honest move is to go create that experience deliberately instead of memorizing an answer you've never lived.

Pick one topic from this post — say, diagnosing unnecessary re-renders — and go build a small app that has that exact problem on purpose. Fix it, profile it, and be ready to explain what you tried that didn't work. That story will beat a rehearsed textbook answer every time, because it's the kind of specificity a senior interviewer is actually listening for.

Want a lower-stakes way to build that muscle before you're in the room? Try a React coding challenge →

And if the full-stack side of a senior or lead role is also on the table, it's worth being equally sharp on the backend fundamentals interviewers pair with these questions.

Want 10 complete React coding questions with tested solutions? Read React coding interview questions with solutions →

Brush up on the Node, Express, and MongoDB side too. Read the MERN stack interview questions guide →