.png)
We've all seen the job posting. "Minimum seven years of experience required." It sits there like a gatekeeper, quietly rejecting candidates before a human ever reads their resume. And we think it's time to admit something uncomfortable: this filter tells you almost nothing about whether someone can actually do the job.
Here's the problem. Years of experience measures time served, not capability gained. Two engineers can both list six years on their resume. One spent those six years solving increasingly complex problems, shipping production systems, mentoring juniors, and adapting to three different tech stacks. The other spent six years doing the same task on repeat, in a role that never demanded growth. On paper, they're identical. In practice, they're nowhere close.
We think hiring managers know this deep down. Ask any technical lead who has interviewed a candidate with a decade of experience only to find they can't explain a basic architectural tradeoff. Ask any recruiter who has placed a three year candidate who ran circles around applicants with twice the tenure. The stories are everywhere. Yet the filter persists, quarter after quarter, req after req.
Years of experience survives as a filter because it's easy. It's a number. You can plug it into an applicant tracking system and let it do the sorting for you. No judgment required, no nuance, no risk of a hiring manager having to justify why they moved a candidate forward. It's a proxy that feels objective, even when it isn't measuring the thing anyone actually cares about.
There's also a liability angle. If a hire goes badly, "they had eight years of experience" sounds like a defensible decision. "We assessed their actual skills through a technical exercise and found strong signal" sounds riskier to explain after the fact, even though it's the better process. We think this is a case where the easy answer and the right answer have quietly diverged, and organizations keep choosing easy.
If tenure doesn't predict performance, what does? We'd argue for three things that matter far more.
First, depth in the specific problem space. A candidate who has spent two focused years deep in identity and access management will likely outperform a generalist with six scattered years across a dozen different domains, when the job is specifically about securing access controls. Specificity beats duration almost every time.
Second, evidence of adaptation. Technology moves fast, and the candidates worth betting on are the ones who show a pattern of picking up new tools, frameworks, and problem types without needing a year of onboarding each time. Ask about a moment they had to learn something unfamiliar under pressure. The answer tells you more than any resume line.
Third, how someone talks about tradeoffs. A skilled engineer, product manager, or analyst can walk you through a decision they made and explain what they gave up to get it. Weak candidates describe what they did. Strong candidates describe why, and what they'd do differently now. That reflective quality doesn't correlate cleanly with years on the job. Some of the sharpest reasoning we've seen has come from people three years into their career who are simply paying close attention.
Every time a strong candidate gets filtered out because they're at four years instead of five, that's a real cost. It's a missed hire, a longer time to fill, and often a less diverse slate, since rigid tenure requirements disproportionately screen out people who took nontraditional paths into a field, changed careers, or spent time in roles that built relevant skills without the matching job title.
Meanwhile, the candidates who do clear the tenure bar aren't guaranteed to be strong. They've simply avoided being screened out by one blunt instrument. The actual evaluation, the part that determines whether they can do the job, still has to happen. So why let the blunt instrument decide who even gets that evaluation in the first place?
We're not arguing that experience is meaningless. Someone who has never touched a codebase shouldn't be leading a platform migration. But there's a wide gap between "some relevant experience" and "exactly this many years." The former is a reasonable floor. The latter is a lazy proxy dressed up as rigor.
If we had to replace the years filter with one question, it would be this: what has this person actually built, solved, or shipped that resembles what we need them to do here? That question takes more effort to answer than reading a number off a resume. It also gets you a far better hire.
We'd rather spend an extra fifteen minutes on a technical screen than lose a great candidate to an arbitrary cutoff. The organizations that figure this out first will simply have better talent than the ones still filtering on tenure. That's the whole opinion, really. Stop counting years. Start assessing skill.
