One of the most misleading things about DSA is the difficulty label.
Easy.
Medium.
Hard.
It looks useful. It feels objective.
But over time, I’ve found it does more harm than good especially when you’re actually trying to get better.
Difficulty feels random for a reason
If you’ve ever felt this, you’re not alone:
- Some “easy” problems feel impossible
- Some “hard” problems click instantly
- You solve a medium one day, struggle with another the next
At first, it’s easy to blame yourself.
Maybe you’re inconsistent. Maybe you’re not good at DSA.
But the issue isn’t you.
It’s the label.
Difficulty isn’t about complexity
Most people assume difficulty means:
- harder math
- trickier code
- more clever ideas
That’s rarely true.
In practice, difficulty mostly reflects how many patterns are involved, and how cleanly they’re combined.
From my experience:
- Easy problems usually test one pattern
- Medium problems combine one or two
- Hard problems usually use two, occasionally three
Almost never more than that.
Once you see this, the labels start to lose their power.
Why “easy” problems can feel hard
An “easy” problem feels hard when:
- you haven’t mastered that specific pattern yet
- the problem hides the pattern behind a story
- the invariant isn’t obvious immediately
It’s not easy because it’s trivial.
It’s easy because, once you recognize the pattern, the solution is straightforward.
Without that recognition, even easy problems feel painful.
Why “hard” problems sometimes feel easy
On the flip side, a hard problem can feel surprisingly manageable when:
- you’ve seen the underlying patterns before
- the combination makes sense to you
- you can reason about the invariants independently
At that point, you’re not solving a “hard” problem.
You’re just coordinating familiar ideas.
The label doesn’t reflect your experience anymore your preparation does.
Difficulty is subjective, patterns aren’t
This is the part I wish someone told me earlier.
Difficulty labels are:
- subjective
- relative
- influenced by popularity and platform heuristics
Patterns are:
- stable
- reusable
- transferable across problems and companies
When you focus on patterns, your progress becomes measurable.
When you focus on difficulty, it feels noisy and inconsistent.
How I approach problems now
I don’t ask:
“Is this problem hard?”
I ask:
- How many patterns does this involve?
- Do I already understand them individually?
- Are they interacting, or just sequential?
That framing turns something vague into something concrete.
A “hard” problem becomes:
“Two patterns I already know, combined slightly awkwardly.”
That’s a much less scary problem to work on.
Why this matters while learning
If you let difficulty labels drive your learning:
- you avoid “hard” problems too early
- you overvalue “easy” problems for too long
- you tie progress to external tags instead of internal clarity
If you let patterns drive your learning:
- you know exactly what you’re weak at
- you know what to practice next
- progress feels intentional, not accidental
That difference compounds over time.
This is also how interviews work
Interviewers don’t think in terms of “this is a hard problem.”
They think in terms of:
- Which concepts does this test?
- Can the candidate recognize structure?
- Can they reason about constraints clearly?
Difficulty labels are for platforms.
Patterns are what interviews actually evaluate.
Where I’m going with this
This way of thinking patterns first, labels last, is what I’m trying to make explicit in my own learning and in what I’m building.
Once you stop fearing “hard” and start dissecting structure, DSA becomes a lot calmer.
Still challenging.
But no longer intimidating.
What’s coming next
In the next post, I want to write about why mastering arrays alone gets you much further than most people expect, and why arrays quietly sit underneath a huge chunk of DSA.
If difficulty labels have been messing with your confidence, try ignoring them for a while.
Focus on the patterns instead.
It changes everything.
I’ve been indexing patterns and the signals that point to them in one place indexedcode, mostly as a reference for myself. Writing about it here helps me refine that thinking.
Top comments (0)