How to Vet IT Talent in the AI Era

A resume tells you what someone has done, and the interview has to show whether that experience holds up. AI has made that much harder to judge.

In a 2025 survey of 3,000 U.S. managers, more than half said AI has made it harder to trust what they see and hear during virtual interviews, and when a hire who interviewed well can't do the work, it costs more than investing in the right person the first time.

For remote teams, the usual response is to police the candidate's environment with camera checks and workspace rules. But that puts the attention on the room instead of the skills, and it treats honest candidates as suspects. A stronger process tests the skills directly and lets candidates show what they know without the surveillance.

Why Traditional Technical Interviews Miss AI-Era Skills

Most technical interview formats were designed for a time when producing the work was the hard part. Now an AI assistant can do much of that work, which makes how they answer even more important than what they answer.

Correct Answers Reveal Less on Their Own

A correct answer no longer tells you who arrived at it. The candidate may have reasoned through the problem, used an assistant along the way, or read out an answer generated while you were still asking the question.

Some tools are built specifically for this. Interview Coder, now sold as Cluely, listens to the call and puts answers on the candidate's screen in a hidden browser window the interviewer can't see. Its creator used it to pass Amazon's technical interview before the tool raised venture funding, because if it can fool Amazon, it can fool most companies.

Take-Home Assessments Hide the Process

Take-home coding tests are useful because they test the skills a candidate will actually use, at a realistic scope and without someone watching. Their weakness is that the finished submission hides how it was produced, and a coding assistant can produce one in the time it takes to paste the prompt.

Even Anthropic couldn't keep its own take-home ahead of its models. By May 2025, more than half of applicants scored higher by handing the task to Claude Code than by completing it themselves. Your team is writing take-homes against these same tools, with less insight into what they can do.

Static Questions Are Easier To Prepare For

A question your team has asked for three years is probably on every prep site. AI makes those familiar questions even easier to prepare for, whether the candidate has seen the exact question before or not.

In an interviewing.io experiment, those using ChatGPT passed 73% of interviews built around verbatim LeetCode questions, compared with 25% for fully custom questions. Minor changes barely reduced the advantage, since the passing percentage was 67%.

Static questions still work as a five-minute warm-up that settles nerves and confirms basic vocabulary. Scoring them tells you nothing.

Traditional Interviews Can Create False Positives and False Negatives

Technical interviews have always produced false negatives. Capable engineers can get rejected because the format rewards memorized algorithms, syntax, and puzzle-style questions they haven't touched since school, and being watched makes it worse.

When researchers at North Carolina State University and Microsoft had students solve a whiteboard problem with an interviewer in the room, the students performed less than half as well as peers solving the same problem in private.

AI adds false positives, too. You hire someone who looked perfect in the interview, and once they're in your repo, it's clear they're out of their depth. By the time you notice their mistakes, you've lost weeks you could have spent getting your next release out.

How To Vet IT Talent in the AI Era: 8 Practices That Reveal Real Ability

Every practice below tests how a candidate would do the actual work, in ways an assistant can't keep up with, and all of them run over video without watching anyone's hands or screen.

For the process around them, including how long it should take and who belongs in it, see Strider's webinar on designing a technical interview.

1. Set Rules for AI Use

Decide at each stage whether AI is allowed, and inform everyone before it starts. Otherwise, people enter the same interview with different assumptions about what they can use.

• AI-restricted stages: Candidates work without AI tools. Use these stages to test foundational knowledge the engineer has to hold independently, like tracing what happens between a user clicking a link and the page loading, or explaining why a query gets slow as a table grows.
• AI-enabled stages: The candidate uses their usual AI assistant on screen, as they would on the job. Use these stages to assess how they frame a problem, direct the tool, evaluate its suggestions, and make technical decisions around its output within your engineering environment.

Canva took this approach in 2025, replacing its computer-science fundamentals round with an AI-assisted coding interview. Candidates used tools such as Copilot, Cursor, or Claude on an ambiguous build task, and the ones who struggled were those who couldn't steer the tool or recognize a weak suggestion.

When AI is allowed, the final code tells you the least. Score how the candidate clarifies requirements, decides what to ask the tool, tests its output, catches mistakes, and defends the decisions behind the final implementation.

2. Test Fundamentals Through Explanation, Not Memorization

Syntax, definitions, and standard technical answers are cheap for an assistant to produce. Test the fundamentals an engineer has to apply during real work instead, such as caching or concurrency depending on the role, by putting a piece of code in front of the candidate and asking them to explain it.

