4 Examples of What Skills-Based Hiring Is Not

It’s January. 

I’m seeing TA professionals roll up their sleeves, ready to get stuck into 2024, armed with all sorts of good intentions. 

I’m seeing them commit to getting to grips with skills-based hiring: understanding what it means for them, how it may influence their hiring habits this year, how they can put it into practice… 

And while I’m convinced that it’s never been easier to “do” skills-based hiring, and that there are many resources and tools available, I feel like something might be missing. Indeed, I’ve read a lot about what skills-based hiring is… but heard little about what it is not. 

I’ve collected some real-life examples from conversations with recruiters and hiring managers in my network. Here are four down-to-earth examples of hiring practices that may look, sound or feel like skills-based hiring… but really aren’t.

Experience does not necessarily equate to skills

Picture this: You’re hiring a back-end engineer. You’ve identified a list of key skills required for this particular role. Proficiency in Java is at the top of your list. You post a job description where it is clearly stated that Java is a necessary skill to be successful in the role. You begin to receive applications. You select candidates with 5 or more years of Java experience and pass them through to the first stage of your process. 

What’s the catch? Objectively enumerating the necessary skills for a role (both technical skills and soft skills) is a must, the 101 of skills-based hiring, if you will. However, it’s not enough. If you don’t then go on to objectively evaluate those skills… *fervently shakes head*. 

While professional and personal experience are an integral part of what a candidate can bring to your role and company, experience does not necessarily equate to skills. 

A developer with 5+ years of experience with Java won’t necessarily have the level of mastery you’re looking for. Similarly, a candidate with less years of experience, may well surprise you. 

What to do instead: Instead of setting experience requirements, give everyone a chance to prove their skills. Assess their Java proficiency through an asynchronous coding test and a structured, collaborative programming interview.

Ideally, send a reasonable and engaging technical test to anybody and everybody who’s interested in your opening. 

If that’s simply not feasible, try to hone in on the most objective and relevant screening criteria possible.

That could be team-lead experience, startup vs. enterprise experience, b2b vs. b2c experience, knowledge of specific industries… That shouldn’t be age, gender, level of education, specific school, specific company, specific number of years of experience…

The interview question pick ‘n’ mix

Picture this: You’re working on creating a structured, standardized interview process. You compile a list of interview questions that are likely to provide you with a deeper understanding of a candidate’s skills. You provide your interview panel with this list ahead of time and encourage them to draw from it during their discussion. 

What’s the catch? Standardizing and scripting your interview questions is a step towards objective skills analysis. However, this initiative becomes counterproductive when questions are then chosen arbitrarily during the interview. 

If you’re not asking candidates the same questions, to assess the same skills, you’re creating room for bias and you’re making fair and objective comparison much more difficult. 

What to do instead: True skills-based hiring demands a more deliberate approach. Ensure that interview questions are standardized and directly aligned with specific skills, rather than a haphazard selection.

Make sure that each person on the interview panel knows which questions they are responsible for asking. Bonus tip: you also want to determine, in advance, what bad, good and excellent candidate responses look like.

This skill, or that skill, or maybe this skill

Picture this: You’re hiring an applications developer. You’ve collaborated with the hiring manager to establish a list of necessary hard and soft skills for the role. You’ve worked on a plan to assess each of these skills. You agree that you won’t be able to assess all of the skills listed, in depth, during the hiring process. Depending on candidates’ resume and past experiences, you choose to assess what seems most relevant (gray areas, non-negotiables, areas of particular interest…).

What’s the catch? Listing the necessary skills for the role? Yes. Testing different candidates on different skills? No.  

What to do instead: It’s unlikely that you’ll be able to evaluate every single skill that might come in useful for a role during your recruitment process. However, to be able to make fair, skills-based hiring decisions, you need to assess each applicant on the same set of skills. This will provide you with an objective basis for comparison. Prioritize in advance, select the “must-have skills” for the position and align on how you’ll evaluate them.

Laying the groundwork… and ending up at the bar

Picture this: The HR team puts time and effort into building an internal process, writing detailed job descriptions, standardizing candidate communications, etc. Candidates move through a short, engaging and structured process. Those that make it through to the technical interview meet the hiring manager. The hiring manager “talks shop”, and digs deep into varying technical subjects and interests, during a natural and enjoyable conversation. 

What’s the catch? I’m not saying that an interview can’t be enjoyable. I’m not saying that you don’t want to put candidates at ease. However, I am saying that a “beer test” type interview introduces tons of bias and will pull you away from a skills-based approach.

You can lay all of the groundwork, your process loses its integrity as soon as hiring managers resort to subjective judgments based on personal feelings rather than a candidate’s demonstrated skills.

What to do instead: Work on building a strong relationship with hiring managers. Support and coach them. If they understand what you’re trying to do and why, they’re more likely to welcome new habits. Structure, collaboration and assuming good intentions can go a long way.