Crack Frontend Interviews: JavaScript + React

Output (from the test run)

script start, async1 start, async2, promise1, script end, async1 end, promise2, setTimeout. Everything up to the first await is synchronous, including the body of async2. The code after await and the .then are microtasks, queued in that order. The timer is last.

Likely follow-up

What if async2 ends with return Promise.resolve()? async1 end moves back two microtask turns. An async function that returns a promise has to follow it, which costs extra turns. With a longer chain (promise2, promise3, promise4), it would print after promise3.

Checked by harness/output/ch04-async/20-async-calls-async.mjs · Node 24.18.0

1 after the first click, 2 after the second, and 3 renders in total. The three updates are queued and applied in order: count + 1 sets 1, the updater makes it 2, and the last count + 1 sets it back to 1.

Common mistake

Answering 3 because of the updater in the middle; a plain value queued after it replaces the result.

The test file checks

• a plain value after an updater replaces it
• updaters chain

Likely follow-up

How do you make one click add 3? Use the updater form for all three calls, setCount((c) => c + 1), so each one starts from the previous result. The test file checks it: one click shows 3.

Checked by harness/react/ch10-performance/mixed-updates.test.jsx · Node 24.18.0, React 19.3.1

Keep one timer in a closure. Every call clears it and starts a new one, so fn runs only after wait ms with no calls, with the last call's arguments and this. With leading: true, run the first call of a burst at once and use the timer only to tell when the burst ends. cancel() clears the timer.

// Runs fn once calls stop for `wait` ms, with the last call's arguments and `this`.
// { leading: true } runs the first call of a burst at once and drops the rest of the burst.
// cancel() drops a pending call.
export function debounce(fn, wait, { leading = false } = {}) {
  let timer = null;

  function debounced(...args) {
    const runNow = leading && timer === null;
    clearTimeout(timer);
    timer = setTimeout(() => {
      timer = null;
      if (!leading) fn.apply(this, args);
    }, wait);
    if (runNow) fn.apply(this, args);
  }

  debounced.cancel = () => {
    clearTimeout(timer);
    timer = null;
  };

  return debounced;
}

The test file checks

• runs once, after calls stop, with the last arguments
• keeps this and passes every argument
• a new burst after the wait runs again
• leading: runs the first call at once and nothing at the end of the burst
• leading: calls during the burst keep pushing the quiet period out
• cancel() drops the pending call
• cancel() resets leading mode so the next call runs at once

Likely follow-up

How do you use this debounce in a React search box? Create the debounced function once, not on every render, with useMemo(() => debounce(search, 300), []) or a useRef. Otherwise each render makes a new debounced function with its own timer and nothing is debounced. That keeps the search from the first render, so if search reads state or props, keep the latest one in a ref (searchRef.current = search on each render, and debounce (q) => searchRef.current(q)), or use useEffectEvent when the call happens inside an effect. Call debounced.cancel() in the effect cleanup so a late call does not run after the component unmounts. Many teams write a useDebounce(value, delay) hook instead, which sets a timeout inside useEffect and clears it in the cleanup.

Checked by harness/impl/ch05-functions/debounce.test.mjs · Node 24.18.0