Most interviews are a waste of time — here's how to fix that

Most hiring teams have a process that goes: CV screen, phone call, interview, offer. The interview sits at the centre of it all, carrying most of the weight. It is also, statistically, one of the weakest links in the chain.

The evidence has been clear for decades: interviews are poor predictors of job performance. They are slow, expensive, and heavily influenced by factors that have little to do with how well someone will actually do the role. Yet they remain the default because they feel thorough.

This page is for hiring teams who want to understand where they are losing time and quality — and what to do instead.

Why interviews waste your time

The core problem is that interviews are typically used as a screening tool, and they are a bad one. A structured interview — the most rigorously designed version — has a predictive validity of around 0.38 according to Schmidt and Hunter's widely cited 1998 meta-analysis of 85 years of selection research. Unstructured interviews sit lower still, around 0.20. By comparison, cognitive ability tests reach 0.51, and work sample tests reach 0.54.

Validity aside, interviews simply do not scale. If 200 candidates apply for a role and you interview 30 of them for an hour each, that is 30 hours of hiring manager time before you have made a single decision. If three interviewers attend each session, that becomes 90 hours — for one hire. Multiply that across a year of hiring and the cost becomes very large very fast.

The harder truth is that many of those conversations were unnecessary. Most candidates who make it to interview but ultimately fail could have been identified earlier, at the screening stage, if the right tools had been in place.

What goes wrong in the interview room

When the interview is the first serious filter, the process inherits all the biases that come with it. Research consistently shows that interviewers form strong impressions within the first few minutes, often before substantive questioning has even started. The rest of the conversation tends to confirm that early judgement rather than test it.

This rewards presentation, confidence, and social fluency. These are useful traits in some roles, but not most. Candidates who are naturally polished, articulate, and comfortable performing under social pressure consistently outperform quieter but more capable candidates — regardless of what the role actually requires. Hiring teams often mistake interview skills for job skills, and the two are not the same thing.

Decisions based on gut feel and first impressions also introduce demographic bias. Studies show that candidates are assessed differently based on characteristics unrelated to role performance, and that these effects are amplified in unstructured interview settings. The interview, by its nature, creates conditions where bias is hardest to control.

Interview performance is not job performance

Performing well in an interview is a skill in its own right. It requires the ability to structure answers on the spot, manage nerves, read the interviewer, and deliver practised responses naturally. These are not the skills of a good analyst, a capable engineer, or a strong project manager. They are the skills of someone who interviews well.

This is the central problem with interview-first hiring. Interview performance and job performance correlate weakly, particularly in roles where the work is technical, analytical, or structured. The candidate who gave the most fluent answers in the room is not necessarily the one who will make the best decisions once they are in the post.

Test ability before you interview

The fix is not to remove interviews from the process. It is to move them later, after you already know something meaningful about the candidate. Ability tests belong at the screening stage because that is where they have the most impact.

A numerical reasoning or verbal reasoning test, sent to the full applicant pool, identifies the candidates most likely to perform well in cognitively demanding work. It takes around 20 minutes per candidate, produces an objective score, and requires no hiring manager time whatsoever. Used at the start of the funnel, it reduces 200 applicants to a shortlist of 30 — not arbitrarily, but on the basis of the trait most strongly linked to job performance.

Every interview you conduct from that point is with a candidate who has already demonstrated they can think analytically. You are no longer trying to detect ability in conversation. You have measured it. That changes the quality of every interview that follows.

For early careers and graduate hiring this matters even more. These candidates have limited work histories, so CVs and experience are poor signals. Ability tests measure what they are actually capable of, rather than where they happened to work before.

Make interviews confirmatory, not exploratory

Once ability testing sits at the front of the process, the interview's job changes. Instead of trying to work out whether a candidate can do the role, you are confirming what you already have evidence for — and adding things the test cannot give you: how they communicate, how they handle specific scenarios, whether they are a good fit for the team and culture.

Structured interviews work best here. A consistent set of job-relevant questions, scored against a defined framework, reduces the influence of bias and creates a defensible record of the decision. Paired with objective test data, they complete a picture that neither assessment alone can provide.

This is how interview time becomes high-value rather than high-volume. Fewer conversations, with better candidates, about things the test has not already answered.

Why ability tests outperform interviews

The research on this is clear. See how ability testing changes what you can know about a candidate — and how quickly you can know it.

Read the guide Explore aptitude tests

Primary author

Ben Schwencke

Chief psychologist at Test Partnership. MSc in Organisational Psychology with over ten years of experience in psychometric testing.

Contributed to by:

• 

Ben Hopgood