DEV Community: Gautam

MERN Interview Prep Isn't Just React Prep With Extra Steps

Gautam — Sat, 08 Aug 2026 15:54:04 +0000

Here's a pattern I see constantly: someone lists "MERN stack" on their resume, spends 90% of their interview prep time on React, and then gets blindsided by a question about MongoDB indexing or the Node event loop. Not because they didn't know the answer existed — because they never actually studied it as seriously as they studied hooks and re-renders.

It makes sense why this happens. React is the part everyone's excited about. It's visual, it's the part you build UIs with, it's what most tutorials center around. MongoDB, Express, and Node quietly become "the stuff that connects to React" instead of three separate skill sets an interviewer is going to test just as hard.

The four layers, and where people actually get caught out

A real MERN interview loop touches all four letters, and in my experience the surprises cluster in predictable places:

MongoDB — not "what is MongoDB," but when do you embed data versus reference it with an ObjectId. This is a genuine design decision with real tradeoffs, and a lot of candidates have never had to reason about it out loud before.

Express — middleware is the big one. Not just "what is middleware" but understanding the (req, res, next) signature well enough to explain error-handling middleware specifically, and why forgetting to define one leaks a stack trace in production.

Node — the event loop gets asked constantly, but in a way that trips people up: not "is Node single-threaded" (yes, sort of), but explaining why it can still handle many concurrent requests despite that. That "despite that" is where the real understanding shows.

React — usually the strongest area for most candidates, which is exactly why interviewers sometimes spend less time here and more time probing the other three, assuming you've already got React covered.

A quick self-check

If you're prepping for a MERN-labeled role, try answering these cold, no Googling:

When would you embed a sub-document in MongoDB instead of referencing it?
What's the actual difference between process.nextTick() and setImmediate() in Node?
Why does Express recognize an error-handling middleware function specifically by its four arguments?
What actually happens in the event loop between console.log, a setTimeout, and a resolved promise?

If any of those made you pause longer than a React hooks question would, that's useful information — it's telling you exactly where your prep has been lopsided.

Where I've been drilling this

I've been working through ReactGrind's MERN stack interview questions guide — it's organized by layer instead of dumping everything into one undifferentiated list, which made it a lot easier to see exactly where my Node and Express knowledge was thinner than I thought. 25+ questions with real answers, not just definitions — the kind of thing you'd actually get asked to explain, not just recognize.

Once the non-React layers stop being the weak point, it's worth stress-testing the React side too, since "I know hooks" and "I can explain useEffect vs useLayoutEffect under FAANG-level questioning" are not the same bar. ReactGrind's React interview questions page is organized the same way — by topic and difficulty, from beginner controlled-inputs questions up to a dedicated FAANG set on things like why useEffect runs twice in Strict Mode.

The takeaway

If "MERN stack" is on your resume, all four letters need to hold up under questioning, not just the R. Spend an evening specifically hunting for your weakest layer instead of doing another React refresher you probably don't need as badly as you think.

Why You Still Fumble useEffect After 2 Years of React

Gautam — Sat, 08 Aug 2026 15:43:07 +0000

You know what useEffect does. You could explain the dependency array to a junior dev in your sleep. And yet — be honest — the last time you wrote one under any kind of pressure (a live coding round, a tight deadline, someone watching over your shoulder), did it come out clean on the first try?

If not, you're not bad at React. You've just never actually practiced it.

Knowing ≠ doing

This distinction sounds obvious once you say it out loud, but almost nobody applies it to how they learn React. We read the docs, we watch a tutorial, we nod along — and we quietly assume that comprehension is the same thing as skill.

It isn't. A musician doesn't get good at scales by reading about scales. An athlete doesn't get fast by watching game film alone. Skill comes from repetition under feedback — attempt, get corrected, attempt again. Most React learning skips the "attempt" part entirely and goes straight from "read" to "assume I've got it."

The specific gap: hooks

Hooks are where this gap shows up hardest, because they look simple. useState is one line. useEffect is a function and an array. It's easy to read a hook's signature, feel like you understand it, and never actually hit the edge cases that only show up when you're the one writing the code:

Forgetting a cleanup function until you've got three intervals stacking on top of each other
Mutating an array in state and wondering why nothing re-renders
A stale closure inside an effect that's technically "working" but silently reading last render's value

