Skills-based hiring has moved from buzzword to boardroom priority remarkably quickly. Every HR conference has it somewhere on its agenda, it’s on the lips of every HR Leader we talk to, and most of the technology vendors we work with have retrofitted their platforms with some version of "skills capabilities" in the last 18 months.
But here's what we’re actually seeing in implementations: there's genuine confusion about what these skills features actually do. Specifically, organisations don't understand the difference between skills inference and skills validation, which causes problems down the line when the system doesn't deliver what they expected.
So let's clear it up.
What's the actual difference?
Skills inference is when technology makes educated guesses about a person's skills based on other information. If your CV says you were a "Senior Marketing Manager at a B2B SaaS company for three years," the system infers you probably have skills in demand generation, marketing automation, stakeholder management, and so on. It's about looking at patterns - what do people with similar roles and backgrounds typically know how to do?
Skills validation is when you've actually verified that someone has a skill through some form of evidence. They've passed an assessment, earned a certification, completed a practical task, or had a manager confirm they can do something to a certain standard.
The distinction matters because they solve different problems and come with different risks.
Why inference sounds appealing (and where it goes wrong)
Inference is genuinely useful for a specific purpose: it helps you find people you wouldn't otherwise have considered.
Let's say you're hiring for a role that needs project management skills. Your ATS can infer that a candidate who spent 5 years as an event manager likely has project management skills, even though they've never held a job with "Project Manager" in the title. That's powerful for diversity and internal mobility - you're not just recycling the same profiles that match obvious keywords.
The technology here varies wildly in sophistication. Some systems are doing little more than keyword matching with a skills taxonomy bolted on. Others - like Eightfold AI or Beamery - are using genuine machine learning that gets smarter over time, analysing patterns across millions of profiles. When we're implementing platforms, one of the first questions we ask is: "Show us what's actually happening under the hood here." Because if the vendor can't explain their inference logic, you're essentially trusting a black box.
The problem with inference is the risk of false positives. Yes, that event manager might have project management skills. Or they might have spent five years coordinating logistics while someone else handled budgets, timelines, and stakeholder management. The system has no way of knowing which is true. It's made a probabilistic guess.
For opening up your talent pool and generating long lists, that's fine. For making actual hiring or deployment decisions, it's risky. We've seen clients get burned by moving someone into a critical role based on inferred skills that turned out not to exist at the level required.
Why validation sounds sensible (but often isn't practical)
Skills validation gives you confidence. Someone has demonstrated they can actually do the thing, not just that they've been in proximity to it.
In theory, this is what HR has always wanted - make decisions based on demonstrated capability rather than credentials and gut feel. And for certain roles and certain skills, it's absolutely the right approach. If you're hiring developers, having them complete a coding challenge through something like HackerRank or Codility tells you far more than their CV ever will. If you're assessing broader skills like problem-solving or communication, platforms like Vervoe or TestGorilla let you create practical simulations. If you need a qualified accountant, you need to see the ACCA or equivalent.
But here's where validation falls apart in practice: it doesn't scale, and it can actually narrow your diversity if you're not careful.
Running assessments costs money and takes time. If you validate every skill for every candidate, your recruitment process becomes glacially slow and your cost-per-hire goes through the roof. We've seen organisations get so committed to validation that they end up with assessment fatigue - both for candidates (who drop out) and for hiring managers (who stop engaging with the process).
There's also a more subtle issue. Validation tends to favour people who already have formal proof - certifications, portfolios, previous job titles that gave them the chance to demonstrate skills. That can inadvertently screen out exactly the non-traditional candidates that skills-based hiring is meant to include. The career-changer or the person returning from a break often has the capability but not the paperwork.
The implementation decisions no one tells you about
When we're configuring recruitment platforms, there are specific decision points where the inference vs validation question comes up, and clients often aren't prepared for them.
Skills libraries and taxonomies: Every platform now wants you to use their skills taxonomy. Some have inference built into how those taxonomies work - the system will suggest skills based on a job title or CV parsing. Others require you to manually tag everything. You need to decide upfront: are we inferring skills from application data, or are we only recording what candidates explicitly claim?
Matching algorithms: Most modern ATS platforms will give candidates a "match score" against a job. How much of that score comes from inferred vs stated skills? If the system infers that someone has 12 relevant skills but they've only claimed 3, are they a 30% match or an 80% match? We've had clients completely misunderstand why certain candidates were being surfaced because they didn't grasp what the algorithm was inferring. SmartRecruiters and Pinpoint handle this quite transparently, but some platforms are much more opaque about their scoring logic.
Internal mobility: This is where inference really shines - and where validation is almost impossible to implement. If you're trying to map your internal talent and identify people for new roles, you can't practically assess everyone's skills. You need inference to make those talent pools visible. Platforms like Gloat, Fuel50, and Workday's talent marketplace are built entirely around this use case - using inference to surface internal opportunities and redeployment options. But you probably want some validation layer before actually moving someone into a new position.
Candidate experience: Asking candidates to self-assess their skills (a form of light validation) seems reasonable but often produces garbage data. People are either too modest or wildly overconfident. Having them complete assessments before you've even screened their application creates drop-off. Getting the validation sequencing right matters enormously.
The compliance dimension that actually affects decisions
Here's something that doesn't get talked about enough: in the UK and EU, there are real legal implications to how you use inferred skills data.
If you're making hiring decisions based on skills that your system has inferred - rather than skills the candidate has actually claimed - you need to be careful. Under GDPR, that inferred data is still personal data. You need a lawful basis for processing it, and you need to be transparent about it. If a candidate asks "why was I rejected?", you can't just say "our algorithm inferred you lacked X skill" if that's not something they had the chance to dispute.
More importantly, if your inference algorithm is producing discriminatory patterns - even unintentionally - you've got a problem. Let's say your system infers leadership skills more readily from certain job titles or sectors that happen to be male-dominated. That inference is now creating adverse impact, and "the algorithm did it" isn't a defence.
Validation at least gives you an audit trail. You can point to an assessment result, a certification, or a structured interview scorecard. With pure inference, you're on shakier ground if you need to defend your decision-making process.
This doesn't mean you can't use inference - it means you need to understand it as a screening tool, not a decision-making tool. And you need to make sure candidates can see and challenge what's been inferred about them.
What actually works in practice
The organisations getting this right use inference to cast a wide net and validation to make confident decisions.
Here's what that looks like:
Use inference early in the process to identify potential. Let the system suggest candidates from non-obvious backgrounds, surface internal talent you didn't know you had, and build long-lists that are genuinely diverse. But be transparent about it - make sure people understand the system is making educated guesses.
Apply validation at decision points. Before you make an offer, before you move someone into a critical role, before you promote someone into people management - that's when you validate. Not with a full assessment battery for every skill, but with targeted validation of the capabilities that actually matter for success.
The validation doesn't have to be formal testing. Sometimes it's a practical work sample. Sometimes it's a structured conversation with clear criteria. Sometimes it's checking references specifically about certain skills. The point is that you've moved beyond inference to evidence.
And be honest about the trade-offs. If you're hiring for a role where the cost of a bad hire is very high - senior leadership, specialised technical roles, roles with compliance requirements - weight your process toward validation. If you're hiring at volume for roles with good training and support, you can rely more heavily on inference and bet on potential.
The vendor landscape is still sorting itself out
Not all platforms handle this well, and it's worth understanding where different tools sit on the spectrum.
Traditional ATS platforms have generally bolted on skills features as an afterthought. SmartRecruiters, for example, takes a practical approach to skills matching - it's designed to support everyday recruitment decisions rather than compete with specialist talent intelligence platforms, which for many organisations is exactly what's needed. iCIMS has added skills features to their Talent Cloud in recent years, again more focused on basic matching than deep inference. Pinpoint's skills capabilities are serviceable for SME recruitment but aren't going to compete with enterprise-grade talent intelligence.
The exception is Avature, which has quite sophisticated skills capabilities because of how deeply configurable the platform is - if you're willing to invest the time in configuration, you can build some genuinely nuanced skills logic.
Specialist talent intelligence platforms have built their entire proposition around inference. Eightfold AI is probably the most sophisticated player here - their whole model uses machine learning to predict skills from career trajectories, and it genuinely gets smarter over time. Beamery is strong on internal mobility and talent pooling, particularly good at inferring which internal candidates might be ready for different roles. LinkedIn Talent Insights obviously has the advantage of the entire LinkedIn graph for skills inference, though you're limited to what people choose to put on their profiles.
For organisations with Workday, the Skills Cloud is increasingly central to their strategy - it ties together recruiting, learning, and career progression with a common skills foundation. The inference capabilities are solid, though you're obviously locked into the Workday ecosystem. SAP SuccessFactors has similarly built skills capabilities across their HCM suite, with skills inference woven through recruiting, learning, and performance modules. Following SAP's acquisition of SmartRecruiters, there's potential for these capabilities to evolve further, particularly around recruitment-specific use cases.
Assessment platforms focus squarely on validation. Vervoe lets you build job-specific skills assessments with practical tasks. HackerRank and Codility dominate technical hiring with coding challenges. TestGorilla has built a broad library of skills tests across functions. Criteria Corp and Wonderlic focus more on cognitive ability alongside skills testing. The challenge with all of these is integrating them smoothly into your recruitment process - having validation happen at the right point, not too early to cause candidate drop-off, not too late to waste everyone's time.
Learning platforms are now positioning themselves in the skills space as well, which makes sense given they see skills development in action. Degreed and Cornerstone can infer skills based on learning activity and course completion. LinkedIn Learning ties directly into profile skills. The limitation is they only see skills development happening within their platform - they've got partial visibility at best.
Internal talent marketplaces - Gloat, Fuel50, and similar - are interesting because they sit between inference and validation. They infer skills to surface opportunities, but they also capture data on what people actually do in projects and assignments, which becomes a form of validation over time.
The reality is that most organisations need elements from multiple categories, which means integrations and data flowing between systems. When we're designing HR tech stacks, we're thinking about how skills data moves between recruitment, learning, performance, and succession planning - and whether the inference and validation is happening in the right places with the right tools.
What this means for your strategy
If you're implementing skills-based hiring, here's what you actually need to figure out:
Where do you need inference? Probably: sourcing, internal talent marketplace, succession planning, identifying skill gaps at an organisational level.
Where do you need validation? Probably: final hiring decisions, promotions, deployments to critical roles, anything with compliance or safety implications.
What's your taxonomy strategy? Are you using a vendor's out-of-the-box taxonomy, building your own, or using a standard like ESCO? How will that taxonomy support both inference and validation?
How will you handle the candidate/employee experience? How will you show people what's been inferred about them? When will you ask them to validate their skills? How will you avoid assessment fatigue?
What's your data governance approach? Who can see inferred vs validated skills? How long do you keep validation results? What's your process if someone disputes what's been inferred?
These aren't the sexy questions vendors want to discuss in sales demos, but they're the ones that determine whether your skills-based hiring initiative actually delivers value or just creates noise.
The bottom line
Skills inference and skills validation aren't competing approaches - they're complementary. Inference helps you find people and possibilities. Validation helps you make decisions with confidence.
The mistake is treating inference like it's validation, or insisting on validation when inference would do. Get clear on what problem you're trying to solve, understand what your technology is actually doing, and build a process that uses each approach where it makes sense.
And if a vendor tells you their system does "skills-based matching" without being able to explain how much is inference vs validation, and where the data is coming from, that's your sign to dig deeper. Because in implementation, these details matter enormously.
If you're working through these questions in your own organisation, we've helped dozens of companies implement skills-based hiring strategies across multiple platforms. The technical configuration is the easy part - it's the strategic decisions about where and how to use skills data that make the difference.
