AI TALENT & ENTERPRISE EXECUTION

The AI hiring paradox: when screening hides the talent

Stop screening for resemblance. Start looking for evidence of what candidates can actually do.

By Vijay Rengan, Founder & Chief AI Officer, EMLI

October 25, 2026

In the late 1990s, IBM faced a difficult hiring problem around AIX: finding people capable of working on the kernel, device drivers, and compilers—deep inside a complex operating system. Before founding my original company, EML Incorporated—now EMLI—I was a hands-on AIX kernel and graphics developer. An IBM manager once told me the organization needed fifty people like me to address its technical backlog. That conversation helped provide the impetus for the company.

Over two decades, I recruited and hired over 100 technical consultants for EML with hard-to-find skills in areas such as UNIX kernel internals and graphics subsystems—the kind of deep technical capability companies are seeking in AI today. Some became so productive and valuable to IBM that the company wanted to retain them as direct employees. Some of those professionals later moved into director and other senior-level positions at IBM. When IBM managers asked how I found such strong people, my answer was simple: I personally looked. I searched beyond the incoming applications and, because I understood the work, could recognize talent behind imperfect wording and formatting.

That experience is why today’s AI hiring problem feels familiar. Companies again need rare technical depth. But instead of helping technical leaders search more widely, many hiring systems place automated screening between the talent and the person capable of recognizing it.

A company can receive 500 applications for an AI role and still face a genuine AI talent shortage. The problem is not simply that deep expertise is scarce. AI has made competence easier to describe without making it equally easy to acquire—and hiring systems increasingly struggle to tell the difference.

This creates two shortages: scarce production-level expertise and weak methods for recognizing it. An employer may reduce hundreds of applications to a small set of highly matched résumés, find the interviews disappointing, and conclude that the market lacks talent. But it has evaluated only the candidates its process was designed to surface.

Don’t treat a tailored résumé as independent evidence

The résumé problem is already widely understood. Candidates can use AI to rewrite their experience in the language of a job description, after which employers use software to compare that optimized document with the same description. The loop—job description → AI-tailored résumé → automated matching—rewards textual resemblance without establishing capability.

The best-described candidates rise. The best builders may not. Distinguishing between them requires a keen technical eye—and the kind of domain expertise automated matching cannot replace. The more important question is no longer whether résumé-based hiring is broken, but what should replace it.

Don’t let AI decide who the hiring manager sees

Once the input signal is unreliable, reducing 500 applications to a top 20 does not repair it. The shortlist is not necessarily representative of the available candidates; it represents the people who scored best under the screening method. The hiring manager is therefore not choosing the strongest candidate from 500 people, only from the small group the process surfaced. If those interviews disappoint, the company may conclude that good AI talent is unavailable even though the strongest candidate may be among the 480 people no domain expert reviewed. The organization has not measured the talent market. It has measured the limitations of its discovery process.

AI can help search, organize, summarize, and surface evidence. It should not be the gatekeeper that makes the substantive first cut and determines which candidates a knowledgeable hiring manager is allowed to consider.

The same caution applies when a nontechnical recruiter conducts a scripted video interview and AI scores the transcript. The candidate may simplify an answer for the audience, while the recruiter may be unable to ask the follow-up that exposes shallow knowledge or recognizes a mature but unconventional decision. Transcript scoring may also confuse verbal fluency with technical ability and amplify transcription errors, language differences, or communication-style bias.

Don’t confuse application volume with talent supply

A stack of 500 applications can also create the illusion that the employer has abundant leverage and can secure serious talent at a budget price. But application volume measures interest, not the supply of people with the precise combination of technical depth, judgment, leadership, and recent production experience the company needs.

Even if a rare candidate accepts below-market compensation, the saving may not last. Strong practitioners continue to attract attention. If compensation, authority, learning opportunity, and recognition do not reflect their value, another employer may recruit them away—leaving the company with another search, delayed initiatives, lost context, and disrupted teams. Compensation should be part of a long-term talent strategy, not merely the lowest price at which a requisition can be closed.

Don’t turn interview rituals into evidence

Structured interviews, job-related questions, and work samples can improve consistency and are central to the approach proposed here. The problem is not structure; it is rigid scoring of superficial behavior unrelated to performance. One company showed me a guide that treated a candidate’s failure to ask a closing question as evidence of weak interest. I was surprised: the candidate may have researched thoroughly, had every question answered, been nervous, or preferred to reflect before asking something meaningful. Evaluate the substance of the interaction and evidence of preparation—not whether someone completed an expected ritual.

