How Do You Verify 'AI-Proficient' on a Resume?

Why can't you verify AI proficiency from the resume?

Because nothing on the page is evidence. "AI-proficient," a prompt-engineering certificate, a portfolio of unusually clean work: all of it is self-reported, and the same tools that produced the work will happily write the claim about it. Detection doesn't rescue this, either: what a detector answers is whether a model touched the text, which is not the question you asked.

That distinction carries the whole problem. Detection asks whether an artifact was AI-written; verification asks whether this person does good work with AI in the room. Only the second is a hiring signal, and only the second survives a challenge. The first puts you in the position of making an employment decision on a probabilistic guess about authorship.

The useful part is that verification is an old problem with a settled answer. You already verify claimed skills you can't take on faith, by asking the candidate to do a piece of the job. Nothing about AI changes that mechanic. What changes is which part of the work you have to watch, because the finished deliverable is no longer the part that separates people.

What does 'AI-proficient' mean for this role?

It means something different in every job, which is why a single screening question is either unfair or uninformative. For a software developer, the observable behavior is testing generated code against something the model didn't write (a test suite, a linter, a staging run). For a financial analyst, it's demanding the source behind the number that moves the recommendation, and then opening it. Same habit, different act.

The occupational task lists make this concrete. The O\*NET summary for Software Developers (SOC 15-1252.00) carries 17 tasks, among them developing or directing software system testing or validation procedures ⁴. The summary for Financial and Investment Analysts (SOC 13-2051.00) carries 26 different ones, built around advising clients on capitalization, assessing companies as investments, and recommending remedies for firms in difficulty ⁵. A verification question written for one of those roles tells you close to nothing about the other.

So do the small piece of thinking first. Name the two or three moments in this specific role where a confident AI answer could be wrong in a way that costs money, credibility or a customer. Those moments are the verification target, and they are also the only defensible basis for setting a proficiency bar at all.

Design one task that makes the claim testable

Hand over a short piece of the actual job, an assistant they may use however they like, and a deliverable with a real constraint attached. Forty to sixty minutes is enough. The task must contain at least one thing a model will get confidently wrong (a stale figure, a plausible claim with no source, a library function that doesn't exist), because that is the moment proficiency becomes visible.

Three properties do the work:

• It comes from the role. The Uniform Guidelines on Employee Selection Procedures are explicit that a content-validity case starts with a job analysis of the important work behaviors, and that "the closer the content and the context of the selection procedure are to work samples or work behaviors, the stronger is the basis for showing content validity" ².
• AI use is permitted, in writing. A task that quietly bans the assistant measures compliance and tests something you will never observe again after the hire. Say the tool is allowed, and say the transcript is part of the submission.
• The trap is real, not cruel. A wrong figure planted in the source packet is fair. A task nobody can finish in the time given tests stamina.

One caveat the same guidelines put in writing: content validity is not an appropriate strategy for a knowledge, skill or ability an employee is expected to learn on the job ². If your team teaches the tooling in week one, verify judgment rather than tool familiarity, and don't gate on the tool at all.

Read the working record, not the finished deliverable

Two candidates can hand back the same document, and everything that separates them sits upstream of it. Ask for the assistant transcript alongside the deliverable, or watch the session live, and read for six acts: what was framed before anything was generated, what evidence was demanded, what was kept by hand, what existed between the brief and the answer, what was refused, and what was tested against something outside the conversation.

Each one either happened or it didn't, which is what makes them gradeable:

• Framing. Did the first move go after understanding the problem, or straight at the deliverable?
• Evidence. Was a source demanded for a specific claim and actually opened, or was "cite your sources" typed once and forgotten?
• Delegation. What did the candidate keep? A check run by hand, or a judgment made without asking, is worth more than volume of prompting.
• Structure. Was there anything the deliverable can be read against: a plan, a criteria list, an outline?
• Refusal. Was any model output rejected on stated grounds, or was all of it accepted with the edges tidied?
• Verification. Was a claim tested outside the chat, and did the result change a number, a recommendation, or a stated limit?

How much AI got used is not on that list. A candidate who decided the model was the wrong instrument for a step and did it by hand has shown you the thing you were trying to see. Write the standard down as a rubric before the first session runs, or the first impressive deliverable will set it retroactively, which is one route to the candidate who aces the loop and struggles in the first quarter.

Keep the check job-related and the decision human

A verification task is an employment test, and it gets treated as one. Under Title VII, a selection procedure that screens people out has to be job-related and consistent with business necessity, and the EEOC lists work samples and simulations among the procedures that standard reaches ¹. That case is straightforward to make about a task drawn from the role's own work. It is very hard to make about a detector's confidence figure.

Two practical consequences. First, keep a person in the decision. Where a tool substantially assists or replaces the screening call, jurisdictions have started attaching obligations to it: New York City's rules under Local Law 144, adopted by the Department of Consumer and Worker Protection and effective July 5, 2023, require a bias audit and candidate notice before an automated employment decision tool is used ³. A human reading a work sample does not put you there.

Second, keep the records. Write the task, the standard and the job analysis down before any candidate sees them, and keep what each candidate produced. When someone later asks why one applicant advanced, "here is the task, here is the standard, here is what they did" is an answer. Knowing what you may lawfully ask about a candidate's AI use is the same discipline one step earlier. None of this is legal advice, and the thresholds move by jurisdiction, so run the final design past counsel.

See a sample report >