Let’s Stop Talking About YOE
If you’ve looked for a job recently, this should look familiar to you:
“12 years of software development experience in one or more general-purpose programming languages.”
That’s taken directly from a job description for a Staff Engineer at Google.
Or maybe you’re looking for your first job out of college, and you see something like this for the entry-level position that you’re looking at:
“1+ years of software development experience.”
Let’s talk about years of experience (YOE) as a metric.
Why do we use YOE?
You’ll often find YOE used to describe minimum requirements for a role. Companies might use it to describe overall development experience (e.g., “3 years of software development experience”), experience with specific programming languages (e.g., “2+ years of experience with Python”), or experience with particular frameworks (e.g., “4+ years of experience with ReactNative”).
The use of YOE as a metric comes from the idea that the longer you do something, the better you get at it. Another way of putting that is “practice makes perfect.” Talking about YOE makes it easy to quantify a candidate’s experience and compare it against others. A hiring manager would feel pretty confident that a candidate with eight years of Android development experience would be a stronger developer than one with only four years.
In a world in which we’re trying to eliminate bias when it comes to hiring, a metric that is so easy to quantify sounds attractive. In our example above, it’s easy to justify hiring the developer with eight years of experience over the one with only four. In fact, if we were talking about a role that required “6 years of experience with Android development, including Java and Kotlin”, the person with only four years of experience might not even choose to apply.
So why should we care? If we’re looking for a senior engineer, and we’ve decided that it takes about six years of experience to become one, we shouldn’t care that someone with only four years of experience might not apply. In fact, we’d probably view that as a success! But should we?
Why shouldn’t we rely on YOE?
Not all paths are linear
The problem with YOE is that it assumes that all career paths are linear. It assumes that we all learn at the same rate. It assumes that we’re all offered the same learning opportunities. It assumes that we all have the same backgrounds. In short, it assumes a lot!
As a direct counter-argument to the idea that “practice makes perfect”, American football coach Vince Lombardi suggests that “only perfect practice makes perfect.”
“Practice doesn’t make perfect, only perfect practice makes perfect.”
— Vince Lombardi
What does that mean? Let’s say that I’m trying to memorize my ABC’s. I spend hundreds, even thousands of hours practicing them. But without realizing, I had been practicing “A-B-C-D-E-F-Z”. Unless I had realized my mistake and corrected it, or someone had pointed it out to me, I would still be making that mistake — despite my hours and years of practice. The same thing happens with people’s work experience.
A person might graduate from college and spend 10 years doing contract work where they don’t really have any developers around them to learn from. Or they might be at a company that doesn’t care to develop their junior engineers. Or at a company with senior engineers that don’t really know what they’re doing. In all of those environments, that person probably wouldn’t grow as a software engineer nearly as much or as quickly as a person in a different environment.
Further, the amount of experience that a person has when they first enter the workforce can vary greatly. Someone who has been doing software development since they were young is going to have more experience coming out of college than someone who only started developing when they took their first CS class. Someone who did internships throughout college or even high school is going to have more experience than someone who didn’t.
On top of that, not everyone learns at the same pace. Even given the same environment and opportunities, some people will take longer to pick up new skills and to level up their current ones.
Just to be clear, none of these things make one person a better engineer than another. They just mean that those two engineers might take different amounts of time to get to the same level of experience.
To make things even more complex, you have to factor in people who might be considered more “non-traditional” — people who might have switched careers midway through their life, people who taught themselves how to code, or people who put themselves through coding bootcamps. Some companies even offer programs that help people new to full-time software engineering ramp up quickly.
Keeping all of these things in mind, it becomes difficult to see years of experience as a useful metric on its own. The person with four years of experience might have been in a work environment where they were encouraged to learn and great mentors. The person with eight years of experience might have been in a work environment where they were on their own and had to teach themselves everything.
Not all positions are equal
As you move up the career ladder, there become more and more types of engineers at your level. If we’re talking about a senior engineer, are we talking about someone who works heads-down to power through complex projects? Are we talking about someone who leads the team, pushing people to drive their projects to completion? Or are we talking about someone who has a lot of experience mentoring junior engineers and really getting the most out of them?
All of the above are examples of different “flavors” of senior engineers — and it’s not an exhaustive list. So why do we try to reduce it to the number of years of experience they have?
YOE can bias your applicant pool
We talked above about how including YOE as a requirement could prevent qualified candidates from applying if they don’t meet that bar. But more than that, we need to realize that it won’t affect everyone in the same way.
Most people have heard some version of: women only apply for a job if they meet 100% of the qualifications, but men will apply for the same job with only 60%. That comes from a report from within Hewlett Packard. And it has often been used as evidence that “women need to have more faith in themselves.”
In 2014, the Harvard Business Review conducted a survey of 1,000 men and women. The conclusion? Women were more likely not to “see the hiring process as one where advocacy, relationships, or a creative approach to framing one’s expertise could overcome not having the skills and experiences outlined in the job qualifications”. In short, they were turned away by perceptions of the hiring process, not themselves.
In fact, this can be broadened to anyone who doesn’t feel like the hiring process is designed for them. That means that you could unknowingly bias your applicant pool against under-represented minorities. Little things like this matter. Words matter.
Why? Saying that you’re looking for someone with at least X years of experience is very binary — very black and white. You either have at least X years of experience, or you don’t. And if you don’t, that feels very disqualifying; you don’t meet one of the seemingly most important qualifications and that’s a huge disadvantage to come back from.
Some YOE requirements make companies look bad
It’s one thing for a company to ask for “10+ years of experience” in a programming language like C, which has been around since the 70s. But what if you’re talking about a newer language or framework? Maybe you want someone with “10+ years of iOS development experience”. You know that iOS development is done in Swift these days, so you ask for “10+ years of experience with Swift”. The only problem is that Swift has only been around for about six years.
You might think that situations like this are uncommon, but Twitter is full of examples of job descriptions asking for impossible amounts of experience.
Not only is this confusing, but it doesn’t create a great impression of the team or company posting the job description.
What should we do instead?
Since we use YOE as a shortcut to describe the skills that we’re looking for, we have to spend some time thinking about what we’re actually looking for our prospective employee to do. What will they be doing day-to-day? For a senior iOS engineer, we might come up with the following:
- Writing code day-to-day in a mixture of Swift (90%) and Objective-C (10%)
- Working with Android and web developers to drive cross-platform parity
- Contributing to app architecture and system design
- Breaking down complex projects into milestones, working with others to clarify ambiguity
- Mentoring junior engineers, helping them grow as developers
- Working closely with product, design, and QA partners to ensure the best experience for our users
- Writing high-quality automated testing to make sure that our code does exactly what we expect
The above describes what we might expect from a prospective senior iOS developer. It provides a lot more information to a prospective candidate than just saying “6+ years of iOS development experience”. It helps them envision the work that they would be doing.
By giving prospective applicants a better idea of what their day-to-day responsibilities would be, it gives them more information as to whether they would be a good fit for that job.
And most importantly, it helps give the impression that they will be evaluated more holistically than just based on their years of experience. The more inviting your job description is, the more people are likely to apply — and the less you’ll alienate potentially great candidates.
Do you agree? Is there something that I missed? Please comment below or let me know on Twitter!
