React Interview Questions: From Hooks to Architecture

1. Explain the virtual DOM and how React uses it

What interviewers assess: Foundational understanding of React's rendering model.

React creates an in-memory representation of the DOM called the virtual DOM. When state changes, React builds a new virtual DOM tree, diffs it against the previous one, and calculates the minimal set of changes needed. Those changes are batched and applied to the real DOM in a single update.

The key insight is that DOM manipulation is expensive, and batching updates reduces layout thrashing. React's fiber architecture takes this further by breaking rendering work into units that can be paused, prioritized, and resumed. This enables features like concurrent rendering and transitions.

Common mistake: Saying the virtual DOM is "faster than the real DOM." It is not inherently faster. The virtual DOM is a programming model that makes it easier to write declarative UI code while React handles efficient updates for you. The performance benefit comes from avoiding unnecessary DOM operations, not from the virtual DOM being fast on its own.

2. What are the rules of hooks?

What interviewers assess: Correctness and understanding of React's execution model.

There are two rules. First, hooks must be called at the top level of your component or custom hook. Never call them inside conditions, loops, or nested functions. Second, hooks can only be called from React function components or custom hooks, not from regular JavaScript functions.

The reason behind the first rule is that React tracks hook state by call order. Each render, React expects the same hooks to be called in the same sequence. If you put a hook inside a condition, the call order changes between renders, and React loses track of which state belongs to which hook.

Explain why the constraint exists, not just the rule itself. Interviewers want to know you understand the execution model, not that you memorized a list.

3. How does React handle reconciliation?

What interviewers assess: Understanding of the diffing algorithm and its performance implications.

Reconciliation is the process React uses to determine what changed between two renders. React compares elements by type first. If the type changes (for example, from a <div> to a <span>), React tears down the old tree and builds a new one. If the type stays the same, React updates the existing node's props.

For lists, React uses keys to match elements between renders. Without keys (or with index-as-key), React may re-render the entire list unnecessarily or produce bugs when items are reordered. Stable, unique keys allow React to efficiently insert, remove, and move items.

The diffing algorithm is O(n) by design. React makes the simplifying assumption that elements of different types produce different trees. This is nearly always true in practice and keeps the algorithm fast.

4. When would you use useRef vs useState?

What interviewers assess: Mental model of React's render cycle.

useState stores values that affect what the user sees. When you update state, React re-renders the component. useRef stores values that persist across renders but do not trigger re-renders when they change.

Use useRef for DOM element references, storing timer IDs, tracking previous values, and holding any mutable data that does not affect visual output. Use useState for anything the user sees or interacts with: form inputs, toggle states, counters, loading flags.

A common interview follow-up is: "What happens if you store a value in useRef and try to display it?" The answer is that the display will not update when the ref changes because React does not know about it. Only state changes trigger re-renders.

5. Explain React's context API and its limitations

What interviewers assess: State management decisions and awareness of trade-offs.

Context provides a way to pass data through the component tree without threading props through every level. You create a context with createContext, provide a value at the top with a Provider component, and consume it anywhere below with useContext.

The main limitation is performance. Any component that calls useContext re-renders whenever the context value changes, even if the component only uses a small part of that value. There is no built-in selector mechanism like you get with Redux or Zustand.

Context works well for low-frequency updates: themes, locale, authentication status. For high-frequency updates like form state or real-time data, external state management libraries are usually a better choice. Discuss the trade-off: context is simple and built-in, but it can cause unnecessary re-renders at scale.

6. What is the difference between controlled and uncontrolled components?

What interviewers assess: Form handling patterns and when to use each.

In a controlled component, React manages the input's value through state. Every keystroke updates state, and the input's value is always driven by that state. In an uncontrolled component, the DOM itself holds the current value, and you access it through a ref when needed.

Controlled components give you real-time access to the input value, which enables validation on every keystroke, conditional rendering based on input, and coordinated multi-field forms. The trade-off is more boilerplate: you need a state variable and an onChange handler for each input.

Uncontrolled components are simpler for basic forms where you only need the value on submit. File inputs are always uncontrolled because their value is read-only in the browser.

7. How does React handle error boundaries?

What interviewers assess: Production readiness and resilience patterns.

Error boundaries are class components that implement componentDidCatch and getDerivedStateFromError. They catch JavaScript errors during rendering, in lifecycle methods, and in constructors of child components. When an error is caught, the boundary renders a fallback UI instead of crashing the entire app.

Important limitations: error boundaries do not catch errors in event handlers, asynchronous code (setTimeout, promises), or server-side rendering. For event handler errors, you need regular try/catch blocks.

In production, you typically place error boundaries at route level and around critical features. The fallback UI should give users a way to recover, like a "Try again" button or navigation to a working page. Pair error boundaries with error reporting services to capture and triage issues.

8. Explain server-side rendering and when you would use it

What interviewers assess: Architecture decisions and framework knowledge.

Server-side rendering (SSR) runs your React code on the server and sends fully rendered HTML to the client. The browser displays the HTML immediately while JavaScript loads in the background. Once JavaScript is ready, React "hydrates" the page, attaching event listeners to the existing DOM.

SSR improves initial load time and is essential for SEO on content-heavy pages. Streaming SSR (introduced in React 18) sends HTML progressively, so users see content before the entire page is rendered.

The trade-offs: SSR adds server complexity, increases time-to-first-byte if your data fetching is slow, and requires careful handling of browser-only APIs. Static site generation (SSG) is better for content that does not change per request. Client-side rendering is fine for authenticated dashboards where SEO does not matter.

Frameworks like Next.js handle SSR, SSG, and hybrid rendering out of the box, which is why they are increasingly expected in full-stack React roles.