None of these show up when you're reading someone else's correct code. They only show up when you write it yourself, get it subtly wrong, and have something tell you so.

A dumb-simple fix: the 3x3 drill

Here's a structure that actually works, borrowed straight from how deliberate practice works in any other skill:

Pick three hooks for the week.
For each one, do three challenges — one easy, one medium, one hard.
Timebox each attempt. If you don't pass on the first try, don't peek at a solution immediately — rewrite it from scratch after you've sat with the failure for a bit.

A rough progression that works well:

Week 1 — useState, useReducer, useEffect
Week 2 — useRef, useMemo, useCallback
Week 3 — useContext, useLayoutEffect, useSyncExternalStore
Week 4 — Custom hooks: useDebounce, useInterval, usePrevious

Four weeks, 45 minutes a session, three sessions a week. That's it. That's the whole system.

What "correct" actually means here

The hard part isn't finding hook exercises — the internet is full of them. The hard part is knowing whether your solution is actually correct, not just "looks right to me." A written answer key can't catch a missing cleanup function or a mutated array — those bugs are silent until something breaks in a way you didn't predict.

What catches them is a real test suite mounting your component and interacting with it the way a user actually would — clicking fast, unmounting mid-effect, passing edge-case props. That's a fundamentally different (and much more honest) kind of feedback than eyeballing your own code.

I've been going through exactly this drill myself, hook by hook, using ReactGrind's hooks practice guide — it lays out the mental model and the common mistake for each hook, then links to an actual coding challenge with hidden tests for each one. It's the first resource I've found that treats "I understand this hook" and "I can write this hook correctly under pressure" as the two different things they actually are.

The takeaway

If you've been meaning to get sharper on hooks, skip another article that just explains what they do. You already know what they do. Go write ten of them badly this week, get told exactly where they broke, and rewrite them. That's the whole unlock.

If you want to jump straight in without reading a whole guide first, ReactGrind's full problem set is where the actual challenges live — hooks, state management, performance, the works, each one graded by a hidden test suite instead of an answer key.

AI Can Write Your React Code. It Still Can't Tell You Why It's Wrong.

Gautam — Thu, 16 Jul 2026 07:17:00 +0000

Every few months there's a new wave of "AI just made developers obsolete" takes, and every few months React developers specifically get singled out as the easiest to replace — "it's just JSX and hooks, the model's seen a million examples of that." I've been building with React for a while now, and I've been using AI tools daily for just as long. Here's the actual gap nobody talks about, and it's not the one you'd expect.

AI is genuinely great at the part everyone worries about

Ask any decent model to write a useDebounce hook, a controlled form, a memoized list — it'll produce something that looks right, compiles, and probably works for the happy path. That part of the fear is legitimate. The boilerplate-to-competent-code gap has basically closed.

The part it's still bad at: telling you why your version is wrong

Here's the thing that doesn't show up in demos. AI-generated code looks confident regardless of whether it's actually correct. It'll happily hand you a useEffect with a subtly wrong dependency array, a debounce hook that breaks on rapid unmount, a memoized callback that isn't actually stable — and it'll explain the code with the same confident tone whether the explanation is right or completely made up.

The failure mode isn't "AI can't write React." It's "AI can't reliably tell you when your React is broken, and it can't force you to confront the gap between code that looks plausible and code that's actually correct under real conditions."

Why this matters more for React specifically than people think

React bugs are rarely syntax errors. They're timing bugs, stale closures, unstable references causing silent re-renders, cleanup functions that don't run when you assumed they would. None of that shows up by reading the code. It shows up when the code actually runs against real interaction — fast clicks, rapid typing, a component unmounting mid-effect.

An AI model reading your code can miss all of that, the same way a human skimming a pull request can. The only thing that reliably catches it is running the code against real conditions and checking the actual behavior, not the code's appearance.

So what's actually changing for developers

Not "will AI replace you." The real shift is: the value of writing boilerplate correctly is dropping fast, while the value of knowing whether code is actually correct — being able to reason about edge cases, verify behavior, and catch what an AI-generated confident explanation glossed over — is going up. If your entire skill was typing out a useEffect from memory, that's genuinely less valuable now. If your skill is knowing that a debounce hook needs to survive an unmount mid-timer and being able to verify that it does, that's more valuable than ever, because it's exactly the thing AI output doesn't reliably self-check.

