I Wasn’t Great at DSA. Here’s How I Still Cracked Tech Interviews

If you’ve prepared for software engineering interviews, you already know the drill.

Open LeetCode.
Pick a random problem.
Solve it (or don’t).
Repeat.
Again.
And again.

At some point, you start wondering:
Is this actually making me a better engineer — or just better at solving puzzles?

That question bothered me for a long time.

I was never “great” at DSA — and that’s okay

Let me be honest.

I was never the person who could breeze through 300–500 DSA problems and feel confident. I understood the basics. I could reason through problems. But grinding endlessly? That drained me.

What I did enjoy was:

Designing systems
Solving practical, real-world problems
Understanding trade-offs
Explaining why something works, not just that it works

And yet, every piece of advice online seemed to say the same thing:

“Just grind more LeetCode.”

So I tried. And I burned out.

image info

The problem with the endless DSA grind

Here’s what bothered me about the traditional approach:

Problems felt random
There was no sense of priority
I had no idea if what I was solving was even relevant for the company I was interviewing for
It optimized for volume, not signal

DSA is important — don’t get me wrong.
But blindly solving hundreds of problems felt like studying everything instead of studying what actually matters. (unless you really enjoy solving DSA problems, which I clearly did not)

That’s when I decided to step back and ask a different question:

What are companies actually asking in interviews right now?

A simple idea that changed everything

Instead of guessing what to prepare, I decided to find out.

I built a small system for myself — a web crawler that scans the web and collects recently asked interview questions from real companies.

Not theoretical.
Not outdated.
Not “top 100 from 2017”.

Just what candidates are being asked today.

You can see it here:
👉 https://interviewtruth.fyi/recent-questions

This was so much fun to build. It was just me solving my own problem in my own way.

Preparing with intent, not anxiety

Once I had that data, my preparation changed completely.

Instead of:

Solving random problems
Chasing streaks
Feeling guilty for skipping problems

I started:

Focusing on recurring patterns
Preparing high-signal questions
Understanding why certain problems show up again and again

I still studied DSA — but selectively.
With context.
With purpose.

And alongside that, I was building something real — a project I genuinely cared about.

The unexpected benefit: better interviews

Something interesting happened during interviews.

When I spoke to hiring managers:

I wasn’t just talking about algorithms
I was talking about decisions
About trade-offs
About building and maintaining systems

My web crawler project became a conversation starter.
It showed how I think.
How I approach ambiguity.
How I solve problems beyond a whiteboard.

Within about 6 months, I had offers from multiple companies.

Not because I cracked every hard problem —
but because I prepared intelligently and played to my strengths.

This is not “anti-DSA” advice

Let me be very clear.

This is not saying:

DSA doesn’t matter
You should skip fundamentals
Everyone should follow this path

DSA is table stakes.

But endless, unfocused grinding is not strategy.

Especially if:

You’re an experienced engineer
You enjoy systems and real-world problem solving
You want preparation to feel meaningful, not soul-crushing

A better question to ask yourself

Instead of asking:

“How many problems have I solved?”

Try asking:

“Am I preparing for the interviews I’m likely to face?”

That mindset shift made all the difference for me.

Final thoughts

If LeetCode grinding works for you — great.
If it doesn’t — you’re not broken.

There are smarter, more intentional ways to prepare.

Sometimes, the best thing you can do for your career is stop following the default advice and start solving your own problems.

That’s exactly what I did.