Why vetting got harder
Hiring an engineer you've never met in person used to carry one main risk: they might not be as good as their résumé. Now there's a second risk: they might not be who they say they are.
- In June 2022, the FBI warned of a rise in applicants for remote IT, programming and database jobs using deepfake video and stolen identities in interviews, sometimes caught only when a background check showed the details belonged to someone else.
- In June 2025, the US Justice Department announced actions against North Korean schemes that placed remote IT workers at more than 100 US companies using stolen and fake identities.
- In a Gartner survey of 3,000 job candidates, 6% admitted taking part in interview fraud, and Gartner predicts that by 2028 one in four candidate profiles worldwide will be fake.
An engineer usually gets access to your code, your cloud and often your customers' data within days of starting. That makes vetting a security question as much as a hiring one. A good process answers four questions in order: is this person real, can they do the work, will they work well with your team, and is their history what they say it is.
1. Is this person real?
Check identity before you invest anyone's time in interviews. The signals that matter are consistency and history: does the phone number, email address, résumé and public profile all describe the same person, and do they have a footprint older than a few months?
- Verify identity against a government ID, and make sure the person on camera is the person on the ID.
- Look for thin or brand-new profiles, recycled résumé text, and contact details tied to other names.
- Keep cameras on in every interview, and watch for audio that doesn't match lip movement or someone who seems to be reading answers.
- Be wary of last-minute changes to where equipment should be shipped, or requests to be paid through a third party.
2. Can they do the work?
Algorithm puzzles and trivia questions mostly test how much someone has practiced algorithm puzzles. They say little about whether a person can work in a real codebase, make sensible trade-offs and explain them. A better test looks like the job itself:
- A realistic project built from the role. For a backend engineer, an API with real edge cases. For an AI engineer, a feature that uses a model and has to be shown to work, not just demoed.
- Their own explanation. Ask them to walk through what they built, what they'd change with more time, and why. This is where real understanding shows, and it's hard to fake.
- Identity checked during the assessment, too. A take-home test proves little if you can't tell who completed it. Proctored or recorded sessions close that gap.
For AI roles, add one more question: how do they know the model's output is right? An engineer who measures quality with evaluations and tests is worth far more than one who ships whatever looked good in the demo.
3. Will they work well with your team?
Remote engineers succeed or fail on communication: writing a clear pull request, raising a problem early, asking the question instead of guessing. Before the technical interview, decide what your team actually values (how it handles disagreement, how much autonomy it expects, how it communicates) and assess candidates against that, not against a generic idea of culture fit.
Then have the people who would review their work interview them. Senior engineers on the team are best placed to judge how someone reasons, how they take feedback, and whether they'll make the people around them better.
4. Is their history what they say it is?
Before anyone gets access, with their consent and as the law allows, confirm their identity, their past employment with former employers and their eligibility to work in the US. Where the role calls for it, check education and criminal records too. References are most useful when you ask specific questions: what did they own, what went wrong, would you hire them again?
5. Keep checking after they start
Vetting doesn't end on day one. Give new engineers access in stages, starting with what they need for their first tasks. Review their first pull requests closely. Hold a short check-in with their lead every month for the first few months. Most problems show up in the first few weeks, which is the cheapest time to catch them. Our guide to the first 30 days covers what to look for.
How we vet every engineer we place
Every person on one of our embedded teams goes through the same steps before they meet a client:
- Fitted to your team. We start with your role, your stack and the traits, values and culture your team cares about. Every candidate takes an Equip (opens in a new tab) personality assessment of how they work and communicate, compared against them, and only those who fit go on to screening.
- Proctored, so it's really them. Every candidate takes their assessment with Equip's AI proctoring: the camera checks it's the same person throughout, and switching tabs, a second screen or someone else in the room is flagged.
- Skills proven. Every candidate passes an Equip skills assessment built from the role: questions on the tools and judgment the job needs and, for engineers, coding challenges.
- Interviewed by our senior team. The people who would review their work interview them first, on judgment, communication and how they work in a team.
- Background and employment checked. With their consent and as the law allows: identity, past employment verified with former employers, eligibility to work in the US and, where the role calls for it, education and criminal records.
- You interview them. You meet everyone we put forward before they start.
- Monthly reviews. A check-in with your lead and reviews from our senior people, for as long as they're on your team.
If someone still isn't the right fit, we replace them. That's the point of doing this work up front: you get the engineer you interviewed, and you don't carry the risk alone.