Reconsidering DSA in Tech Hiring: A Builder’s Perspective

Have you ever spent hours grinding LeetCode, only to wonder: Is this what software engineering is really about? Data structures and algorithms (DSA) dominate tech hiring, especially at big tech companies. They’re a measurable way to test coding skills, logic, and problem-solving under pressure. But as someone who’s been through the DSA gauntlet and come out the other side, I’m starting to question: Are we filtering for the right kind of talent?

DSA isn’t the enemy—it’s a useful tool. But when it becomes the only lens for evaluating engineers, we risk missing out on builders, pragmatists, and innovators who don’t shine in 90-minute coding puzzles. Let’s rethink how we hire and what we’re optimizing for.

My Journey: From LeetCode to Real Systems

I’ll be honest: I’ve played the DSA game. I’ve solved hundreds of LeetCode problems, climbed the rankings, and honed my ability to reverse a linked list faster than you can say “time complexity.” That grind taught me discipline, code precision, and a deeper understanding of algorithms. It wasn’t a waste.

But there was a moment when I hit a wall. I wasn’t building anything. I was solving abstract puzzles that felt disconnected from the real world. So I pivoted. I started writing compilers, tinkering with machine learning models, contributing to open-source projects, and designing tools to solve problems I cared about. That’s when my growth as an engineer truly took off.

I learned how to structure a codebase, manage dependencies, deploy systems, and iterate on feedback. These skills—not my ability to invert a binary tree blindfolded—made me a better engineer. And yet, most tech interviews barely test for them.

Why DSA Matters (and Where It Falls Short)

Let’s give DSA its due. It’s a scalable way to screen candidates. It tests foundational computer science knowledge and ensures a baseline of coding fluency. For roles in infrastructure, backend systems, or search algorithms, DSA skills often correlate with success. It’s also democratic—anyone with an internet connection and determination can study and compete.

But here’s the catch: DSA is a narrow lens. Not every great engineer excels at solving decontextualized puzzles under a ticking clock. Some shine when building maintainable systems, designing APIs, tuning ML models, or collaborating on open-source projects. These aren’t “soft” skills—they’re the backbone of modern software engineering.

By making DSA the primary gatekeeper, we might be filtering out engineers who are already productive in real-world contexts. Think about it: the person who can debug a production outage or architect a scalable API might not ace a graph traversal problem. Are we okay with losing that talent?

Redefining “Quality” in Hiring

We all agree: quality matters. Tech companies manage massive infrastructure, serve billions of users, and ship mission-critical products. There’s no room for mediocrity. But “quality” isn’t just about acing a coding challenge. It’s about:

• Writing maintainable code: Can they structure a codebase that’s easy to extend and debug?
• Understanding trade-offs: Do they know when to optimize for speed vs. scalability?
• Debugging in production: Can they stay calm and methodical when things break?
• Building iteratively: Can they ship something useful and improve it over time?

DSA tests some of these skills, but not all. It also favors candidates who’ve had the time and resources to practice a specific type of problem-solving, often outside real-world constraints. This can exclude builders who excel at shipping software but aren’t optimized for puzzle-solving.

A Broader Lens for Hiring

So, what’s the alternative? Replacing DSA entirely isn’t practical—it scales well, and portfolios or project reviews are harder to standardize. But we can complement DSA with approaches that capture a wider range of skills. Here are a few ideas:

Value GitHub activity: A candidate’s open-source contributions or personal projects can reveal their ability to write real code and collaborate.

Give take-homes real weight: Well-designed take-home projects mimic real engineering tasks and let candidates show their process.

Review documentation and wikis: Writing clear docs or contributing to wikis shows communication and systems thinking.

Incorporate system design: Practical discussions about architecture or trade-offs can test real-world problem-solving.

These aren’t perfect solutions. They’re harder to scale and evaluate. But if we care about innovation, we need to experiment with hiring processes that let diverse talent shine.

Final Thoughts: Let’s Hire Builders

Some of the most transformative technologies of the next decade might never be built—not because the talent isn’t there, but because we filtered it out with a 90-minute coding challenge. That’s not a quality filter; it’s a missed opportunity.

DSA has its place, but it’s not the whole story. Let’s start optimizing for engineers who can build, contribute, collaborate, and grow—not just those who can solve puzzles the fastest. The sooner we broaden our lens, the stronger our industry will be.

What do you think? Have you faced the DSA grind in interviews? How would you change tech hiring to value builders? Share your thoughts in the comments—I’d love to hear your perspective!