DEV Community: Animesh Sarker (231-115-074)

Understanding useEffect — The Hook I Got Wrong for Months

Animesh Sarker (231-115-074) — Sat, 21 Feb 2026 19:14:25 +0000

I used useEffect for months before I actually understood it.

I knew the syntax. I could make it work. But I had a collection of habits I'd picked up by trial and error — like always adding // eslint-disable-next-line react-hooks/exhaustive-deps when the linter complained, or passing an empty array [] whenever I just wanted something to run once.

It worked. Until it didn't. And when it didn't, I had no idea why.

This post is the explanation I wish I'd had from the start.

What useEffect Actually Is

Most tutorials explain useEffect as a way to run "side effects" — data fetching, subscriptions, manually touching the DOM. That's true, but it doesn't help you think about it correctly.

Here's a better mental model:

useEffect lets you synchronize your component with something outside of React.

That "something" could be an API, a browser API like document.title, a timer, a WebSocket — anything that lives outside React's render cycle. Every time your component renders, React checks whether the things your effect depends on have changed. If they have, it re-runs the effect.

That reframe changes everything. You're not "running code after render." You're keeping an external system in sync with your component's state.

The Dependency Array — What It Actually Means

This is where most people (including me) get confused.

useEffect(() => {
  document.title = `Hello, ${name}`;
}, [name]);

The second argument — [name] — is the dependency array. It tells React: "re-run this effect whenever name changes."

There are three forms:

No dependency array — runs after every single render:

useEffect(() => {
  console.log('This runs every render');
});

Empty array [] — runs once, after the first render:

useEffect(() => {
  console.log('This runs once on mount');
}, []);

Array with values — runs when any of those values change:

useEffect(() => {
  fetchUser(userId);
}, [userId]);

The rule is simple: every value from your component that the effect uses should be in the dependency array. Props, state, context — if your effect reads it, it belongs in the array.

The reason people reach for eslint-disable is they don't want the effect to re-run when a dependency changes. But that's usually a symptom of a different problem — either the effect is doing too much, or the component state isn't structured correctly.

The Bug I Kept Creating

Here's a real example of the mistake I made over and over:

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(data => setUser(data));
  }, []); // ⚠️ Missing userId in deps

  return <div>{user?.name}</div>;
}

This looks fine. It fetches the user on mount. But what happens when userId changes — like when you navigate from one user's profile to another? The effect doesn't re-run. You're still showing the old user's data.

The fix is obvious once you see it:

useEffect(() => {
  fetch(`/api/users/${userId}`)
    .then(res => res.json())
    .then(data => setUser(data));
}, [userId]); // ✅ Now re-fetches when userId changes

Cleanup Functions — The Part Everyone Skips

Every useEffect can optionally return a function. That function runs when the component unmounts, or before the effect runs again.

useEffect(() => {
  const timer = setInterval(() => {
    setCount(c => c + 1);
  }, 1000);

  return () => clearInterval(timer); // cleanup
}, []);

Without the cleanup, that interval keeps running even after the component is gone — a classic memory leak.

The same pattern applies to subscriptions, event listeners, and WebSockets:

useEffect(() => {
  window.addEventListener('resize', handleResize);
  return () => window.removeEventListener('resize', handleResize);
}, []);

Think of the cleanup as: "before I run this effect again, undo what the last run did."

The Race Condition Nobody Warns You About

Here's a subtle bug that useEffect makes easy to accidentally create:

useEffect(() => {
  fetch(`/api/users/${userId}`)
    .then(res => res.json())
    .then(data => setUser(data)); // ⚠️ Could set stale data
}, [userId]);

Imagine userId changes quickly — from 1 to 2. Two fetches start. If the fetch for user 1 completes after the fetch for user 2, you end up displaying user 1's data even though the component should be showing user 2.

The fix is to use a cleanup flag:

useEffect(() => {
  let cancelled = false;

  fetch(`/api/users/${userId}`)
    .then(res => res.json())
    .then(data => {
      if (!cancelled) setUser(data);
    });

  return () => { cancelled = true; };
}, [userId]);

Now if the effect re-runs before the fetch completes, the previous fetch's result is ignored. Clean, no library required.

A Mental Checklist

Before I finalize any useEffect, I now ask myself:

What external system am I syncing with? If I can't answer this clearly, maybe I don't need a useEffect at all.
Does my dependency array include everything the effect reads? If not, I'm asking for stale data bugs.
Does this effect create anything that needs cleanup? Timers, listeners, subscriptions — always clean up.
Can this effect cause a race condition? If it involves async, think about what happens if it runs twice.

