To vet software developers is to prove four things before anyone touches your code: they are who they say they are, they can do the work at the seniority claimed, they can communicate in a distributed team, and the person who passed is the person who shows up on day one. A sound process checks identity first, runs a staged technical screen with a live round last, and designs for AI use instead of pretending it doesn't happen.
Most vetting advice skips one question: how to audit a vendor's vetting claims when you're buying a shortlist instead of building a loop. We're a vendor ourselves, so the standard we apply to others applies to us: HighCircl runs four stages, all run by senior engineers, and about 1 in 10 applicants pass.
What's on this page
- What developer vetting has to prove
- Verify the person before the skill: identity and interview fraud
- The stages of a technical screen
- Take-home projects vs live coding
- Interviewing when candidates use AI
- Assessing architecture and seniority
- AI screening vs engineer-led screening
- Auditing a vendor's vetting claims and pass rates
- Red flags in a vetting process
- Vetting does not end at the offer
- What this means for your hiring decision
- All vetting and interview guides
- FAQ
What developer vetting has to prove
A CV is a claim, not evidence. It tells you what the candidate says they did, in the words they chose, and nobody has checked it. Vetting is the work of turning each claim into something you've seen or verified yourself.
There are four claims to test. Identity: the person is real, and is the same person at every stage. Skill and seniority: they can do the work at the level you're paying for. Communication and remote fit: they can explain a decision in writing, disagree usefully and work without someone watching. Continuity: the engineer you interviewed is the engineer who joins the team.
Each stage you skip leaves one of those claims unproven, and the failure shows up in a different place. An unproven identity shows up as a security incident. An unproven skill level shows up three months in, as slow reviews and rework. An unproven communication style shows up as a quiet engineer nobody can read. Our general guide to how to hire software engineers places vetting inside the whole hiring process, and evaluating engineers for remote-first teams covers the traits that matter once nobody shares an office: written clarity, independence and impact beyond hours worked.
Verify the person before the skill: identity and interview fraud
Check identity first. In our judgment, it's the cheapest filter and the one with the worst downside. If the person isn't who they claim to be, a flawless coding round tells you nothing.
The schemes are documented in court filings. A federal court sentenced Christina Chapman to 102 months for a scheme that, per the DOJ's sentencing announcement, defrauded 309 U.S. companies and generated more than $17 million. A separate DOJ indictment of two North Korean nationals and three facilitators alleges the defendants obtained work from at least 64 U.S. companies, that payments from ten of them generated at least $866,255 in revenue, most of it laundered through a Chinese bank account, that they used forged and stolen identity documents, including passports containing a real person's stolen identifying information, and that laptops from victim companies were hosted at U.S. residences. These people were hired.
The FBI's Internet Crime Complaint Center issued a public service announcement (I-072325-4, 23 July 2025) that works as a checklist. The IC3 advisory tells employers to confirm employment and education directly with employers and schools, compare identity documents, photos and contact details, and, on video calls, ask candidates to show their surroundings and watch for glitches when a hand passes in front of the face. It also says to photograph the candidate so you can check the interviewee is the person working, to withhold system access until background checks finish, to ship laptops only to the address on the worker's ID and to brief any third-party staffing firm on the guidance. Its guidance also flags misspellings in identity documents, requests to ship equipment to a different address, and a different person doing the work than the one interviewed. It says "Beware of agreements to pay employees using virtual currency" and "Monitor employees who change their bank accounts often".
Treat the hand test as a prompt, not proof. A glitch can be a bad connection. Our guide to catching fake candidates in remote engineering hiring turns this into five checks: identity, independent references, the live video moment, delayed laptop and access, and confirming the vetted engineer is the one who shows up. Keep fake candidates separate from candidates who simply use AI in a test. The first is fraud and ends the process. The second is a process-design problem, covered below.
Checks on personal data need a lawful basis and proportionality. Our view is that you should collect only what each check needs and keep it no longer than the hire requires. We haven't gathered country-by-country rules on background checks, so the EU hiring compliance hub is the place to start, followed by a local lawyer.
The stages of a technical screen
In our judgment, order matters more than any individual test. Put the cheapest, highest-cut filter first and the most expensive human time last.
The sequence we'd defend is a pass bar written before the first candidate is seen, a communication check before any code, a take-home that opens a conversation and a live architecture session as the final gate. The communication check goes early because it's cheap and it removes people who couldn't work with your team however well they code. Our guide to designing a technical screening process walks through all five steps, including tracking your pass rate so you learn what each stage cuts.
Two short pieces cover the people side. HighCircl's first interviews explain why our first interviews are all about people, and the older post on why soft skills matter as much as technical skills gives the argument for scoring communication as its own stage and not as an afterthought to the coding round.
Assessment platforms are tools, not stages. They automate one part of a screen. If you're weighing HackerRank, CodeSignal, Codility, CoderPad and TestGorilla, our comparison of five coding assessment platforms shows what each does and what none of them test. A platform score belongs early in the funnel as a sorting signal. It shouldn't replace the stage where an engineer talks to the candidate.
Take-home projects vs live coding
Which tells you more? Our judgment: neither alone. A take-home shows what someone produces with time and tools. A live round is better placed to show who did the thinking. The first can't tell you who wrote the output.
| Dimension | Take-home project | Live coding or live session |
|---|---|---|
| What it catches | Design choices, code structure, tests, documentation, effort on a realistic problem | Real-time reasoning, how the candidate reacts to changed constraints, whether the person on the call is the person you hired |
| What it misses | Who wrote it, and how much was generated | Polish that comes from time, and strong people who freeze on camera |
| Cost to run | Candidate hours, reviewer reading time | Scheduled interviewer hours, the same time for each candidate |
| Fraud and AI exposure | High, because it's unobserved | Lower, if the interviewer watches the screen and probes decisions |
This table is our judgment from running both, not a measured comparison. The conclusion that follows from it is the one HighCircl's own process uses: a take-home mirroring real work, then a live session where the candidate explains it. Our guide to running a live coding interview and catching AI cheating covers the problem choice, the time-box, writing the rubric before the session and the tells that someone is getting help off-screen. It includes a longer live-versus-take-home comparison.
Our view on take-home projects: keep each one to a size you'd accept as a candidate, base it on a real problem and treat it as the opening of the conversation, not the verdict.
Interviewing when candidates use AI
Should you allow it or ban it? Pick based on what you're hiring for, then score the thing you pick. The mistake is leaving the policy unstated and discovering mid-interview that the candidate and the interviewer assumed opposite rules.
Two engineering teams have said in public why they changed. Coinbase's July 2026 write-up describes how it rebuilt its engineering interviews for AI use, and says it is running 45- and 90-day pulse surveys on the results. Canva reached a similar point and now expects candidates to use Copilot, Cursor or Claude because AI tools solved its computer-science-fundamentals questions correctly in seconds.
If AI is allowed, the signal moves from "can they write it" to "can they judge it". Karat's human-AI interview rubric scores several things, including code productivity, product sense and problem solving, and AI proficiency. Our additions, labelled as judgment: give a task where the first AI answer is subtly wrong, score whether the candidate catches and overrides it, and keep a short AI-off segment for fundamentals so you can see what they know without a tool.
Ban it in unobserved tests only if you can enforce it, which you mostly can't. A take-home with a no-AI rule is a rule you'll never see broken. That's the case for putting an observed round last. Our guide to running a coding interview where candidates can use AI has a six-step runbook, including when a ban still makes sense. We'd pilot an AI-allowed round on two hires before changing the whole loop, and compare it with how those hires perform, since nobody has published evidence yet that these interviews predict performance.
Assessing architecture and seniority
Seniority shows up as judgment under changed constraints, and years of experience don't measure that. In our judgment, a fluent mid-level engineer with an AI assistant can now produce clean, idiomatic code, so clean code stopped being the signal. What separates the senior engineer is the answer to "what breaks if the traffic is ten times higher, or the team halves?"
The method that works best in our experience is a live walk-through of the candidate's own take-home, followed by a change you introduce on the spot. The candidate has to explain why they chose what they chose, then extend or refactor under a new constraint. Someone who wrote the take-home tends to handle this easily. Someone who didn't, or didn't understand it, usually struggles. We explain the pattern in a short answer on how to assess architectural skill.
Our backend hiring guide on what seniority means and how to test it shows the same idea applied to one stack. If you're a non-technical buyer, you can't judge the code yourself, so the realistic options are an outside technical reviewer and a paid trial. The guide to vetting a technical co-founder covers both, plus a disagreement test and the vesting questions that apply to co-founders.
AI screening vs engineer-led screening
AI is good at sorting and bad at judging. That's our position, and the field evidence we can cite is narrower than the marketing around it.
| Stage | Automate | Keep with a human engineer |
|---|---|---|
| Matching profiles to a role | Ranking and filtering profiles | Reviewing the shortlist |
| Identity and records | Document checks as a first pass | A live, unscripted conversation |
| Skills screen | Auto-graded tests as a sorting signal | Reviewing the take-home with the candidate |
| Architecture and seniority | Nothing | A live session run by a senior engineer |
| Final decision | Nothing | A named person who owns it |
This split is our judgment. A field experiment by Jabarian and Henkel, posted on arXiv, covered 70,884 applications (67,056 randomized) and 131 recruiters. It used AI voice interviews, and applicants were 12% more likely to get an offer. The roles were customer service in the Philippines, humans made every decision, and none of the candidates were engineers. It's evidence that AI can run a structured first conversation. It isn't evidence that AI can judge engineering ability.
Vendors describe their own approaches. Arc's vetting post lists four stages: profile screening, a communication assessment, a technical interview with live coding or pair programming, and a final review. Separately, Arc's HireAI page describes HireAI as "our GPT-4-powered AI recruiter" for matching. Our guide on AI vs human technical screening walks through the three approaches and the stage-split in more depth, and the short answer on engineer-led vetting defines what we mean by it: senior engineers run every technical stage.
Auditing a vendor's vetting claims and pass rates
If you're buying a shortlist, the vendor's vetting is your vetting. You can't audit what you haven't asked about, so the first job is to get claims in writing and read them for what they leave out.
Here's what several vendors say on their own pages. We've quoted them as published and haven't tested any of it.
| Vendor | Stated acceptance | Stages as described | What the page leaves open |
|---|---|---|---|
| Toptal | Typically fewer than 3% accepted | Five stages (the fifth, continued excellence, is ongoing performance) with stated pass rates: language and personality about 26.4%, in-depth skill review about 7.4%, live screening about 3.6%, test project about 3.2%, continued excellence 3%. The page says screening takes about 3 to 8 weeks | Measured against applications received; the page doesn't say how many are qualified |
| DistantJob | About 1% | Four: integrity and safety shield, expert-led technical screen, business English and communication audit, remote readiness and cultural alignment | The figures are the vendor's own and unsourced. It says stage 1 removes 60-70% and claims automated platforms pass 10-30% |
| Arc | Top 2% | Four: profile screening, communication assessment, technical interview, final review | Calls the technical interview "expert-led" without saying who the experts are |
| HighCircl | About 1 in 10 applicants | Four stages run by senior engineers | The denominator is applicants, not qualified applicants |
Read the table for what it doesn't say. A pass rate is comparable only when you know the denominator: all applicants, qualified applicants or profiles that reached a stage. "Top 3%" and "about 1 in 10" can describe the same funnel measured differently. DistantJob also claims 60% of candidates passing automated coding tests fail its architecture interview. That's a vendor figure to verify, not a fact to repeat. Toptal publishes stage rates and says the 3% is of applications received, which is more specific than most percentage claims. A percentage with no denominator is marketing, and that's our judgment.
Put these in writing to any vendor:
- Who interviews at each technical stage, and what are their credentials?
- How is identity verified, and by whom?
- Is the engineer you interviewed contractually the one placed on your team?
- What is the pass rate at each stage, and what is the denominator?
- How is AI assistance handled in unobserved tests?
- What are the replacement terms if the engineer isn't working out?
- Can you see a sample rubric?
- Can you speak to a reference client?
- Can you meet the interviewers who will assess your candidates?
- Will the vendor support a short paid trial before you commit?
Then verify. Ask for stage-level pass rates and the rubric, read the interviewer bios and call a reference client. In our judgment, a paid trial is the strongest test, because it measures the thing the vetting was supposed to predict. The full seven-step process is in our guide to evaluating a nearshore vendor. Sourcing sits upstream of vetting, and our post on how we find senior developers shows what a curated approach looks like before the first interview.
Red flags in a vetting process
Pause when you see one of these. Not every flag is disqualifying alone, but two in the same row are reason to stop and investigate before going further.
| Stage | Candidate-side flag | Vendor-side flag |
|---|---|---|
| Identity | Misspelled documents; photos or contact details that don't match public profiles | No named identity step, or identity checked only by an automated tool |
| Interview | The person interviewed differs from the person working; refuses to show surroundings or to move a hand in front of the face | "AI-vetted" with no named human step |
| Technical | Strong take-home, but can't explain or change it live | No stated stages; percentages with no denominator |
| Evidence | Employment or education that employers and schools won't confirm | No stage-level pass rates, no sample rubric |
| Onboarding | Asks to ship equipment elsewhere, asks to be paid in virtual currency, changes bank accounts often | The engineer who shows up isn't the one you interviewed |
The candidate-side column is warning signs drawn from the FBI's guidance, with the live-coding mismatch added from our judgment. The vendor-side flags are our judgment from the audit above. The fake-candidates guide linked in the identity section holds the full checklist behind the identity, interview and onboarding rows. Read the table across a single row as well as down it: a candidate flag and a vendor flag in the same stage mean the vendor's check missed something it should have caught.
The swap risk deserves its own line: the engineer you interviewed isn't the one who starts. In our judgment, the fix is a contract clause, not a better interview. The named engineer is the one placed, and any substitution needs your written approval.
Vetting does not end at the offer
A good vet lowers the odds of a bad hire. It doesn't remove them. Treat the first weeks as the last stage.
In our judgment, use a trial period and set the review points before the start date: what does a good week two look like, and who decides it? Give early work that's small, shippable and reviewed, so you see real output quickly. Hold back production and sensitive access until the checks are complete, as the FBI advises, and widen it in steps.
If the engineer isn't working out, the order is to diagnose, document, escalate to the vendor and replace. Replacement terms matter here, which is why they're on the audit list. Our guide to handling an underperforming staff augmentation developer walks through that sequence.
What this means for your hiring decision
The decision is whether to trust a vendor's vetting claims or build your own loop, and what must be verified before an engineer gets repo or production access.
Before repo access, require an independent identity and employment check, one live unscripted video moment, and a contract line naming the interviewed engineer as the placed engineer. The court cases above involved people who got hired, so don't rest this on a vendor's word.
Put three questions to any vendor in writing: who runs each technical stage, what each stage's pass rate is, and how unobserved tests handle AI.
Two points of judgment. Pilot an AI-allowed round on two senior hires and compare it with their 90-day performance, because Coinbase says it is still running 45- and 90-day surveys and we found no published evidence that these interviews predict performance. And treat any percentage without a denominator as marketing.
Once the vetting checks out, the seven-step vendor evaluation covers the rest of the decision.
All vetting and interview guides
Guides not linked in the sections above, grouped by topic.
Hiring fundamentals
AI-era seniority
Choosing and comparing vendors
- Arc.dev alternatives: when AI matching isn't enough
- 5 cheaper Toptal alternatives in 2026, with real rates
- Toptal vs Turing: which fits an EU engineering team?
FAQ
How do you vet a software developer?
Run four checks in order. Verify identity and records first, then test communication before any code, then run a technical screen that ends in a live session with an engineer, then confirm the person who passed is the person who joins. Give access in steps and treat the first weeks as part of the vet.
How can you tell if a developer candidate is fake or using a proxy?
You can't rely on one signal. The FBI's advisory recommends confirming employment and education directly with employers and schools, comparing identity documents and photos, asking to see the candidate's surroundings on video, shipping laptops only to the ID address and holding back system access until checks finish. It also flags misspelled identity documents, equipment sent elsewhere and a different person working than the one interviewed.
Should candidates be allowed to use AI in a coding interview?
In our judgment, yes for most senior roles, if you score judging and overriding the AI and not just output. Canva reports that AI tools solved its fundamentals questions in seconds, and Coinbase rebuilt its interviews for AI use. Keep a short AI-off segment for fundamentals, and ban AI only where you can observe the session.
Is a take-home test or a live coding round better?
Neither alone, in our judgment. A take-home can't show who wrote the work, and a live round can. The combination we use is a take-home that mirrors real work followed by a live session where the candidate explains and changes it.
What does a "top 3%" or "top 1%" claim from a hiring platform mean?
Nothing until you know the denominator. Toptal's own page says typically fewer than 3% of applications are accepted; DistantJob says about 1% of candidates who enter its process are presented to clients (its FAQ says "applicants", so even the vendor's denominator shifts). Applicants, qualified applicants and profiles that reached a stage give very different percentages, so ask which one the number uses and who ran each stage.
Can AI replace human technical screening?
Not for judging engineering ability, on the evidence we can cite. The field experiment we cite used AI voice interviews for customer-service roles in the Philippines, with humans making every decision, and it didn't involve engineers. AI is useful for sorting and first conversations. Seniority and architecture still need a senior engineer.
