Most DSA Problems Are Repetitions

Avatar photoByAdil

At some point while preparing for interviews, something odd happens.

You solve a problem, move on, then a few days later you see another one that feels… familiar. Different story, different variables but the same underlying logic.

At first, it feels like a coincidence. But, it isn’t.

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.

Read carefully.
Start from scratch.
Try a few approaches.
Hope something clicks.

So when problems start repeating, it can feel like you’re “cheating” by reusing ideas like you’re not really learning.

That framing is what 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.
We reuse known approaches.
We 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

This part took me a while to accept.

Difficulty usually doesn’t come from brand-new ideas.
It comes from combining familiar ones.

In practice:

  • 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 whether you can hold multiple constraints and invariants in your head at the same time.

Why grinding eventually stops helping

This is where a lot of people get stuck.

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

  • you overfit to specific questions
  • you forget solutions quickly
  • the next variation still feels “new”

But if you 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 starts feeling 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
  • even 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.
Not as tricks.

But as a way to make the learning process feel less random and less intimidating.

I’ve been slowly 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.

Similar Posts