When You Don't Need useEffect

One thing I've learned — the best useEffect is often the one you don't write.

Derived state, computed values, even some event responses don't need useEffect at all. Before reaching for it, ask: can this be calculated directly during render? Can it go in an event handler instead?

useEffect is powerful, but it's also a common source of bugs when overused. Use it for synchronization with external systems — and for not much else.

I'm Animesh, a CS final year student learning React and full-stack development. If this helped, follow me here on dev.to for more posts like this.

How I Solved My 300th Problem on Codeforces

Animesh Sarker (231-115-074) — Sat, 21 Feb 2026 19:13:11 +0000

I remember the exact moment I solved my first problem on Codeforces. It was a simple A-level problem — check if a number is even or odd, essentially. I submitted it, saw the green Accepted, and felt like I'd just cracked a bank vault.

500 problems later, that feeling hasn't gone away. It's just harder to earn.

This post isn't a tutorial. It's an honest reflection on what the journey from 0 → 500 actually looked like — the patterns I noticed, the walls I kept hitting, and what eventually broke through them.

The First 100: Enthusiasm Over Everything

The first hundred problems were pure momentum. I was solving easy A and B level problems, mostly brute force, occasionally stumbling into greedy. Every acceptance felt like a win.

What I got wrong here: I was chasing count, not depth. I'd solve a problem, see Accepted, and immediately move on. I never asked why it worked. I never tried to find a cleaner solution. I never read the editorial after solving.

That came back to bite me around problem 150, when I started hitting problems that required actual thinking — and I had no toolkit to reach for.

Lesson: Solve fewer problems, understand them more deeply. An Accepted verdict is the beginning of learning, not the end.

The 100–200 Wall: When Brute Force Stops Working

This was the hardest stretch. Problems started requiring real algorithms — binary search, prefix sums, basic graph traversal. And I had no idea how to recognize which technique applied to which problem.

I'd read a problem, stare at it for an hour, and give up. Or worse — I'd code a brute force solution that passed small test cases but TLE'd on the large ones, and I had no idea why.

The thing that helped most wasn't grinding more problems. It was slowing down and topic-grinding instead. I spent a full week on just binary search — reading the theory, solving 15 tagged problems, and really internalizing the pattern. Then a week on graphs. Then sorting and greedy.

After that, when I saw a new problem, I had something to ask: "Does this smell like a graph problem? Could binary search work here?"

Lesson: Learn techniques deliberately before trying to apply them under pressure.

200–250: Learning to Think, Not Just Code

Somewhere around problem 250, something shifted. I started actually reading problems more carefully before opening my IDE. I started sketching small examples on paper. I started thinking about edge cases before submitting.

My acceptance rate improved. My solve time dropped. Problems that used to take 2 hours started taking 45 minutes.

I also started doing something that changed everything: reading editorials even after I solved a problem. Not just when I was stuck — always. It was humbling. My O(n²) solution that barely passed? There was an O(n log n) approach that was elegant and obvious in hindsight. I started collecting these patterns like trading cards.

I also started participating in actual rated contests around this time. Contests are brutal. There's a timer. There's pressure. You can't look things up. And honestly — contests taught me more per hour than any amount of casual practice. The pressure forces you to think clearly, not just mechanically.

Lesson: Editorials are free mentorship. Use them even when you don't need them.

250–300: The Problems That Beat Me First

By the time I was approaching 500, I'd been humbled enough to genuinely enjoy hard problems — even when they destroyed me. A problem I couldn't solve in 3 hours still taught me something. I started writing down every new idea or technique I encountered, keeping a personal "patterns notebook."

The 500th problem specifically was a DP problem involving interval states. I spent two days on it. I drew out the state transitions on paper four or five times before they clicked. When I finally submitted and saw Accepted, I didn't feel triumphant — I felt tired and grateful. Which is, I think, what real learning feels like.

What Actually Matters After 300 Problems

Looking back, here's what I actually learned — not about algorithms, but about learning itself:

Consistency beats intensity. Solving 2 problems a day for a year beats cramming 20 problems in a weekend and burning out. My Codeforces streak was never perfect, but it was consistent enough.

Struggle is the curriculum. The problems I gave up on after 20 minutes taught me nothing. The ones I sat with for 2 hours, even without solving them, rewired how I think.

Community accelerates growth. Reading other people's solutions — especially ones that were shorter and smarter than mine — was one of the highest-leverage things I did. Codeforces has a culture of clean, clever code. I learned to want that too.

