Debugging a React Hydration Mismatch
You have a React SSR page that warns that hydration failed because the server HTML doesn't match the client. How would you debug it and fix it?
what they're testing: Whether you understand that hydration asserts the server and client render the same thing, and can trace a mismatch to its nondeterministic input instead of just silencing the warning.
The diagnosis is that the server HTML and the client's first render produced different output. Hydration attaches React to the existing HTML rather than rebuilding it, so those two outputs have to match. An update after hydration is fine; it's only that first render that has to agree.
I'd reproduce with the development build, use the mismatch warning to narrow it to the smallest component, and compare the inputs on each side. Usually it's one of a few suspects:
- a
typeof windowbranch or a browser-only API Date.now(),Math.random(), or anything time or locale dependent- data that changed between server and client without a serialized snapshot
- invalid HTML nesting that the browser silently repairs
The fix is to make that first render identical on both sides. Most often that means sending the server's data snapshot with the HTML and initializing the client from it, instead of recomputing a different value during hydration. If some UI genuinely has to differ in the browser, I render the same stable fallback on the server and the first client pass, then switch it in an Effect once hydration is done.
What I wouldn't do is reach for suppressHydrationWarning as a general fix. It's a one-level escape hatch for an unavoidable text difference like a timestamp, and it won't patch mismatched content for you.
Why it lands
- Starts from the exact invariant: server output must equal the first client render.
- Turns the warning into a focused search for nondeterministic inputs.
- Gives concrete fixes for shared data and for genuinely client-only UI.
- Treats warning suppression as a narrow escape hatch, not a repair.
Where people slip
- I'd just add `suppressHydrationWarning` wherever React complains.
- Hydration mismatches are usually just a `window` check, so I'd fix that and move on.
- I'd disable SSR for the whole component instead of tracing which input differs.
- React will patch the server markup anyway, so the warning is harmless.
If they push further
What actually happens on a mismatch? Does React just patch it?
No. React discards the server-rendered DOM for that subtree and re-renders it on the client, so you lose the SSR work and can get a visible flash. It's a recoverable error, not a silent fix.
When is suppressHydrationWarning genuinely the right call?
Only for a single element whose text is legitimately environment-dependent, like a formatted date. It silences one node, one level deep, and never reconciles structure or child components.
How would you catch these before they hit production?
Treat the dev-mode warning as a failure in CI, and wire onRecoverableError to your monitoring so real-user mismatches surface as signals instead of silent flashes.
Sources
Now answer it yourself.
Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.
beta
The interviewer part is in the works.
The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.