Skills-based hiring is sold on a promise about what happens after the offer. Assess what the job actually needs, the argument goes, and you widen the pool and the people you pick can do the work. That promise is why teams drop degree requirements. It’s also the part no hiring process can check.

The reason is structural, and a better rubric won’t fix it. A hiring loop only ever sees the people it hired. It never sees how the candidates it turned down would have done, so it can’t show the bar was set in the right place, or that a skills-based loop produced better hires than the one it replaced.

So this guide argues for a smaller question, one you can answer. Did the loop collect comparable, job-relevant evidence on the skills you said mattered, and was that evidence still there when someone made the call? Clearing that bar doesn’t prove you hired well, but it’s the condition that has to hold before the question is even worth asking, and most loops don’t clear it.

AI has a narrow place in that. It can capture the conversation and keep the record straight. It can’t decide what counts as the skill, and it won’t tell you whether your rubric measures anything that matters.

The claim you cannot check from inside the loop

The case for skills-based hiring has two halves. Drop the proxies and you see candidates the resume filter would have skipped. Assess the work itself and the people you choose can do it. Both halves are statements about the future, and both get settled long after the last interview ends.

The evidence usually cited for the second half is external and academic: decades of published work on selection methods, comparing structured interviews and work samples against unstructured conversation. That literature belongs to the field, it studies methods across many employers, and Metaview didn’t run it. Metaview’s own data covers interview conversations and the scorecards attached to them, and it stops at the offer.

Your own company’s numbers can’t settle it either, and this is the part that gets skipped. You collect ratings for the people you hired. You have nothing at all for the ones you turned down, because there was nothing for them to be rated on. A tidy relationship between interview scores and later ratings, drawn only from people who cleared the bar, describes how the bar behaved among people who cleared it. That’s a different question from whether the bar was in the right place, and it says nothing about how many good candidates the bar removed.

None of that makes pedigree worthless. A degree and a well-known employer are real facts about where someone has been and what they were exposed to. What they’re missing is anything specific to this role, on this team, this year. They’re also fast to read, which is why they win when the calendar is full: in Metaview’s 2026 AI & Hiring Alignment Report, 67% of teams say they lose qualified candidates every month to competitors who move faster.¹ Under that clock, the resume is the shortcut that’s always available.

The shortcut cuts both ways. It screens out people who built the skill somewhere unfamiliar, and it flatters candidates whose background reads stronger than the examples they give once you ask. The five steps below are aimed at the second problem, because that’s the one an interview can fix.

Step 1: define each skill as observable behavior

Start with the work, and skip the label. “Strong communicator” can mean almost anything. A definition earns its place when it says what the person would do, what choices they’d make, and what a good example would contain.

The well-known test: could two interviewers hear the same answer and agree on whether the behavior appeared? If they couldn’t, the definition isn’t finished.

Run that test, but know it settles less than people think. Agreement means the definition is readable. It says nothing about whether the behavior belongs in the job. Two interviewers can score the same rehearsed answer identically all week and still be measuring something the role never asks for.

So run a second test, and run it with the hiring manager. Name a piece of real work from the last quarter where this behavior decided how it went. If nobody can name one, the skill is on the list because it sounds like a skill, and it’ll eat an interview slot anyway.

That conversation has to happen with someone who won’t be in every interview, and it isn’t always comfortable. In the same report, 58% of recruiting leaders and hiring managers say they sometimes or often wish they could work around their counterpart.¹ The survey didn’t ask why. What it does tell you is that a definition agreed in a room and never written down has a short life.

How many skills? One interviewer can only gather usable evidence on so many in an hour, and that’s the real constraint. Across 331,872 captured sessions, a single interview touches a median of 18 distinct competency topics, measured by topic detection rather than by a loaded guide.² That’s what a loop does when nobody has decided: it covers everything lightly. Give each named skill a slot instead, and if the list needs more slots than the loop has, the list is too long. For most roles that lands around four to six.

Step 2: give every skill one owner and one stage

Match the format to what you need to see. A structured behavioral question gets you there when the skill shows up in how someone handled a situation. A work sample is the more direct test when the skill is the doing of the task, since you’re watching the work happen instead of hearing about it. And if the skill only appears between people, you need a live exercise. Structured interviews and work samples are the two formats with the longest record in the external selection literature, which is research about methods across employers and is separate from anything Metaview measures.

Then give every skill one owner and one stage. It can come up anywhere, but one named interviewer is responsible for coming back with enough to score it. That’s what stops four people asking their own version of the culture question while the skill the role turns on goes untouched.

One owner buys coverage and costs you a second opinion, so spend the extra slot where it counts. If a skill is the one the whole role rests on, look at it twice in two different formats rather than twice in the same conversation.

Keep the exercise close to the real work and in proportion to the decision. A candidate should be able to show the skill without giving up a weekend.

Step 3: ask for the example, then dig into it

A broad question gets a broad answer. “Tell me about your experience with enterprise customers” invites a summary. “Walk me through the last enterprise deal that nearly fell apart” gives you something with edges on it.

The evidence lives in the follow-ups, for a plain reason: the first answer is the one the candidate has given before. Ask what they personally owned, what the trade-off was, what they chose, what happened next, and what they’d do differently now. A rehearsed story survives the first question and rarely survives the fourth.

This has to be planned or it doesn’t happen. In a corpus of roughly 5.8 million logged interview questions, 22.5% are behavioral, or 1,310,366 of them.² Most of what gets asked in an interview is something else entirely, and none of it is the evidence you’re meant to be scoring.

