React Interview Questions for AI Training Work

Props are read-only data passed down from a parent, while state is data a component owns and can change itself, typically via `useState`. Props are immutable from the child's perspective because React's data flow is one-directional: if a child could mutate its props directly, the parent's copy of that data would go out of sync with what's rendered, breaking the predictability that makes React's rendering model work.

The dependency array tells React when to re-run the effect: it re-runs whenever any value in the array changes between renders, and runs once on mount if the array is empty. A common mistake is omitting a value the effect actually uses, like a prop or state variable referenced inside, which causes the effect to run with a stale closure over an outdated value instead of re-running when that value changes.

A component re-renders when its state changes, its parent re-renders, or its props change identity, even if the new props are shallowly equal in value, like a new object or array literal created on every render. I'd use the React DevTools Profiler to record a render pass and see which components re-rendered and why, rather than guessing which memoization to add first.

Both cache a value across renders unless a dependency changes, but `useMemo` caches the result of a computation, like an expensive derived value, while `useCallback` caches a function reference itself. `useCallback(fn, deps)` is functionally equivalent to `useMemo(() => fn, deps)`, it exists mainly for readability when the goal is specifically to keep a stable function identity, commonly to avoid re-triggering a memoized child component.

React uses `key` to match elements between renders and decide whether to update an existing DOM node or create a new one. Using the array index as a key breaks this when items are reordered, inserted, or removed, because the index no longer reliably identifies the same logical item, which can cause React to reuse the wrong DOM node, showing stale state, like an input's value, attached to the wrong list item.

I'd first confirm with the Profiler that the lag is actually re-render cost and not something else, like an expensive computation running inside the render itself. If unrelated child components are re-rendering unnecessarily, I'd wrap them in `React.memo` and stabilize the props passed to them with `useMemo`/`useCallback`. If the real cost is the input's own re-render, debouncing the state update or moving that field to uncontrolled with a ref can help.

The most direct fix is lifting the state up to their nearest common ancestor and passing it down as props to both. If that ancestor is far up the tree and prop drilling through several layers gets unwieldy, Context is the next option for state that's read in many places, and a dedicated state library becomes worth it once the shared state and its update logic gets complex enough that Context alone starts causing broad re-renders.

Inside `useEffect`, I'd set up an abort controller or a local `let ignore = false` flag, start the fetch, and check that flag before updating state when the response resolves. The effect's cleanup function sets the flag or calls `abort()`, so if the component unmounts mid-request, the fetch either gets cancelled or its result is simply discarded instead of triggering a state update on an unmounted component.

I had a `setInterval` set up inside `useEffect` with an empty dependency array that referenced a state variable, and the callback kept using the value from the very first render instead of the current one. The fix was either adding the variable to the dependency array and resetting the interval when it changed, or switching to a functional state update that doesn't depend on the closed-over value at all.

On a settings panel that re-rendered on every keystroke in an unrelated field, I measured the actual render cost with the Profiler and found it was under a millisecond, well below anything a user would notice. Adding `React.memo` and memoized callbacks there would have added code complexity for a performance gain nobody would ever perceive, so I left it as-is and documented why in case someone later assumed it needed fixing.