React state belongs to a particular render. Calling a setter requests another render; it does not replace the variable inside the event handler that is already running. React interview questions about counters usually test this distinction before they test syntax.

Start by identifying the value captured by the current handler. Then read each queued update in order. Avoid the vague explanation that state is simply slow: waiting is not the rule that determines the result.

Why do two replacement updates add only one?

import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);
  return <>
    <output aria-label="Count">{count}</output>
    <button onClick={() => {
      setCount(count + 1);
      setCount(count + 1);
    }}>Replace twice</button>
    <button onClick={() => {
      setCount(value => value + 1);
      setCount(value => value + 1);
    }}>Add twice</button>
  </>;
}

From zero, Replace twice queues the replacement value one twice. The next count is one. From that result, Add twice applies two transformations and reaches three. Both statements in the first handler read the same count snapshot.

What does an updater function receive?

It receives the pending state as React processes the queue. Each updater returns the value for the next step. This is useful when a change depends on the previous value, especially when several updates can be queued together.

An updater must be pure. Do not send a request, modify an outside array or record a payment inside it. React may call updater functions more than once in development to find accidental impurities. The result must remain correct if that check happens.

Does a timeout read future state?

No. A callback created in a render captures values from that render. If a handler schedules an alert using count, a later render does not rewrite that callback's captured variable. Ask whether the task needs the value at scheduling time or the latest value when it runs. Those are different requirements.

A ref can hold a mutable value that survives renders without triggering them. That does not make refs a replacement for visible state. If a number is displayed, its normal owner should still be state.

How do replacement and updater entries interact?

Trace them in order. Starting at zero, a replacement with five followed by an updater that adds two produces seven. Reversing those entries leaves five, because the later replacement supplies the final value. A setter is not an immediate assignment to the local binding.

When the interviewer changes the example, write a small queue: input, operation, output. This is more reliable than remembering one counter puzzle and guessing at every variation.

What should you test?

  • Click each button from a fresh zero state.
  • Click Add twice after Replace twice and check three.
  • Render two counters and confirm their state is independent.
  • Check that the displayed value changes without relying on a console log inside the old handler.

Do not make a test depend on an exact development render count. Verify the user's observable result. React can render for reasons that do not imply another committed user action.

A concise interview answer

“Each handler reads its render's snapshot. Replacement updates here calculate the same number. Functional updates compose against pending state, so two increments add two. I would keep those functions pure and test the displayed result after the interaction.” Use the example to explain the model, then stop when the question is answered.

References and next practice

react.dev — react state

react question collection · Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud