"Can you explain how React hooks work?"
You know hooks. You use them every day. You've built entire applications with useState, useEffect, useRef, useMemo. But when this question hits you in an interview, something strange happens. You start reciting: "useState is a hook that lets you add state to functional components..."
And the interviewer's eyes glaze over. Right?
You just described what the React docs say. You didn't show that you understand hooks. There's a gap between knowing how to use something and being able to explain it in a way that demonstrates real understanding — and that gap is where most candidates lose points.
What follows are ways to talk about the core hooks that actually show you've worked with them. Not what to know — how to say it.
Why docs-style answers don't work
Every blog post about React interview questions gives you the same format:
Q: What is useState?
A: useState is a React hook that allows you to add state variables to functional components. It returns an array with the current state value and a setter function.
Technically correct. Zero signal to the interviewer.
The interviewer already knows what useState does. They're not quizzing you on facts. They're evaluating three things:
- Mental model — Do you understand why hooks exist and how they fit into React's rendering model?
- Practical judgment — Can you choose the right hook for the right problem?
- Communication — Can you explain technical decisions to teammates?
A docs-recitation scores zero on all three. An answer that starts with the problem hooks solve scores on all three.
The "problem-first" approach
Before we get to individual hooks, here's the structure that works for explaining any technical concept in an interview. This is basically the core idea from the first 30 seconds of your interview answer:
- Problem (1-2 sentences) — What pain point does this solve?
- Mechanism (2-3 sentences) — How does it actually work, in your own words?
- Gotcha (1 sentence) — What trips people up?
- Real usage (1-2 sentences) — When you'd reach for it and when you wouldn't.
About 60 seconds to deliver. Under 30 feels shallow. Over 90 and you're rambling.
useState: stop saying "adds state to functional components"
The docs answer: "useState is a hook that lets you add state to functional components. It returns an array with the current value and a setter function. When you call the setter, the component re-renders."
That's a Wikipedia entry, not an interview answer.
Something more like this:
"Before hooks, if you needed a piece of data that could change and should trigger a re-render — a counter, a form field, a toggle — you had to convert your function component to a class. useState solved that. It gives your component a slot in React's internal state array, tied to the position of the hook call. That's why hooks can't be called conditionally — React relies on call order to match each useState to the right slot. In practice, I use it for local UI state — things like 'is this dropdown open' or 'what has the user typed.' For anything shared across components or with complex transitions, I'll reach for useReducer or something external."
The difference: you started with the problem, explained the mechanism with a mental model (slots, call order), dropped the key gotcha (conditional calls) with the reason behind it, and showed practical judgment. About 45 seconds of speaking.
useEffect: the most misunderstood hook
This is where candidates either show they understand React's model or reveal they don't.
The docs answer: "useEffect lets you perform side effects in function components. It runs after every render by default, and you can pass a dependency array to control when it runs."
Mechanically correct, reveals nothing.
Something better:
"useEffect exists because React's render function is supposed to be pure — given the same props and state, it should return the same JSX. But real applications need side effects: fetching data, setting up subscriptions, manually touching the DOM. useEffect is React's escape hatch for that. It says 'after you're done painting this to the screen, run this code.' The dependency array tells React which values this effect depends on — React skips re-running if none of them changed."
And the part that actually matters: "The biggest mistake I see is treating useEffect like a lifecycle method — trying to recreate componentDidMount with an empty dependency array. It works, but it misses the point. useEffect is about synchronizing with external systems, not about running code at specific lifecycle moments. That shift in mental model changes how you think about cleanup and when effects re-run."
This shows you understand:
- Why useEffect exists (purity of render)
- What "after painting" means (the timing model)
- The real purpose of the dependency array (correctness, not optimization)
- The conceptual trap (lifecycle thinking vs. synchronization thinking)
If the interviewer follows up on the cleanup function: "The cleanup runs before the effect re-runs and when the component unmounts. Classic example is a WebSocket subscription — you connect in the effect, disconnect in the cleanup. React cleans up the old effect before running the new one, which prevents stale-subscription bugs that were really common with class components."
useRef: not just "for DOM elements"
The docs answer: "useRef gives you a reference to a DOM element."
That's like saying "a car is for going to the grocery store." True, incomplete, misses the point.
Better: "useRef gives you a mutable container that persists across renders without triggering re-renders. That's the key distinction from useState — both persist values, but updating a ref doesn't cause React to re-paint. The DOM reference use case falls out of that naturally: you need a stable reference to a DOM node that doesn't change on every render. But I use refs for other things too — storing interval IDs, tracking previous prop values, keeping a mutable flag for whether a component is still mounted. Basically, anytime I need an instance variable that isn't part of the render output."
The phrase "instance variable that isn't part of the render output" connects hooks back to the class component mental model in a way that signals you've thought about this at a deeper level.
useMemo and useCallback: show restraint
This is where you can really stand out — by showing you know when not to use them.
The docs answer: "useMemo caches a computed value, and useCallback caches a function. You should use them to optimize performance."
Something that shows more judgment:
"Both are memoization tools. useMemo caches the result of a computation, useCallback caches a function reference. You'd want a stable function reference usually to prevent unnecessary re-renders in child components that take that function as a prop, or to keep a useEffect dependency stable. But here's the thing — memoization itself has a cost. React has to store the previous value, compare dependencies on every render, manage that cache. For cheap computations, adding useMemo actually makes performance worse."
And then — "I only reach for useMemo when I've profiled and confirmed there's a bottleneck — an expensive filter or sort on a large list. useCallback mostly when passing callbacks to memoized children. The React team has been pretty vocal about this: don't optimize prematurely with these hooks."
Most candidates talk about these hooks as pure performance wins. Showing you understand the cost of memoization and that you profile before optimizing — that's the signal.
useReducer: the underrated hook
Most candidates skip useReducer or dismiss it as "useState for complex state." That's a missed opportunity.
"useReducer follows the same pattern as Redux: you dispatch actions, and a pure reducer function computes the next state. I reach for it when state transitions depend on the previous state in non-trivial ways — like a form with validation that depends on multiple fields, or a multi-step wizard where going back needs to undo several state changes. The reducer function is pure and lives outside the component, so it's trivially testable. You write unit tests for your state logic without rendering anything."
The testability angle catches interviewers off guard. Most people don't mention it, and it shows you think about code organization, not just functionality.
That said — I'll admit I probably underuse useReducer in my own code. I reach for useState by default even when the state is getting complex enough that a reducer would be cleaner. Old habits. Something about the action/dispatch pattern feels like overhead when you're just prototyping. Whether that's laziness or pragmatism, I'm not sure.
useContext: keep it short
Not much to say about this one. useContext reads from a React context, provider sits up the tree, any descendant can read the value without prop drilling. The only thing worth mentioning is the re-render trap: every consumer re-renders when the context value changes, which is why you don't put rapidly-changing values in context. Theme, locale, auth state — things that change infrequently. For everything else, use a proper state management tool.
Don't over-explain this in an interview. Ten seconds is fine. Move on.
Custom hooks: the real test
If the interviewer asks about custom hooks, they're testing whether you see hooks as a composition mechanism, not just a React API.
"Custom hooks are just functions that call other hooks. The convention is the 'use' prefix so React can enforce the rules of hooks. But the real value is that they let you extract and reuse stateful logic — not UI, just logic. For example, I've built a useDebounce hook that wraps useState and useEffect to give any component debounced input handling. The component doesn't know about the timing logic. You get reusable stateful behavior that's decoupled from any particular component's rendering."
Then give one concrete example from your own work. "I built useMediaQuery that tracks viewport breakpoints" or "we had a usePolling hook that fetched data on an interval with automatic cleanup." Specific beats generic.
The 60-second hooks overview
If you get the broad "explain hooks" question, here's roughly what a complete answer looks like:
"Hooks let function components do everything class components could — and more composably. Before hooks, reusing stateful logic meant higher-order components or render props, both of which created wrapper hell. With hooks, you extract stateful logic into a function and call it from any component. The core hooks map to specific needs: useState for local reactive values, useEffect for synchronizing with external systems, useRef for mutable values that don't trigger renders, useMemo/useCallback for targeted performance optimization. Custom hooks are where it gets powerful — you compose the primitive hooks into domain-specific logic that any component can use. The mental model shift is thinking in terms of what this component synchronizes with rather than what happens at each lifecycle stage."
That's about 60 seconds. It covers the why, the what, and the mental model.
Practice out loud, not in your head
Reading these examples won't help you in an interview. You need to say them. Out loud.
This is the core insight behind verbal practice for interview prep: the gap between reading an explanation and delivering one is enormous. Your brain processes information differently when you're producing speech. You'll stumble on transitions, realize you don't actually understand the dependency array as well as you thought, and discover which parts of your explanation feel forced.
Pick one hook — whichever you feel least confident explaining. Set a timer for 60 seconds. Explain it out loud using the problem-mechanism-gotcha-usage structure. Record yourself if you can stand it.
Then do it again. The second take will be noticeably better. The fifth take will sound like you actually understand it, which is different from sounding like you invented it — nobody needs to sound like Dan Abramov in an interview, they just need to sound like they've actually used the thing and thought about why it works the way it does.
Top comments (0)