I bombed a React interview once. Not because I didn't know the answers — but because I answered the wrong question. 🧵 The interviewer asked: "What's the difference between useCallback and useMemo?" I gave a textbook answer. Correct. Complete. Totally missed the point. The real question was: "Do you know when NOT to use them?" That one experience made me rethink how I prepare. Here's what I now know goes into a truly strong React interview — 7 concepts that actually matter in production: ───────────────────────────── 1. useCallback vs useMemo Not just what they do — but why blindly using them can hurt performance more than help. Memoization has a cost. 2. React reconciliation + the key prop The key prop isn't just for lists. Misusing it causes components to silently remount. Most devs never debug this because they don't know to look for it. 3. Closures and stale state A useEffect that captures an old value of state — and you spend 2 hours wondering why your data is always one step behind. Classic stale closure. Once you see it, you can't unsee it. 4. Shallow copy vs deep copy in state updates {...obj} feels safe. But if your object has nested arrays or objects, you're still mutating shared references. React won't re-render. The UI lies to you. 5. Preventing re-renders in large trees React.memo alone isn't enough. If your callbacks aren't stable and your context isn't split — you're still re-rendering everything. The fix is a combination, not a single tool. 6. Controlled vs uncontrolled components Choosing wrong here leads to either overengineered forms or state that React can't track. Both hurt in different ways. 7. useEffect cleanup with async calls If you don't cancel async operations on unmount, you'll set state on a component that no longer exists. AbortController is underused. Race conditions are underestimated. ───────────────────────────── 3.6 years of React has taught me that the difference between good and great frontend engineers is almost never syntax. It's knowing why something breaks — before it breaks. 💬 What's the trickiest React bug you've ever debugged? Drop it below 👇 #ReactJS #Frontend #JavaScript #WebDevelopment #SoftwareEngineering #ReactDeveloper #TechCommunity
Very relatable. The hardest React questions are often not about API knowledge, but about judgment — knowing what to optimize, what to simplify, and what can quietly break later.
I’ve definitely been in situations where React code “worked” but performance told a different story later in production. Especially memoization misuse — learned it the hard way too
These are such daft questions to ask in an interview in all reality. And honestly, the real answer is that you should almost never use them at all. It's almost never required. It's very rare that these things are actually required and make a difference. But asking about specific apis for specific libraries is always a bit of a red-flag to me. Likely, the interviewer themselves are not particularly experienced or strong. And this question likely hints at the fact that they're not even particularly strong at React - because it's such a cheesy interview question and it hints at the fact they're probably "optimising" for things that don't matter, which implies a lack of maturity.