Walking through the reasoning tells you more than the code does. Strider's senior technical interviewers probe past a candidate's first answer for exactly this, because the second and third follow-ups are usually where understanding and recall separate.

3. Use Follow-Up Questions That Change the Problem

A candidate can prepare for the problem you put in front of them. They can't prepare as easily for the constraints you introduce after their answer, and an assistant that has to be re-prompted for every change falls a step behind each time. Change one condition at a time and make the candidate reconsider the solution they just proposed.

Useful follow-ups include

• What changes if the data no longer fits in memory?
• What happens when the request volume increases tenfold?
• What would you change if this had to be delivered in two days?
• Which assumption in your current approach would worry you most?
• What would you test before putting this into production?

For example, ask for a structure with constant-time insert, delete, and lookup, then ask for the minimum element in constant time as well. A candidate who understood the first answer starts trading off immediately, while one reading from an assistant returns a polished answer to the textbook question.

Then listen to how they respond to the change. A clarifying question or some thinking aloud shows they've registered it, while a confident answer that ignores the new requirement shows they haven't adapted the solution. Keep the changes grounded in situations your team actually faces, too, so the candidate is reasoning about real work.

4. Ask Candidates To Critique and Debug, Not Only Create

AI assistants are good at producing plausible code. Judging why code is wrong is a different skill, and your team will need it more as more of the codebase is machine-drafted.

Give candidates imperfect work and ask them to find the problems. A pull request works especially well when the defects vary in type and severity.

Seed it with three defects at different depths, like a query built through string concatenation, a missing authorization check on one endpoint, and a race condition that appears only under load. Ask the candidate to identify each problem and explain what it would break. Then have them decide which issue needs attention first and describe the fix.

Finding a defect is the easy part. A strong candidate explains why a missing authorization check creates a security risk and why one issue needs attention before another, and gives style nits less weight than defects that affect security, correctness, or reliability. Pitch the defects at what a strong engineer would catch in a normal code review, hard enough to need careful reading and never an obscure puzzle.

5. Test Engineering Judgment With Problems That Don't Have One Right Answer

The decisions your team argues about have no canonical answer for an assistant to retrieve, like build versus buy, ship now versus refactor first, or a choice between two architectures that both work. Because the right call depends on the constraints, these problems show how a candidate weighs competing priorities.

Say you give a four-person payments team the choice between building and buying a reconciliation service. Listen for what the candidate asks before answering, about volume, about who would own the vendor relationship, about what happens when the vendor's schema changes.

No one has to reach the same decision as your team. However, a strong applicant should identify the factors driving the decision, weigh the trade-offs, and commit to a recommendation, while being ready to adjust when conditions change.

6. Go Deep on Something the Candidate Has Actually Built

You can tell which projects a candidate worked on by looking at a resume, but not how much of the work they owned. Pick one project they handled and get specific. Start with their role, then follow the project from the original problem through the technical decisions, implementation, and post-launch outcomes.

The reasoning behind a real project is the one thing an assistant can't supply, because it wasn't there when the decisions were made.

For example, if the candidate chose the data model, ask what alternatives they considered and why they rejected them. Similarly, when discussing a production incident, ask what caused it, how the team responded, and what changed afterward.

Ashby runs the project deep dive twice during its engineering interview process. The first takes 10 to 20 minutes with an engineering leader, while the final round spends 30 to 45 minutes going deeper with senior engineering leaders. Interviewers let candidates lead the discussion, interrupting to explore decisions, technical details, challenges, or anything that needs clarification.

These details also help separate personal ownership from team involvement. Someone who led the work should know which decisions they made, which ones belonged to others, and why the team changed course when the original approach stopped working.

7. Evaluate Communication and Consistency Throughout the Interview

A technical interview is a conversation about how someone approaches technical work. Communication is part of what you're testing in every stage, and a soft-skills round bolted on at the end misses it.

Across the interview, watch for:

• Consistency: Their reasoning sounds the same when you come back to a decision later or ask about it a different way.
• Depth when questions get specific: An assisted candidate is often fluent on prepared material and vague once you ask about the details.
• Honest uncertainty: A candidate who says they're not sure and reasons toward an answer is more credible than one whose confident answer doesn't fit the question.
• Written versus spoken: Someone articulate in a take-home write-up but halting when they explain it live is worth probing.

The point is to keep testing the reasoning behind their first answer as the conversation develops.

