More requirements, not required

The hiring process most of us are using these days is built on the premise that, in order to quickly hire the best candidate, we need to narrow down our pool of applicants as much as possible. And it assumes that the best way to do that is to put up barriers for applicants at the very beginning, which often leads to us writing wish lists longer than a kid’s Christmas list and calling them “requirements” for the job.

I understand why—we’re all busy, we’re all sick of wading through applications from spammy candidates who didn’t even read the posting, and we all need help RIGHT NOW OMG.

The truth is, we can sometimes hire some good people this way. But if we keep doing what we’ve always done, we’ll continue getting what we’ve always gotten: a toxic industry with a real diversity problem. We can and should do better, and the good news is that our job postings are an easy place to start.

A job posting is often a candidate’s first touchpoint with your company, and the gatekeeper that decides who will be in your candidate pool. So, you should make sure your job posting isn’t throwing up unnecessary roadblocks that deter good candidates from applying.

Those roadblocks might look something like this:

• 5-7 years of experience required
• Bachelor’s degree in x or y required

If you aren’t hiring a doctor, lawyer, architect, or another professional required by your jurisdiction to have a degree, I urge you to think about whether or not requirements like these should make it into your job description. Especially if you work in tech.

Here’s why.

College isn’t the only place to learn.

It’s 2018. You can learn things without committing four years of your life and tens of thousands of dollars to the endeavor.

There are great trade schools out there and, in tech, we have bootcamps too. Many even teach best practices and tools that are more immediately relevant in a professional setting than some colleges. Then there is the vast amount of material available to us via books, workshops, online courses, and project-based learning. So many ways to learn!

So, if we want the best candidates possible, why are we limiting our talent pool before we even get started?

Most of our degrees are unrelated anyway.

Few of us make a living at what we studied when we were eighteen. Industries evolve and roles change, but universities are slow to change with them.

My degree is in Interdisciplinary Art. (Interdisciplinary. Art.) I liked college, and I don’t regret studying what I did, but the classes I took in bookbinding and screenprinting in no way prepared me to be the Director of Operations at a tech education startup.

But the work I did as a front-end developer, teacher, event planner, and curriculum designer did prepare me for some aspects of my current job. And the rest I picked up along the way because I’m a smart person who’s capable of learning.

Are you not planning to hire smart people capable of learning? Of course you are!

No one can “hit the ground running.” New employees are going to spend lots of time getting acquainted with your company, your processes, and your product. So let’s all agree to stop using that bogus phrase and level-set our expectations. The sooner we do, the better off our teams and our new hires will be.

(Also, there’s thing called onboarding and it’s really important. But that’s another post.)

When we write job postings at Skillcrush, we ask every hiring manager to critically review the requirements they’ve listed and ask themselves, “Could a great candidate do the job without this?”

If the answer to that question is yes, it’s not a requirement. It’s a bonus. And that’s what section of the job posting it should be in.

People learn different things, at different paces.

Years of experience is not a straightforward metric. Some people work part-time, while others juggle multiple jobs. Some roles are extremely demanding, while others allow you to spend two hours a day subtly flipping between Facebook and BuzzFeed instead of gaining actual work experience.

In addition, people in similar roles learn different things, at different paces. If you’ve ever hired multiple people for the same role and watched them onboard together, you’ve probably witnessed this first hand.

There are better ways to convey the seniority of a role and the skills it requires than “years of experience.” Below are two of my favorites. (And I’m always open to more ways of doing it, if you’ve got ‘em!)

Option A: Defining levels of experience.

You can just say, “This is an early career role” or “This is a mid-senior level role.” Then detail exactly what skills you expect them to have at that level, so applicants know how you’re defining something like “mid-senior.”

What are you hoping they learned while completing that degree or working in the field for x years? I encourage you to focus on communicating those specific skills or traits when writing your requirements for a role.

For example, when I hired a mid-level WordPress developer, the hiring manager and I assumed we’d get a lot of applicants who primarily work on the front end and/or have primarily used WordPress in a client or agency environment. That’s not the context here at Skillcrush, though, so we wanted to make sure sure our candidate pool was full of developers with back-end and product development experience.

Instead of listing years of experience as a requirement, we included the following in our posting:

• Experience developing custom plugins for WordPress
• Experience using Git on a commercial development team
• Deep understanding of HTML, CSS, and JavaScript
• Knowledge of object-oriented PHP

It was more important to us that our candidates have these key requirements than a specific number of years working in the field because these were the things that we were not able or willing to teach them.

We included matching yes or no questions on the application that allowed us to more quickly screen applications. (“Have you developed custom plugins for WordPress?”) Then we asked candidates to explain programming concepts during their interviews, and paid the finalists to do a code exercise so we could see that knowledge in practice. This gave us three opportunities to really make sure they had the technical skills we wanted them to have.

Option B: Not making it a hard requirement.

If you really believe that “years of experience” is the best way to indicate the level of seniority you expect from candidates, well, we can agree to disagree. 🙂

I still encourage you to move it out of your requirements section and into the first few paragraphs you use to initially frame the role. In my opinion, this makes it feel more like what it is – a rough estimate versus a hard and fast rule.

You’ll likely never know for sure if this change makes a difference. But, if it encourages one high-performing future hire to apply when they otherwise would have hesitated, isn’t it worth it?

Fewer requirements doesn’t mean more work for you.

I’m speaking from first-hand experience when I say that education and years of experience requirements don’t lead to more unqualified candidates. This is usually the biggest concern with “lowering the bar,” but it’s never been my experience.

I’ve run informal A/B tests with our hiring at Skillcrush, and it’s made no difference in the amount of time it takes us to hire. We get the same amount of spam applications, and the same amount of unqualified people sending us the same template they’ve sent everybody else.

The places we post the job, how we craft our postings, and the practical questions and exercises we use during our hiring process play a far bigger role in weeding out unqualified applicants than requirements ever did.

It gives everyone a shot.

When you can’t rely on years of experience, you have to dig deeper to really understand what core competencies you’re expecting someone to have developed in their career and take the time to articulate them. It’s a wise investment of your time because your company is awesome and the role you’re trying to fill is a fantastic opportunity for someone.

There are people who could kill it in that job without the exact pedigree you’re imagining. Those people—the ones who can excel in a job without the related degree or hyper-specific experience—may have developed those skills via less traditional training, but those skills might be no less valid. They might even be more valuable for the fact that they were gained outside of the classroom or in a non-traditional setting.

These folks might be some of the brightest applicants, the most independently motivated, the ones so hungry for the opportunity that less open-minded companies won’t give them. I want those people in my candidate pool and on my team, and I’m betting you do too.

Next time you find yourself writing a long list of requirements, I encourage you to consider if there are other ways to describe the knowledge, skills, and abilities required for the role.

Ask yourself, “Could a great candidate do the job without this?”