New skills get the same test. At Qonto, AI use is part of how the work gets done every day, so the recruiting team asks about it directly. That question passes the check from step one: someone there can point at the work it decides.

Copying their question would be a mistake. Their reasoning transfers, though. They spotted a behavior that changes how the work goes in their own environment, then went and asked about it.

Step 4: anchor the rubric and read agreement carefully

A rubric earns its place when the levels describe behavior instead of quality labels. For stakeholder management, the bottom level might be a candidate who can’t produce a specific example, the middle a clear example with thin ownership. The top: direct ownership, a trade-off they can explain, and a result they describe honestly, including the part that went badly.

Calibrate before anyone meets a candidate. Two interviewers score the same sample answer and say why. Every disagreement you settle there is one you won’t be having in a debrief with a real offer on the table.

Then be careful about what agreement is telling you. Several people scoring the same candidate land on a split verdict 15.0% of the time, across 72,753 panels.² Unanimity is the normal outcome. Read one way, that’s a bar everyone understands. Read another, it’s exactly what you’d see if everyone were reading the same resume and reaching the same conclusion for the same unexamined reason. The data can’t separate those two readings, and neither can a debrief where whoever speaks first sets the tone. The question worth asking in the room is whether each interviewer can point at the moment they’re scoring.

Metaview sits underneath that, one layer down from the judgment. Metaview’s Notetaker joins with consent, records the conversation, and turns it into structured notes. Each note section links back to the transcript moment it came from, so a claim about who owned what is checkable later instead of remembered. On Ashby and Greenhouse, the browser extension autofills the objective sections of the scorecard and leaves the subjective fields blank. The interviewer reads the evidence, applies the rubric, and submits the scorecard.

That’s record keeping, all of it. Metaview doesn’t score the candidate and doesn’t decide who advances, and none of it tells you whether the rubric measures anything worth measuring.

Step 5: check the record rather than the outcome

The usual version of this step says to correlate interview scores with performance later and act on what you find. Two things make that harder than it sounds.

First, the outcome side has to come from you. Metaview’s corpus covers what happened inside the process: conversations, questions, scorecards, decisions to advance. It contains no performance reviews, no retention, and no tenure. Metaview Reports will query your own interview data, and the outcome measure has to come from somewhere else in your company.

The second one never makes it into the deck. Even with clean HR records, you only observe the people you hired. The candidates you passed on have no ratings at all, so any pattern you find describes the survivors of your own bar and nothing else.

You can see the shape of that mistake in someone else’s numbers. The 2026 AI & Hiring Alignment Report found that 85% of companies that exceeded their hiring goals use AI in hiring.¹ The base there is companies already exceeding their goals, and the survey didn’t measure what the companies that missed their goals were doing. Read carelessly, it sounds like a finding about AI. Read properly, it’s a description of one group with no comparison group attached. Your own score-to-rating analysis will have the same hole in it.

So run the check you can run, and be honest about its size. It asks whether the loop did what you designed it to do, and it can’t tell you whether the design was right. Three questions cover it. Was every named skill assessed? Is the evidence specific enough that someone who wasn’t in the room can see what it was? And did the record survive to the point where the decision got made?

The third question is where most processes come apart, and it has nothing to do with intent. Across a corpus of 5.2 million candidate interviews, 31.2% have at least one scorecard attached. Among candidates who advanced to a later round, 41.9% did so with no submitted scorecard at all, across 296,555 advances.² Those are two separate measures on two different denominators, and both describe the industry’s normal state. Nobody abandons a skills-based process in a meeting. It empties out one unwritten scorecard at a time.

Metaview moves the number in exactly one place on that list. Submission runs at 50.3% when Metaview generates the scorecard as a first draft, against 28.6% for manual scorecards, on capped samples of 93,502 and 26,498.² That’s a 1.76x difference in whether the evidence gets written down at all. It says nothing about whether the evidence was any good, and it shouldn’t be sold as though it does.

Screening for skills before the interview

The same problem starts earlier. The fields that are fast to scan win by default when a role pulls hundreds of applications, and those fields are the company names, the degrees, and the titles.

Metaview Application Review drafts an Ideal Candidate Profile from the job description and any context you add. You review and edit that profile before anything runs against it. Application Review then evaluates each application against those criteria and shows the reasoning behind each call, sorted into ICP Fit buckets rather than a numerical score. The recruiter decides who moves forward, and Metaview never auto-rejects.

One limit is worth naming. The profile is built from your job description, so if the job description is written in proxies, the criteria will be too, and every application then gets judged consistently against the wrong thing. Consistent isn’t the same thing as correct. Write the skills into the profile in the same observable terms you used for the rubric, and read the reasoning behind the bucket, because the bucket can only be as good as the criteria you approved.

Across the whole process the discipline is the same. Decide what counts as evidence before you look at anyone, give each skill somewhere to be collected, and keep what you heard. None of that proves you made better hires. It shows whether you ran the process you said you were running, and until you can say that much, the rest of the argument was never available to you.

¹ Survey data from Metaview’s 2026 AI & Hiring Alignment Report: 505 recruiting leaders and hiring managers at companies with 200 or more employees across North America and EMEA.

² Metaview aggregate interview data, a corpus of roughly 5.5 million captured conversations. Scorecard coverage is measured across 5,207,185 candidate interviews. The competency-topic and question-type figures are topic-detection proxies. The scorecard submission comparison rests on capped query samples and isn’t a full population.