React interview cheatsheet: hooks rules in 60 seconds

Why it exists

React needs a way to remember each piece of state and each effect between renders of the same component instance. Rather than requiring a name or key for every useState and useEffect call, React ties each one to the order it was called in during render. The rules of hooks exist to protect that ordering assumption, because if it breaks, React has no way to know which stored state belongs to which hook call.

The mental model

Picture each component instance holding a plain array of hook slots, filled in the exact order the hooks were called during the first render. On every later render, React walks that same array position by position and matches each hook call to its slot. There are no names involved, only position, so the sequence of hook calls has to be identical every single render for the matching to stay correct.

How it works

The two rules follow directly from that model. Only call hooks at the top level means never put a hook inside a condition, a loop, or after an early return, because any of those can change how many hooks run on a given render, shifting the array positions of everything that follows. Only call hooks from React functions means custom hooks and components, not regular helper functions, so React can still trace the call order back to a single component instance. The react hooks ESLint plugin enforces both rules statically, catching violations before they ever run.

When it matters

This is a constant interview probe because the failure mode is subtle: conditionally calling a hook compiles fine and often runs fine on the very first render, then breaks the moment the condition changes on a later render. The footgun is exactly that delay, code that looks correct and passes a quick manual test can still violate the rule and fail intermittently once real users hit the branch that changes hook count.

A concrete example

A form component calls useEffect to run validation, but a developer wraps it in if the field has been touched, to avoid running it too early. On the render where touched flips from false to true, React expects the same hook at that position as before and instead finds a mismatch, throwing rendered more hooks than during the previous render. The fix is to keep the useEffect call unconditional and move the condition inside the effect body instead.