Why Big Companies Still Ask for DSA in Interviews

No, this post isn’t selling a course. This is just me sharing some real talk and reflection on an ongoing debate in tech: DSA (Data Structures and Algorithms) vs. Projects / Web Development.

The Never-Ending Debate

There’s been a lot of noise online lately—posts, YouTube rants, influencers pushing "real-world dev over DSA", and a bunch of developers blaming companies for having a "broken hiring process."

I get it. I used to be in that camp too. Early in my career, I never bothered with DSA. Interviews were mostly about your resume, the projects you built, and a machine round. That was it. Nobody cared if you could balance a binary tree.

But here’s the thing—the industry has changed, the tech stack has evolved, and so has the complexity of the systems we’re building. And with that, the value of DSA has only increased.

Been on Both Sides

After over a decade in tech—starting as an engineer, moving into tech lead role, and then leadership—I’ve now sat on both sides of the interview table. I finally get why big companies still lean so heavily on DSA.

It’s not that they hate web dev or your cool projects. It’s about something else entirely.

Inside the Engineering meeting Room

Trust me, when engineers sit down to design a system, or solve a probelem , they don’t start with:

“Should we use React or Angular?”

They start with:

“What are the constraints?” “How do we handle scale?” “How do we reduce latency or ensure consistency?”

The language comes later. The solution comes first. And being good at DSA means you’re naturally good at thinking in terms of solutions.

The Hiring manager's Perspective: Hiring Problem Solvers

Let me tell you what happens inside these big orgs:

A React developer might end up working on a backend service in Java in their next project.

A mobile engineer could be pulled into designing system architecture for a high-scale service.

A team often includes people from varied backgrounds—Java, Python, Go, C++—but they all need to solve the same core problems together.

So, from a CTO’s, Hiring maanger's, Director of Engineering’s perspective, the goal is not to hire someone who knows just one framework or language.

The goal is to hire someone who can:

1 . Understand problems deeply

2 . Break them down logically

3 . Communicate their approach clearly

4 . And implement solutions in any language

And that’s where DSA comes in.

It’s language-agnostic. It shows how you think, not just what you’ve memorized.

So... DSA or Web Dev?

Short answer: Both.

Don’t think of it just from an interview perspective. Think of it from the lens of becoming a solid, well-rounded engineer.

If you only do web dev, you might get by initially. But without problem-solving chops, you’ll hit a ceiling.

If you only do DSA and can’t build a working product, that’s not helpful either.

The balance I recommend:

Use Web Dev to get a job and ship real projects

Use DSA outside your job to keep your brain sharp and grow long-term

But... Isn't the Hiring Process Broken?

Let’s be honest—it’s not perfect.

But also, it’s not completely broken.

Hiring at scale is hard. Large companies don’t want to miss out on great engineers, but they also need a consistent and scalable way to evaluate thousands of candidates across locations and time zones.

And DSA? It’s one of the best tools we have today to assess raw problem-solving ability across the board.

It’s not that they don’t want to hire—you just have to show them you’re more than a framework. They want to hire engineers, not just developers.

Final Thoughts

Don’t get sucked into the DSA vs. Web Dev war. It’s a false binary.

If you want to grow in your career, work on both. DSA is your gym. Web dev is your real-world match. You need both to stay in shape.

Happy Learning