Don’t mistake credentials and titles for proof

Degrees, certificates, prestigious employers, and senior titles provide context, but they have limited resolution. In a postgraduate AI and machine learning program I attended, participants could choose coding or no-code paths. In my cohort, I observed that a large majority chose the no-code option, and many came from nontechnical backgrounds. Yet everyone ultimately received the same certificate. On a résumé, the credential did not reveal the substantial difference in the technical work performed.

A famous technology company on a résumé likewise does not prove recent hands-on AI experience, and titles such as Chief AI Architect and Head of AI are not standardized. These signals may help describe a career, but they do not establish what the candidate can build.

Generative AI can also produce sophisticated-looking code, diagrams, and architecture that conceal weak understanding. The gap appears when permissions fail, retrieval is poor, dependencies break, costs rise, or the system must operate at scale.

The useful question is not simply, “Where did you work?” It is: What exactly did you build, what did you personally decide, and what happened in production?

Start with a stable professional record

Many application workflows collect a newly tailored résumé and then ask administrative questions while asking almost nothing that helps a domain expert understand what the person has built. Reverse that design. Begin with an existing LinkedIn profile or another stable career record and a small number of evidence-producing questions. Collect most administrative information only from the smaller pool the employer intends to advance.

LinkedIn is not perfect: profiles are editable, self-reported, sometimes stale, and not maintained by every capable candidate. But it has one important advantage over a tailored résumé: it is a shared, persistent professional identity. A candidate cannot privately regenerate it for every application without repeatedly changing the same profile for every employer and professional contact to see. That makes it a more stable starting point, which can then be supplemented by job-specific evidence.

As profiles themselves increasingly feed automated matching, candidates may begin optimizing them too, and people with a thin digital footprint may remain difficult to discover. A LinkedIn profile is therefore not proof—only a less job-specific starting point. The hiring decision still needs to rest on evidence the candidate can explain and demonstrate.

The burden should return to the employer: understand what the person has accomplished and connect that history to what the organization needs accomplished.

Ask questions that create evidence

One thoughtful leadership application asked approximately twenty substantive questions about what I had done, what I had developed, how I led people, how I handled uncertainty, and where I was still developing. The questions took close to an hour to answer and produced a richer picture than keyword matching could provide.

After roughly a week, the posting showed only seventeen applicants while similar openings often displayed hundreds. That does not prove the questions caused the difference, but meaningful effort may have encouraged useful self-selection. Employers should reserve that burden for questions that genuinely inform selection and respect the time candidates invest.

For a technical AI position, employers can apply the same principle to capability: What have you personally built? What business problem did it solve? Which components did you design or implement yourself? What failed after deployment? What tradeoffs did you make? How did you evaluate the system? Where did you decide not to use AI? What measurable result followed?

AI could compare those answers with a candidate’s stable LinkedIn profile or career record—not to generate another unexplained score, but to identify supporting experience, chronology, missing context, and claims that deserve follow-up. An answer absent from LinkedIn should not become an automatic rejection; confidential projects, consulting work, and internal responsibilities may never appear publicly. The system should surface questions for a knowledgeable evaluator, not issue a verdict.

Candidates can use AI to polish these answers too. Written responses are therefore not proof. Their value is that they create specific, testable claims. A genuine builder’s account usually becomes richer when a domain expert probes the details. A polished account without underlying experience usually becomes thinner.

Let candidates demonstrate what they built

For senior AI roles, the critical instruction should be: Show me what you built.

Ask candidates whether they can demonstrate a product or system they personally helped build. A live demonstration can reveal more than another round of conceptual questions: the candidate must explain how the product works, navigate its actual behavior, and connect visible capabilities to underlying technical decisions.

A live demo is not always possible. Enterprise systems may be proprietary, confidential, or inaccessible after departure. Accept alternatives such as a sanitized architecture walkthrough, redacted artifacts, public code, an approved recording, a recreated prototype, or a detailed case study. In every case, ask the candidate to separate what they personally built from what they supervised, purchased, or inherited.

A candidate who has independently built a useful system for a real personal workflow—on their own hardware, with their own data and design decisions—is already well ahead in demonstrating hands-on capability. Such a project shows initiative, curiosity, end-to-end ownership, and a willingness to work through integration and operational problems without waiting for an employer to create the opportunity. It does not by itself prove experience with enterprise scale, security, governance, or organizational adoption, but it provides concrete evidence from which a knowledgeable interviewer can probe.

