When would you choose useLayoutEffect over useEffect?
React commit phase and paint timing.
Use useLayoutEffect to measure or mutate DOM before paint to stop flicker; useEffect runs after paint.
Using it for data fetching or ignoring its blocking cost.
What's really being asked
This question probes whether you understand the boundary between React's commit phase and the browser's paint cycle. A senior engineer should know that useLayoutEffect fires synchronously after all DOM mutations but before the browser repaints the screen, while useEffect fires after the paint. The interviewer wants to see that you grasp the performance trade-off: blocking paint can prevent visual flicker but also blocks the main thread.
The full answer
First, the timing distinction in plain terms. useLayoutEffect runs immediately after React commits changes to the DOM and before the browser repaints the screen. useEffect runs after the paint, making it non-blocking. Second, a concrete scenario where synchronous measurement and mutation matter, such as positioning a tooltip or modal based on the measured height or position of a trigger element. Third, the user impact. Because useLayoutEffect blocks paint, the user never sees the intermediate wrong state, whereas useEffect would show a flash of incorrectly positioned content before the correction. Fourth, the default recommendation. The answer should state that useEffect is preferred for almost all side effects, and useLayoutEffect should be reserved for layout measurements that absolutely must happen before paint.
The mistakes people make
A major red flag is saying that useLayoutEffect is only for server-side rendering or that it runs before the DOM is updated. Another is claiming it is safer or more predictable than useEffect and should be used by default. Some candidates describe data fetching in useLayoutEffect, which misses the point entirely because fetching does not depend on DOM paint timing. Finally, failing to mention the performance cost of blocking the browser's main thread suggests shallow knowledge.
What usually comes next
The interviewer may ask how you would handle the same problem in a server-rendered environment where useLayoutEffect warns or does nothing. They might also ask about useInsertionEffect for CSS-in-JS, or how to reduce layout thrashing when reading and writing DOM values repeatedly. Another follow-up is asking for a specific performance budget or how you would measure the impact of a synchronous layout effect on frame time.
A concrete example
Imagine a tooltip that needs to appear above a button. If the tooltip height is unknown, you might render it first, then measure its bounding rectangle with getBoundingClientRect, and finally adjust its top position to sit flush above the button. If you do this in useEffect, the user sees the tooltip render in the wrong spot for one frame and then snap into place. If you do it in useLayoutEffect, the measurement and adjustment happen before the browser paints, so the tooltip appears in the correct position immediately.
Interview question
You must measure a rendered DOM element and immediately adjust a modal to prevent visual flicker. Which choice is correct?
- a.useEffect, because it runs after paint and avoids blocking the main thread
- b.useInsertionEffect, because it fires before React commits to the DOM and prevents layout thrashing
- c.useLayoutEffect, because it runs after the browser paints and ensures the DOM is fully updated
- d.useLayoutEffect, because it runs synchronously after DOM mutations but before paint, letting you correct layout before it is visibleCorrect
Why? this is the answer
useLayoutEffect runs synchronously after React commits DOM changes but before the browser paints, so layout corrections happen before the user sees anything. Option C is tempting because it names the right hook but incorrectly claims it runs after paint, which would actually cause the flicker you are trying to prevent.
Just read this? Test yourself on what you have been reading.
Read the original → react.dev
- #react
- #hooks
- #uselayouteffect
- #performance
- #dom
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.
See open roles