Practically, this means practicing differently

Reading AI-generated React code and nodding along teaches you nothing about whether you could catch the same bug yourself. The instinct that actually matters — spotting a stale closure, knowing when a dependency array is wrong, recognizing an unstable reference — only builds by writing code yourself and getting real, immediate feedback on whether it's actually correct, not whether it looks correct.

This is part of why I built ReactGrind — React-specific coding challenges checked by real automated test suites instead of a written answer key. The whole point is closing that exact gap: you write the component, real tests mount it and interact with it the way a user actually would, and you find out immediately whether it holds up — not whether it merely resembles a correct answer.

AI can write plausible React code all day. Practicing against real tests is still how you build the instinct to know the difference.

Curious what others are seeing here — has your day-to-day debugging shifted at all now that AI writes a bigger share of first-draft code? What's actually catching the bugs for you these days?

I built a LeetCode-style platform, but for only for React (not DSA)

Gautam — Tue, 14 Jul 2026 23:15:10 +0000

If you've ever prepped for a frontend interview, you've probably hit this weird gap: LeetCode will happily grill you on binary trees and dynamic programming, but it has almost nothing to say about the thing you'll actually be asked to build in a real frontend interview — a debounced search box, a modal that traps focus correctly, a component that doesn't quietly re-render itself into a performance problem.

That gap is why I built ReactGrind.

What ReactGrind actually is?

ReactGrind is a coding practice platform built specifically around React — not algorithms, not data structures, just the actual behavior of React itself: hooks, rendering, state, effects, memoization, and the kind of edge cases that only show up once real user interaction is involved.

Every challenge comes with a real automated test suite, not a static answer key. You write a component, hit run, and the tests mount it, click it, type into it, and check the result — the same way a real pull request gets reviewed before it ships. If it passes, you know it actually works. If it fails, you know exactly where.

What's on there right now

50+ problems (adding questions daily) across Hooks & State, Custom Hooks, Performance, Context & Patterns, Forms & Events, and a FAANG-style Interview Set
A React Interview Prep section — 200+ questions with plain-English explanations, analogies, and code examples, not just one-line definitions
A free online React compiler/playground — no signup, no setup, just write and run React code instantly in the browser
A blog covering practical React engineering topics — React 19's actual production impact, MERN stack interview prep, and things like whether React counts as frontend or backend (yes, people really do ask that)

Why test-based practice, specifically?

Writing a debounced search box is easy. Writing one that still works when someone types fast, deletes everything mid-debounce, or unmounts the component while a timer is pending — that's the part that actually gets caught in code review, and it's the part a written answer key can't check for you. A real test suite catches it immediately, which is a much better habit to build than comparing your code to someone else's "correct" solution and hoping it's equivalent.

If you're prepping for a frontend role, or you just want to stay sharp on React outside of whatever you're building at work, it's free to start: reactgrind.com

Since this is early and actively evolving — if you try it and something feels off, missing, or like it should exist but doesn't, I'd genuinely like to hear it. Bug reports, feature ideas, "this problem's test cases are wrong," all of it is useful right now.

10 React Hooks Interview Questions That Actually Trip People Up (With Explanations)

Gautam — Sun, 12 Jul 2026 12:42:05 +0000

If you've been prepping for React interviews, you've probably noticed most interview question lists online are either too basic (what is useState) or copy-pasted from the same five articles. So I put together a list of hooks questions that come up often in real interviews — the kind that sound simple but expose whether you actually understand what's happening under the hood.

Let's go through them.

Why does this useEffect cause an infinite loop?

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    setCount(count + 1);
  });

  return <div>{count}</div>;
}

Answer: No dependency array means the effect runs after every render.
Since it updates state on every run, it triggers another render, which
triggers the effect again — forever. Add [] if you want it to run once, or a proper dependency array if it should run on specific value changes.

What's the difference between useMemo and useCallback?

Both cache something between renders, but:

**useMemo **caches a value (the result of a computation)
**useCallback **caches a function reference