1. Build a debounced search input

What interviewers assess: Hooks composition and cleanup logic.

Create a custom hook that wraps useState and useEffect with a debounce timer. The hook accepts a value and a delay, then returns the debounced value. Inside the effect, set a timeout that updates the debounced value after the delay. Return a cleanup function that clears the timeout.

The cleanup function is critical. Without it, you get stale closures: if the component unmounts before the timeout fires, you will try to update state on an unmounted component. The cleanup runs before every re-execution of the effect and on unmount.

Edge cases to discuss: race conditions when async search results return out of order (the solution is an AbortController or a flag that ignores stale results), and what happens if the user types and then navigates away mid-debounce. A strong answer separates the debounce logic into a reusable hook and the search logic into the consuming component.

2. Implement an infinite scroll component

What interviewers assess: Performance awareness and API usage.

Use the IntersectionObserver API to detect when a sentinel element near the bottom of the list enters the viewport. When it does, trigger the next page fetch. This is more efficient than scroll event listeners because IntersectionObserver runs off the main thread.

Handle loading states (show a spinner while fetching), error states (show a retry button if a request fails), and deduplication (prevent firing multiple requests for the same page). Track whether there are more pages to load and remove the observer when the list is complete.

For very long lists (thousands of items), discuss virtualization. Libraries like react-window or react-virtuoso render only the visible items plus a small buffer, keeping the DOM size constant regardless of list length. This prevents memory issues and keeps scrolling smooth.

3. Your component re-renders too often. How do you debug it?

What interviewers assess: Performance debugging methodology.

Start with React DevTools Profiler. Record an interaction and look at which components re-rendered and why. Common culprits: a parent re-rendering causes all children to re-render, new object or function references created on every render get passed as props, or context changes trigger updates in components that do not need them.

Apply fixes based on the root cause. React.memo prevents a child from re-rendering when its props have not changed. useMemo stabilizes object and array references. useCallback stabilizes function references. But only apply these after profiling. Premature memoization adds complexity without solving the actual problem.

Common mistake: Wrapping everything in React.memo and useMemo without measuring. This adds memory overhead and makes code harder to read. Find the bottleneck first, then optimize surgically.

4. Create a custom hook for API data fetching

What interviewers assess: Abstraction skills and error handling.

Build a useFetch hook that manages three states: loading, data, and error. Accept a URL and optional configuration. Use useEffect to trigger the fetch when the URL changes. Handle the response, parse JSON, and update the appropriate state.

The critical detail is handling race conditions. If the URL changes while a request is in flight, the old request's response should be ignored. Use an AbortController to cancel the previous request, or use a boolean flag in the effect cleanup to mark stale responses.

Discuss when you would stop using a custom hook and reach for a library like React Query or SWR. These libraries handle caching, deduplication, background refetching, retry logic, and optimistic updates. For a production application with many API calls, they save significant development time and cover edge cases that are hard to get right manually.

5. Implement a modal system that supports stacking

What interviewers assess: Component composition, portal usage, and accessibility.

Use createPortal to render modals outside the component tree, directly into document.body or a dedicated modal root. This avoids z-index conflicts and overflow:hidden issues from parent containers.

For stacking, maintain an array of active modals in state. Each modal gets a z-index based on its position in the stack. Pressing Escape closes the topmost modal only. Clicking the backdrop closes the topmost modal only.

Accessibility requirements: trap focus within the active modal (Tab and Shift+Tab should cycle through focusable elements inside it), restore focus to the trigger element when the modal closes, and add role="dialog" and aria-modal="true" attributes. Discuss how you would handle screen readers and keyboard navigation throughout.

6. Refactor a class component to use hooks

What interviewers assess: Migration knowledge and lifecycle understanding.

Map lifecycle methods to hooks systematically. componentDidMount becomes useEffect with an empty dependency array. componentDidUpdate becomes useEffect with specific dependencies. componentWillUnmount becomes the cleanup function returned from useEffect.

Replace this.state with individual useState calls. If the class had many related state values, you can use useReducer instead. Replace this.context with useContext.

Watch for subtle differences. Class components batch state updates only inside event handlers, while function components with React 18+ batch all state updates automatically. Also, useEffect runs after paint, while componentDidMount runs before paint. If you need the pre-paint timing, use useLayoutEffect instead.

Over-engineering simple components

Not every component needs a custom hook, context provider, and memoization. Start simple and add abstractions only when the complexity demands it. Interviewers notice when you complicate straightforward problems.

Using useEffect for everything

useEffect is not a lifecycle method replacement. It synchronizes your component with external systems. If you find yourself using useEffect to derive state from other state, you probably need a computed value or useReducer instead. The React docs call this "You Might Not Need an Effect" for a reason.

Not explaining trade-offs

When an interviewer asks "which approach would you use," they do not want a single answer. They want to hear you compare options, acknowledge downsides, and explain why one approach fits the situation better. Always discuss trade-offs.

Forgetting accessibility in component design

If you build a custom dropdown, modal, or tab component without mentioning keyboard navigation, focus management, or ARIA attributes, you are leaving points on the table. Accessibility is part of component quality, not an afterthought.

Memorizing hook signatures without understanding the mental model

Knowing that useEffect takes a dependency array is not enough. You need to understand why it exists (to control when the effect re-runs), what happens when you get it wrong (stale closures, infinite loops), and how cleanup works. Interviewers probe the "why" behind every answer.

Ignoring error handling and loading states

When you build a component in an interview, always handle the loading state, the error state, and the empty state. Jumping straight to the happy path makes your solution look incomplete. Production components deal with failure, and interviewers expect you to show that awareness.