Most DSA Problems Are Repetitions

Source: Dev.to

The quiet realization

Most DSA problems aren’t truly new.
They’re variations—different constraints, slight tweaks, new wording.
But underneath, the same few ideas keep coming back:

• Two pointers
• Sliding windows
• Prefix sums
• Binary search
• A bit of hashing

Once you notice that, it’s hard to unsee it.

Why this feels uncomfortable at first

A lot of us are taught to treat every problem as something unique:

1. Read carefully.
2. Start from scratch.
3. Try a few approaches.
4. Hope something clicks.

So when problems start repeating, it can feel like you’re “cheating” by reusing ideas, as if you’re not really learning. That framing makes DSA feel harder than it needs to be.

This is how engineering actually works

In real systems we don’t reinvent solutions either. We:

• Recognize structure.
• Reuse known approaches.
• Adapt patterns to constraints.

DSA is no different. Interview problems aren’t testing how original you are; they’re testing whether you can:

• Recognize structure
• Choose the right abstraction
• Reason about trade‑offs
• Explain why your approach works

Repetition isn’t a weakness of the system—it’s the signal.

How difficulty really increases

Difficulty usually doesn’t come from brand‑new ideas; it comes from combining familiar ones.

• Easy problems → one pattern
• Medium problems → one or two patterns
• Hard problems → usually two, occasionally three

That’s it. The jump from easy to medium isn’t about intelligence; it’s about holding multiple constraints and invariants in your head at the same time.

Why grinding eventually stops helping

If you keep solving problem after problem without pausing to extract the pattern, you:

• Overfit to specific questions
• Forget solutions quickly
• Let the next variation feel “new”

Instead, stop and ask:

• What pattern is this really testing?
• What invariant is being maintained?
• Which constraints force this approach?

Then repetition becomes an advantage instead of a frustration. You start recognizing problems earlier—sometimes within the first minute. That’s when DSA becomes manageable.

What helped me the most

The biggest shift for me was changing the question I asked myself.

• Instead of: “Can I solve this problem?”
• I started asking: “Which pattern is this trying to test?”

Once I could answer that, everything else followed more naturally:

• The approach
• The edge cases
• The complexity
• The explanation

The code itself often became the least interesting part.

Why I’m leaning into this publicly

This idea that DSA is mostly structured repetition is what I’m building around right now—not as shortcuts or tricks, but as a way to make the learning process feel less random and less intimidating. I’ve been documenting patterns, invariants, and ways to recognize them in one place (indexedcode.com), mostly as a reference I wish I’d had earlier. This newsletter is where I think out loud as I do that.

What’s next

In the next post I’ll write about how I identify the right pattern early, usually before thinking about code at all. It’s not magic; it’s mostly about constraints, keywords, and knowing what to ignore.

If DSA has been feeling repetitive lately, that’s probably a good sign—you’re starting to see the structure.