A common gotcha: useCallback(fn, deps) is literally equivalent to
useMemo(() => fn, deps). If you understand that, you understand both.

Why does my state update not reflect immediately after setState?

const [name, setName] = useState("Aman");

function handleClick() {
  setName("New Name");
  console.log(name); // still logs "Aman"
}

Answer: State updates are **asynchronous **and batched. name inside
handleClick is a snapshot from the current render's closure — it won't
reflect the update until the component re-renders.

What problem does useRef solve that useState can't?

useRef gives you a mutable object that persists across renders without
triggering a re-render when it changes. Great for:

Storing a DOM node reference
Keeping a mutable value (like a timer ID) that shouldn't cause a re-render

Why do custom hooks need to start with "use"?

It's not just convention — it's how React's linter (and React itself) knows to apply the Rules of Hooks (no conditional calls, no calls inside loops) to your custom hook. Name it getSomething instead of useSomething and ESLint's hooks plugin won't catch violations inside it.

What's a stale closure, and how does it happen with hooks?

useEffect(() => {
  const interval = setInterval(() => {
    console.log(count); // always logs the initial value
  }, 1000);
  return () => clearInterval(interval);
}, []);

Answer: The effect's closure captures count from the render it was
created in. With an empty dependency array, that closure never updates —
so count is frozen at its initial value forever inside the interval.

When would you use useLayoutEffect instead of useEffect?

Answer: useLayoutEffect runs synchronously before the browser paints. Use it when you need to measure or mutate the DOM before the user sees anything (e.g., preventing a visual flicker when adjusting an element's position). useEffect runs after paint, which is fine for most side effects (data fetching, subscriptions).

Can you conditionally call a hook?

No — and interviewers love asking why, not just that. React tracks hooks
by call order per render, not by name. If a hook is skipped in one render
and called in another, the entire hook-state mapping shifts, causing bugs
that are hard to trace.

What does the dependency array in useEffect actually compare?

Shallow equality (Object.is), not deep equality. This is why passing an
object or array literal as a dependency causes the effect to run on every
render — a new reference is created every time, even if the contents are
identical.

How would you debounce a search input using hooks?

function useDebounce(value, delay) {
  const [debounced, setDebounced] = useState(value);

  useEffect(() => {
    const timer = setTimeout(() => setDebounced(value), delay);
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debounced;
}

The cleanup function is the key part — it cancels the previous timer
whenever value changes before the delay finishes, so only the last
keystroke actually triggers the debounced update.

If you want to test yourself on questions like these interactively (with
instant feedback instead of just reading answers), I've been building
ReactGrind — a LeetCode-style platform specifically
for React.js practice. Still actively adding new challenges, so feedback is very welcome if you try it out.

What's a hooks question that stumped you in an interview? Drop it in the
comments — might turn it into a follow-up post.

DEV Community: Gautam

MERN Interview Prep Isn't Just React Prep With Extra Steps

The four layers, and where people actually get caught out

A quick self-check

Where I've been drilling this

The takeaway

Why You Still Fumble useEffect After 2 Years of React

Knowing ≠ doing

The specific gap: hooks

A dumb-simple fix: the 3x3 drill

What "correct" actually means here

The takeaway

AI Can Write Your React Code. It Still Can't Tell You Why It's Wrong.

AI is genuinely great at the part everyone worries about

The part it's still bad at: telling you why your version is wrong

Why this matters more for React specifically than people think

So what's actually changing for developers

Practically, this means practicing differently

I built a LeetCode-style platform, but for only for React (not DSA)

What ReactGrind actually is?

What's on there right now

10 React Hooks Interview Questions That Actually Trip People Up (With Explanations)

Why does this useEffect cause an infinite loop?

What's the difference between useMemo and useCallback?

Why does my state update not reflect immediately after setState?

What problem does **useRef **solve that **useState **can't?

Why do custom hooks need to start with "use"?

What's a stale closure, and how does it happen with hooks?

When would you use useLayoutEffect **instead of **useEffect?

Can you conditionally call a hook?

What does the dependency array in useEffect actually compare?

How would you **debounce **a search input using hooks?

What problem does useRef solve that useState can't?

When would you use useLayoutEffect instead of useEffect?

How would you debounce a search input using hooks?