Building in Public: How I Think About DSA (and Why I’m Sharing It)

Source: Dev.to

I want to build in public, write about how I think, and share what I’ve learned while actually using DSA—not just preparing for it.

How my view on DSA changed

At some point, DSA stops being about problems.

You start noticing that:

• The same ideas keep repeating
• Most “hard” problems aren’t new; they’re combinations
• The real difficulty is recognizing what applies, not writing code

That shift didn’t happen because I solved hundreds of problems.
It happened when I stepped back and asked why the same patterns kept showing up.

Once you see that, DSA feels less like a grind and more like a set of mental models.

What I believe now

This is my current, very opinionated take:

• You don’t need endless problem‑solving
• You need standalone mastery of patterns
• Easy problems usually use one pattern
• Medium problems combine one or two
• Hard problems rarely go beyond that

If you can explain the invariant, you’re most of the way there.

When I say “understand”, I don’t mean memorizing templates.
I mean being able to explain why a certain approach works and why others don’t.

What I’ll write about here

This won’t be about:

• LeetCode dumps
• Speed‑running problem lists
• “Crack X in Y days” content

Instead, I’ll write about:

• How I recognize DSA patterns from constraints
• Why certain patterns work (and when they don’t)
• How difficulty in interviews is often misunderstood
• How these same ideas show up in real systems
• What I’m building, and rethinking, along the way

Think of this as engineering notes, written out loud.

Building in public

Alongside this, I’m building indexedcode, a pattern‑first way to learn DSA.

• Not a course.
• Not a leaderboard.
• Not a grind.

More like a reference I wish I had earlier, one that focuses on patterns, invariants, and decision‑making.

I’ll share what I build, what I change, and what I get wrong.
If it helps someone else think more clearly, that’s a win.

Who this is for

This is probably for you if:

• DSA feels harder than it should be
• You’re preparing for interviews but tired of brute force
• You care more about understanding than memorizing
• You like slowing down and reasoning things through

If not, that’s okay too.

What’s next

I’ll start with things like:

• Why most DSA problems are repetitions
• How I identify the right pattern early
• Why difficulty labels are misleading
• How mastering array patterns alone gets you surprisingly far

I don’t have a fixed schedule. I’ll write when there’s something worth sharing.

If any of this resonates, feel free to stick around. I’ll build in public and hopefully learn alongside a few of you.

Backend engineer. Thinking a lot about DSA, systems, and how engineers actually reason.

indexedcode in public.