Score communication for clarity and technical substance. Accent, speaking speed, personality, and polished delivery don't belong in the assessment, and that matters more when you hire across countries, where presentation style varies widely.

Strider's first-round interview with a recruiter evaluates the same things, whether the candidate can hold a conversation past the resume and follow their own reasoning, before anyone reaches the technical stage.

8. Have Experienced Engineers Conduct the Technical Evaluation

A technical rubric has limits. It tells interviewers what a good answer might contain, but it cannot judge an answer that takes an unexpected path. That requires someone who understands the underlying engineering problem.

Take eventual consistency. A candidate might recommend it for a system where the trade-off makes sense. An experienced engineer can explore why, ask what risks the choice introduces, and see how the candidate would respond if the requirements changed. The conversation tests the reasoning behind the decision instead of checking for specific terminology on a scorecard.

Strider's technical vetting puts senior engineers in that role. The interviewers use AI in their own work and learned to build software before generative AI became commonplace, so they know what unassisted reasoning and debugging look like and can tell the difference in a live conversation. They then share the assessment with you, including the areas that deserve further probing.

AI Fluency vs. AI Dependence: How To Tell the Difference

The same AI tool produces very different results in different hands. An experienced engineer might use it to explore an approach, then scrutinize the output before accepting it. Someone with weaker technical judgment might follow the same suggestions without questioning the assumptions behind them.

The table below gives hiring teams a set of behaviors to look for when assessing AI use.

Ask how AI has changed the way the candidate works, then ask what they won't put into it. The second answer separates fluency from dependence, since a fluent engineer has limits and a reason behind each one.

Someone who never reaches for it at all has a different problem, and underusing AI carries its own cost.

What To Do When You Suspect Undisclosed AI Use

Don't try to catch anyone. Test the competency again. You can't prove from one interview that a candidate had help, and accusing someone who did the work themselves costs you a candidate you might have hired. Having them show the same skill a second time answers the question either way.

If something feels off, work down this list in the same interview or the next one:

1. Ask for more detail: Have the candidate explain a specific decision in their solution, including what alternatives they considered and why they chose their approach.
2. Change the requirements: Introduce a new condition that changes the trade-offs in the original problem. See how the candidate rethinks the approach.
3. Ask for a code or design change: Give the candidate a specific modification and have them explain how they would make it.
4. Debug the solution together: Add a bug to the proposed solution and work through the failure with the candidate.
5. Test the same skill differently: If a take-home demonstrates strong knowledge of caching, discuss a problem live without the original implementation.
6. Get a second technical opinion: Have another interviewer review the response and follow-up independently.
7. Record inconsistencies: Write down the original answer, the follow-up, and what changed so the next interviewer has something concrete to investigate.

None of these steps accuses anyone, and an honest candidate goes through them as a thorough interview.

They take the candidate through a project they shipped, raise anything that doesn't add up, and stop recommending a candidate they can't vouch for.

For the warning signs that have nothing to do with AI, Strider's checklist of red flags when interviewing developers covers the rest.

A Practical Scorecard for AI-Era Technical Interviews

After testing technical ability, interviewers can use a shared scorecard to record what they observed across the interviews. It works best as part of a structured process for vetting and hiring technical talent.

Use the four-point scale consistently, and require a written reason for every score. During the debrief, discuss the evidence behind each score before discussing the overall assessment.

Strider: Built for Companies That Want Deeper IT Talent Vetting

The practices above require senior engineering time, which is often the hardest resource to pull into hiring. Strider, the LATAM developer hiring platform, built its vetting process around that constraint and now applies it across a network of 100,000+ LATAM professionals.

Every candidate on a Strider shortlist can work remotely for a U.S. company and clears the experience bar your role requires. Recruiters screen for the stack and skills your role requires, and professional English teachers grade recorded spoken responses against CEFR levels.

A Strider recruiter then evaluates communication and culture fit, including how well the candidate explains their experience, follows their own train of thought, and holds a conversation beyond the resume. Candidates receive feedback from this interview, so they arrive at your interview better prepared.

Within two days of the intro call, you get four or five candidates to review. Technical vetting then runs on the ones you want to take further, before your final interview. Here, a senior engineer walks the candidate through a project they completed and follows up on the decisions behind it to help weed out anyone relying on AI assistance. If their answers don’t hold up, they don’t end up on the final shortlist.

Most companies complete a first hire in about two weeks, and you only pay when you hire.

If your senior engineers are spending their afternoons on first-round screens, book a call to see what a vetted shortlist for your open role looks like.