I know this firsthand from building E-QUERY. Developing an end-to-end AI product independently is difficult, expensive, and time-consuming. It requires far more than producing a model response: architecture, data preparation, retrieval, integration, infrastructure, testing, troubleshooting, usability, and cost decisions all have to work together. The process teaches lessons that are difficult to acquire through coursework or isolated prototypes.

Then use a realistic enterprise problem rather than AI trivia. Give the candidate a business process, data environment, constraint set, and consequence of failure. Ask:

A genuine builder usually becomes more convincing as the questions become deeper. The system comes alive in the details: tradeoffs, mistakes, constraints, measurements, and the reasons one design was chosen over another. A vocabulary-level candidate becomes less convincing.

Let the hiring manager drive—and use AI to expand their reach

Wherever practical, the hiring manager should actively search the pool and own the first substantive selection. That was the model I used at EMLI: I searched the available candidates myself, selected roughly ten people whose histories showed relevant depth, and then passed that group to an administrative person for contact, coordination, and follow-up.

The division of work matters. The person who understands the problem decides whose experience deserves investigation. Recruiting then manages sourcing support, candidate communication, scheduling, administrative requirements, and the process that moves qualified people forward. For larger applicant volumes, other domain experts can share the review rather than transferring the judgment entirely to a general recruiter or ranking system.

Expert-led review should not mean unstructured or unchecked review. Hiring managers bring their own affinity bias and blind spots. Use consistent job-related criteria, document the evidence behind decisions, involve more than one qualified reviewer where practical, and monitor outcomes for unjustified exclusion. Keeping a human in the loop does not remove the employer’s fairness or compliance obligations.

AI can make that model scalable. It can help the hiring manager explore a larger pool, prepare questions, organize evidence, suggest follow-ups, compare claims with the career record, and document what still needs verification. It should extend the expert’s reach, not substitute for an expert who never entered the conversation.

A discovery-oriented system could help a qualified hiring manager explore hundreds of candidates without reducing each person to a single match score. It could summarize stable career histories, identify evidence relevant to the business problem, surface adjacent experience, group candidates by capability type, flag uncertainty, and deliberately retrieve candidates whose backgrounds differ from the dominant pattern.

It could answer questions such as:

• Who has built reusable platforms adopted by multiple teams, even if their title was not “AI Architect”?
• Who has recent production experience with retrieval evaluation and access control?
• Who has combined data architecture, distributed systems, and business transformation?
• Which candidates have demonstrated judgment by choosing a simpler non-AI solution?
• Which relevant candidates would be missed by the exact vocabulary in this requisition?

The output should preserve evidence and uncertainty. It should let the domain expert inspect why someone was surfaced and search beyond the first page. It should not make an unexplained claim that candidate A is a 94 percent match while candidate B is an 81 percent match and therefore disposable.

Administrative gates should be transparent. If location, sponsorship, compensation, or travel caused exclusion, tell the candidate. If a substantive qualification caused the decision, identify it. Give candidates a way to correct erroneous data. Employers should monitor whether their selection procedures disproportionately exclude protected groups and ensure that assessments are meaningfully related to the work.

Make talent discovery the objective

When I interviewed candidates, I did not begin with “Tell me about yourself.” The candidate had already provided a résumé, and I had already invested the time to read it. If I scheduled the conversation, it was because I saw relevant credentials and believed the person might fit the role.

I began by telling the candidate that I was impressed by the résumé they had presented and that I saw a potential fit. I then asked three questions: What interested you about this role? What do you understand the role to be? How do you believe you can help us? The answers showed whether the candidate had studied the opportunity, understood what the company needed, and could connect those needs to their own capabilities. The interview began with mutual preparation rather than résumé repetition.

That is the broader hiring model this article proposes. The employer should do the work of understanding the candidate before the interview. The candidate should arrive prepared to explain the opportunity as they understand it and provide evidence of how they can contribute. The hiring manager should bring enough domain knowledge to evaluate the answer. AI should help all three parties reach that substantive conversation more efficiently.

I found exceptional technical talent because I personally looked and understood what I was looking for. AI should make that kind of expert-led discovery possible at greater scale. It should not remove the expert from the search.

Additional context: LinkedIn’s description of AI hiring agents and U.S. Equal Employment Opportunity Commission guidance on employment tests and selection procedures.