Rating is a lagging indicator. There were stretches where I solved a lot but my rating barely moved. It felt discouraging. But the skills were compounding quietly — and they showed up eventually in contests.

What's Next

300 is a milestone, but it's not a destination. I'm still a mid-level solver on a good day. There are people on Codeforces who've solved 3,000+ problems and can see the solution to things I'd struggle with for days.

But that's what I love about competitive programming. There's always more to understand. The ceiling keeps moving.

If you're somewhere in your first 100 problems and it feels slow — it's supposed to feel slow. You're building a mental model that will pay off later. Keep going.

Thanks for reading. If you want to follow along with my CP journey, my Codeforces handle is animesh_sarker.

DP Patterns Every CP Solver Should Know

Animesh Sarker (231-115-074) — Sat, 21 Feb 2026 19:04:24 +0000

Dynamic programming has a reputation for being the hardest topic in competitive programming. I used to agree with that.

Then I realised something: most DP problems aren't unique. They're variations on about six core patterns. Once you internalise those patterns, you stop treating each DP problem as a new puzzle and start asking: "which pattern is this?"

This post breaks down the six patterns I keep coming back to. For each one, I'll explain the core idea, show a simple example in C++, and point you to a representative problem to practice.

Pattern 1: Linear DP (1D State)

Core idea: The answer for position i depends only on answers at earlier positions.

This is the most foundational pattern — the building block everything else extends from.

Classic example: Longest Increasing Subsequence

int lis(vector<int>& a) {
    int n = a.size();
    vector<int> dp(n, 1);

    for (int i = 1; i < n; i++)
        for (int j = 0; j < i; j++)
            if (a[j] < a[i])
                dp[i] = max(dp[i], dp[j] + 1);

    return *max_element(dp.begin(), dp.end());
}

dp[i] = length of the longest increasing subsequence ending at index i. To find dp[i], look at every earlier element that's smaller and take the best.

When to recognize it: The problem involves a sequence, and the answer for each element depends on some subset of previous elements.

Practice: Codeforces 340E, LeetCode 300

Pattern 2: Grid DP (2D State)

Core idea: State is a position (i, j) on a grid. Transitions come from adjacent cells — usually up and left.

Classic example: Minimum Path Sum

int minPath(vector<vector<int>>& grid) {
    int m = grid.size(), n = grid[0].size();
    vector<vector<int>> dp(m, vector<int>(n, INT_MAX));
    dp[0][0] = grid[0][0];

    for (int i = 0; i < m; i++) {
        for (int j = 0; j < n; j++) {
            if (i == 0 && j == 0) continue;
            int best = INT_MAX;
            if (i > 0 && dp[i-1][j] != INT_MAX) best = min(best, dp[i-1][j]);
            if (j > 0 && dp[i][j-1] != INT_MAX) best = min(best, dp[i][j-1]);
            dp[i][j] = best + grid[i][j];
        }
    }
    return dp[m-1][n-1];
}

When to recognize it: Grid, matrix, or 2D table. Movement is restricted (usually right/down only). Count paths, minimize cost, maximize value.

Practice: Codeforces 166E, LeetCode 64

Pattern 3: Knapsack DP

Core idea: You have items with weights and values. You can pick or not pick each item. Maximize value subject to a capacity constraint.

This pattern is deceptively broad — "knapsack thinking" applies to many problems that don't look like packing bags.

Classic 0/1 Knapsack:

int knapsack(int W, vector<int>& wt, vector<int>& val) {
    int n = wt.size();
    vector<vector<int>> dp(n+1, vector<int>(W+1, 0));

    for (int i = 1; i <= n; i++) {
        for (int w = 0; w <= W; w++) {
            dp[i][w] = dp[i-1][w]; // don't take item i
            if (wt[i-1] <= w)
                dp[i][w] = max(dp[i][w], dp[i-1][w-wt[i-1]] + val[i-1]); // take it
        }
    }
    return dp[n][W];
}

Key variants to know:

0/1 Knapsack — each item can be taken at most once
Unbounded Knapsack — each item can be taken unlimited times (coin change)
Subset Sum — can we reach exactly target weight?

When to recognize it: "Select items/elements, subject to a total limit, maximize/minimize something."

Practice: Codeforces 459B, LeetCode 416 (Subset Sum variant)

Pattern 4: Interval DP

Core idea: State is a subarray or subrange [l, r]. To solve [l, r], you split it at some midpoint k and combine the answers for [l, k] and [k+1, r].

This pattern shows up in matrix chain multiplication, burst balloons, palindrome partitioning, and similar problems.

Classic example: Minimum Cost to Merge Stones

