How to hire developers when everyone uses AI

Short answer: to hire developers when everyone uses AI, stop trying to detect it and start verifying understanding. Look for evidence that is slow and social to produce: years of changes accepted by other people, reviews given, long-term ownership of a project. Then ask the candidate to explain their own code. Someone who understands what they shipped can answer follow-up questions. Someone who pasted it in usually cannot.

Most developers now use AI assistants at work, so "did you use AI?" is the wrong question. The useful question is "can you judge, explain and take responsibility for this code?"

Why detecting AI doesn't work

Teams have tried to catch AI use in tests and applications. It fails for practical reasons.

• No reliable detector. Code is short, formulaic and often edited by a human after generation. Nobody, including DevEval, can tell you honestly whether a given piece of code was written by a person or a model, and any tool that claims certainty should be treated with suspicion.
• Most work will involve AI. If your engineers use assistants daily, banning them in the interview tests a skill the job doesn't use.
• Accusations are costly. A false positive harms a real person and your reputation as an employer.
• The arms race favours candidates. Whatever you detect today will be prompted around tomorrow.

Karat's co-founder has said around 80% of candidates use LLMs on tests, as reported by SoftwareSeni. Treat that as one industry claim, not a measured fact. The practical conclusion holds either way: output alone, such as a solved puzzle or a finished take-home, is a weaker signal than before.

What AI can't easily fake

AI can produce a function in seconds. It can't produce these:

Evidence	Why it's hard to fake
Merged pull requests to projects the candidate doesn't own	A maintainer had to approve each one, over weeks, in public
A history of work over months or years	Time can't be compressed
Code reviews given that spot real risks	Needs understanding of a specific system and its history
Responses to reviewer feedback in the thread	Shows a real human conversation and a change of mind
A colleague or maintainer who will vouch for them	Needs a relationship
An accurate explanation of why a change was made	Needs the knowledge to be in their head

None of these is perfect. A determined person can fabricate parts. Together they are much harder to fake than a test result.

The AI-era screening process

Step 1: Look at the track record (10 minutes)

Read the candidate's public work: merged pull requests to others' projects, reviews given, and how long they kept at it. See how to evaluate a developer's GitHub profile for the method.

What to ignore: commit counts, stars and green squares. AI can generate a lot of commits and activity quickly, so volume proves nothing.

DevEval does this automatically. It only reads code the candidate wrote, focuses on merged PRs and reviews, and reports what it could not see. It makes no claim about whether code is AI-assisted.

Step 2: Ask about their own code

This is the most important step. Choose one change from their history and ask:

• "Walk me through this change. What was the problem?"
• "Why did you choose this approach over the alternatives?"
• "What did the reviewer ask for, and did you agree?"
• "What would break if I changed this line?"
• "What would you do differently now?"

A developer who wrote and understood the code answers with specifics, trade-offs and honest doubts. A developer who didn't tends to describe what the code does in general terms and stalls on "why".

Keep the tone curious, not accusatory. Someone who used an assistant but understands the result passes this test, and that is the right outcome. You want people who can take responsibility for code, however it was drafted.

Step 3: Change something live

Ask the candidate to modify something in their own code, or in a small piece of yours, while sharing their screen. A change request like "now handle the case where the list is empty" shows how well they understand the structure. Allow AI tools if your engineers use them, and watch how they use them: do they read the output, test it, and push back on it?

Step 4: Check judgment, not just output

Give them something AI can't judge for them: a pull request from your codebase to review, or an ambiguous requirement to clarify. Ask what they would check first, what worries them, what they would ask the product team. These are the skills that matter when AI writes the first draft.

Interview questions that test understanding

• "Which part of this code are you least confident about?"
• "Tell me about a bug in your own code that an assistant or a reviewer missed."
• "When do you not trust AI-generated code?"
• "How do you verify a change does what you think it does?"
• "Show me something you wrote and then deleted. Why?"

Strong answers are specific and unprompted. Weak answers are generic ("I always review AI output carefully") with no example.

Red flags and green flags

Green flags

• Explains trade-offs in their own words
• Admits uncertainty and says how they would check
• Can modify their own code live
• Has a history of changes accepted by others
• Uses AI openly and describes how they check its output

Red flags

• Cannot explain why code in their own repository works
• Many large changes, all committed at once, with no discussion
• Gets vague when asked "why" instead of "what"

One flag is a question to ask, not a verdict.

What this approach can't tell you

• Private work. A developer's best work may live in a company repository you can't see.
• Team attribution. Commits show who typed, not who decided.
• Fabrication. A motivated person can inflate a profile with fake contributions. The explanation step is the safeguard.
• Fit. Nothing here shows whether someone suits your team.

When there is no public record, use a conversation about a past project and a short paid exercise.

Being fair to candidates

• Tell them your rules on AI tools before the interview, and apply them evenly.
• Don't penalise people for using the tools your own engineers use.
• Say what you will look at, including public code.
• Let candidates add context for work you can't see.
• Use any report, ours included, as one input to a human decision. See the methodology and pricing pages for details.

For a wider comparison of screening formats, read take-home vs live coding vs GitHub review.

Checklist

• Decided and communicated your policy on AI tools in interviews
• Looked at merged PRs and reviews, not commit counts
• Picked one real change to ask about
• Asked "why", not only "what"
• Asked for a small live change
• Gave candidates a way to share private work
• Made a human decision, with notes

Frequently asked questions

Should I ban AI in interviews? Only if the job bans it. Otherwise watch how candidates use it, since that is the real skill.

Can I tell if code was written by AI? Not reliably. Verify understanding instead.

Is this unfair to people with little public code? It can be, which is why a conversation about private work and a short paid exercise must stay available.