Making Sense of “Number of Years of Experience” in Technical Recruitment

“3+ years experience with Ruby on Rails or similar web frameworks (i.e. Django)”

“5-10 years of experience in software development, framework architecture and design”

“7 years of experience in a full stack environment, building large scale consumer web applications”

There are endless examples of these requirements listed on typical job descriptions.  Many people, including job seekers, hiring manager and recruiters, recognize that “X years of experience” is a highly unreliable proxy to gauge someone’s capabilities.  Then, why do we keep using “number of years of experience” to describe what we are looking for?  Isn’t there anything else better?

In technical recruiting, looking for “hard skills” in candidates is unavoidable.  Should we be using “number of years of experience” to guide our evaluation in technical recruiting?  Given that we deal with a mostly left-brained crowd, we’d like to look deeper at this ambiguous, vague, and treacherous method to evaluate candidates.  Hopefully, with some careful thoughts, we can figure out a way to be more objective and stay true to our logical selves.

I’m excited to have Dusty Jewett joining me in this conversation.  Dusty is a Software Engineer in Seattle, who has led and mentored teams to build large scale software solutions at companies like Simply Measured and Turbo Patent. He also managed the Seattle Web App Developers Meetup.  Here are some thoughts Dusty shared with me –

Different Ways of Using “Number of Years of Experience”

When we look at someone who has never worked on a software team – in other words, an entry-level developer, this person will be doing many things that are crucial for making high quality software for the first time.  The way work gets done on a team, such as how an individual communicates and interacts with the team, might seem obvious.  But, unfortunately, it often is not to those who are brand new to this process and environment.

This means, for someone having never done professional level work in a team environment, there will be a significant learning curve.  Therefore, when estimating how well someone can work on and with a team, the number of years of experience does correlate.

However, when it comes to comparing “number of year of experience” in specific tech skills, say JavaScript or Ruby on Rails, this measure becomes elastic.  Although it’s obvious that someone who has a two-month experience working on a JavaScript project would be less effective when compared to someone with 7 years, it’s very difficult to know where to draw the line to define the point of diminishing return.

Finding Someone’s Technical Skill Boundaries

Over the years, Dusty developed a rubric with 43 elements to figure out a person’s standing in the following technical areas –

• Computer Science
• Software Engineering
• Infrastructure Engineering
• Programming
• UX / Design
• Experience
• Knowledge
• Learning
• Leadership

Dusty used this rubric during on-boarding to help someone figure out where they stand, know what they want to learn and how to move forward in their career. This is valuable to determine what types of work assignment would be the best fit for this person.

However, we need to use something simpler in a job interview situation to know if bringing this person on board that would be mutually beneficial.  The key indicators Dusty looks for during interviews include:

• Do you show a history of learning new things?
• Do you show a history of learning more than what you need to know?   

These are not to be mistaken for “Does the candidate have the technical understanding in certain areas?”  Because being on a startup engineering team, Dusty needs to hire a team of people willing to move fast, especially on the front-end, and willing to learn whatever it takes because startups need to move forward with new technologies.

Having someone who will learn above and beyond the minimum amount of knowledge to finish the tasks is a more important factor when evaluating candidates for Dusty’s team than specific technical skills.

Should We Get Rid of “Number of Years of Experience” when Hiring?

The “number of years” measurement is there to filter out the obviously under-experienced and under-qualified candidates and to give a general indication of for what the “missing ingredients” might be.  There’s no over-whelming evidence of how completely ignoring someone’s experience level would make the candidate evaluation better.

Knowing that “number of years of experience” as a measurement is far from perfect, we should use it cautiously and avoid putting too much weight in it.  When applied judiciously, it can guide us to ask the right questions during the interview process.

Don’t forget to sign up for our newsletter and follow us on Twitter@g33kology to get more articles like this to help you learn more geek language.