The general structure looks like this:

// dp[l][r] = optimal answer for subarray [l..r]
for (int len = 2; len <= n; len++) {
    for (int l = 0; l + len - 1 < n; l++) {
        int r = l + len - 1;
        dp[l][r] = INT_MAX;
        for (int k = l; k < r; k++) {
            dp[l][r] = min(dp[l][r], dp[l][k] + dp[k+1][r] + cost(l, r));
        }
    }
}

Notice the iteration order: solve smaller intervals first, then larger ones. This ensures that when you compute dp[l][r], dp[l][k] and dp[k+1][r] are already solved.

When to recognize it: The problem involves a sequence, and the optimal solution for a range depends on splitting it somewhere.

Practice: Codeforces 149D, LeetCode 1000

Pattern 5: DP on Trees

Core idea: State is a node. You compute the answer for a subtree rooted at each node using the answers of its children.

// Standard tree DP template
void dfs(int node, int parent) {
    dp[node] = base_value;
    for (int child : adj[node]) {
        if (child == parent) continue;
        dfs(child, node);
        dp[node] = combine(dp[node], dp[child]);
    }
}

Classic example: Maximum Independent Set on a Tree

For each node, consider two states: include the node in the set, or exclude it.

// dp[v][0] = max independent set in subtree of v, v NOT included
// dp[v][1] = max independent set in subtree of v, v included

void dfs(int v, int p) {
    dp[v][1] = 1; // include v
    dp[v][0] = 0; // exclude v
    for (int u : adj[v]) {
        if (u == p) continue;
        dfs(u, v);
        dp[v][1] += dp[u][0]; // if v included, children must be excluded
        dp[v][0] += max(dp[u][0], dp[u][1]); // if v excluded, children can go either way
    }
}

When to recognize it: The problem is on a tree. Answers propagate from leaves to root. Subtrees are independent.

Practice: Codeforces 161D, LeetCode 337

Pattern 6: Bitmask DP

Core idea: State includes a bitmask representing a subset of elements. Used when n is small (usually ≤ 20) and you need to track which elements have been used.

Classic example: Travelling Salesman Problem

// dp[mask][i] = min cost to visit all cities in mask, ending at city i
int n = cities.size();
vector<vector<int>> dp(1 << n, vector<int>(n, INT_MAX));
dp[1][0] = 0; // start at city 0

for (int mask = 1; mask < (1 << n); mask++) {
    for (int u = 0; u < n; u++) {
        if (!(mask & (1 << u))) continue;
        if (dp[mask][u] == INT_MAX) continue;
        for (int v = 0; v < n; v++) {
            if (mask & (1 << v)) continue;
            int next_mask = mask | (1 << v);
            dp[next_mask][v] = min(dp[next_mask][v], dp[mask][u] + dist[u][v]);
        }
    }
}

The bitmask mask tracks which cities have been visited. mask & (1 << i) checks if city i is in the set.

When to recognize it: Small n (≤ 20). You need to track which elements have been selected or visited. "Optimal assignment" or "cover all elements" problems.

Practice: Codeforces 327E, LeetCode 847

How to Actually Use These Patterns

Knowing the patterns isn't enough. You need to practice recognizing them before you can apply them under contest conditions.

My approach:

Pick one pattern at a time
Solve 8–10 tagged problems for that pattern — easy to medium difficulty
After each problem, write down in plain English: "this was a [pattern] problem because..."
Only move to the next pattern when you can identify the current one within 2–3 minutes of reading a problem

The recognition is the hard part. The coding, once you see the pattern, is usually mechanical.

One more thing: write your own transitions from scratch each time. Don't copy templates. The act of re-deriving the state definition and transition yourself is what builds the intuition. Templates make you fast but fragile — you want to be slow and robust first.

Summary

Pattern	State	Key Question
Linear DP	`dp[i]`	What's the best ending at position `i`?
Grid DP	`dp[i][j]`	What's the best to reach cell `(i,j)`?
Knapsack	`dp[i][w]`	What's the best using first `i` items with capacity `w`?
Interval DP	`dp[l][r]`	What's the best for subrange `[l,r]`?
Tree DP	`dp[v]`	What's the best for the subtree rooted at `v`?
Bitmask DP	`dp[mask][i]`	What's the best having visited the set `mask`, last at `i`?

These six patterns won't cover every DP problem you'll ever see. But they'll cover most of them — and more importantly, they'll give you a framework for thinking about the ones that don't fit neatly.

I'm Animesh, a CS final year student and competitive programmer. Follow along for more algorithm breakdowns and CP content.