We Stopped Hiring 'Senior' Engineers—We Hired Problem Solvers

By 2024, our hiring rubric for "Senior Software Engineer" was incredibly precise. We wanted exactly 8-12 years of React experience, deep knowledge of distributed systems, and a background in high-growth startups or Big Tech. We were paying $250k+ per role and getting exactly what we asked for: experienced, highly-specialized professionals who were remarkably inefficient at actually solving problems.

The "Senior" title has become a proxy for tenure, not talent. A "Senior" engineer often has 10 years of experience doing the same thing one year at a time. They are often experts in a specific ecosystem (like AWS or React) but are completely lost when faced with a problem that doesn't have a clear StackOverflow answer or a well-documented API.

We realized that we weren't hiring engineers; we were hiring credential-holders. We stopped. We threw away the years-of-experience requirement, we stopped testing for framework trivia, and we started hiring purely for problem-solving ability. Here is why the "Senior" title is a trap and why you should hire for adaptability instead.

The Specialization Curse

The modern tech industry rewards hyper-specialization. You're not just an engineer; you're a "Senior iOS Engineer" or a "Staff Backend Engineer (Java)." This is great for large, stable organizations, but it's deadly for startups and mid-sized companies that need to pivot.

We hired a "Senior Infrastructure Engineer" from a major cloud provider. He was brilliant at Terraform and Kubernetes. But when we had a critical performance bottleneck in our Node.js API, he was useless. He wouldn't touch the application code because it "wasn't his domain." He waited for the "Senior Backend Engineer" to handle it. We had two highly-paid seniors waiting for each other while the site was down.

In contrast, we hired a "Problem Solver" with only three years of experience. He didn't know much about Kubernetes, but when the site went down, he spent four hours reading the docs, two hours debugging the traces, and fixed the issue. He didn't care about his "domain"; he cared about the problem. He was more valuable than the specialist who had triple his tenure.

The 'Senior' Rigidity

Many "Senior" engineers arrive with a heavy cargo of "Best Practices" that they refuse to leave behind. They spent five years at [Big Tech Co] doing things a certain way, so they assume that's the *only* way to do it. They try to impose complex enterprise architectures on simple startup problems.

We had a senior architect who insisted on building a multi-region, event-driven microservices architecture for a product that had exactly 500 users. Why? Because that's what he did at Amazon. He was more interested in the purity of the architecture than the reality of the business. He spent six months building infrastructure for scale we wouldn't reach for five years.

Problem solvers, on the other hand, are pragmatic. They ask: "What is the simplest way to solve this right now?" They are willing to write "ugly" code if it gets the job done and allows the business to survive. They don't have an emotional attachment to "Best Practices" that don't fit the context.

How We Test for Problem Solving

We stopped asking LeetCode questions. We stopped asking about the internals of React's reconciliation engine. Instead, we give candidates a real, broken system. We tell them: "Here is a small Node.js app that is supposed to calculate taxes but currently crashes on Mondays and is extremely slow. Fix it however you like."

This test reveals three critical things:

• Can they navigate the unknown? Almost nobody knows the codebase. The candidate who starts reading the logs and searching for the error is a problem solver. The candidate who says "I don't know this library" is a specialist.
• Do they prioritize correctness? The candidate who fixes the crash first and then optimizes the speed is a pragmatist. The candidate who tries to refactor the entire app before fixing the bug is a "Senior" who will slow you down.
• Are they curious? When they find the fix, do they understand why it worked? Or did they just copy a fix from Google?

The Results

Since we stopped hiring for "Seniority" and started hiring for "Problem Solving," our execution speed has tripled. Our teams are smaller, more autonomous, and significantly more adaptable. We have "Junior" engineers who are more productive than "Staff" engineers at other companies because they aren't afraid to dive into any part of the stack.

We pay these problem solvers extremely well—often more than we used to pay "Seniors." We aren't trying to save money; we're trying to gain speed. A nimble, curious engineer with 3 years of experience is worth five "Senior" specialists in a fast-paced environment.

Conclusion

The "Senior Software Engineer" title is becoming as meaningless as "Expert" on a resume. If you define seniority by years in a seat, you are hiring for endurance, not excellence.

Hire for curiosity. Hire for adaptability. Hire for the ability to solve a problem without a map. The tech world changes too fast for specialists to survive. The future belongs to the generalists who can learn anything and fix anything.