How to vet offshore developers: the interview process that predicts performance

Companies that get burned offshore almost always skipped a step they would never skip at home, usually because a provider told them the vetting was already done.

This guide sets out a complete vetting sequence for offshore engineering, design and AI roles. It is written for the people who own the outcome: founders, CTOs and heads of engineering at UK and UAE companies. It assumes one non-negotiable, which we have argued for elsewhere: you interview real, named individuals before they join your team, exactly as you would for an in-house hire. If a provider offers anonymised profiles with substitution rights instead, the vetting question is already answered, and not in your favour.

Two layers of vetting, and who owns each

A useful way to think about vetting is in two layers.

The funnel layer is high-volume filtering: sourcing, CV screening, baseline technical assessment and communication checks. This is what a staff augmentation partner should run for you, and it is where a large screened network earns its keep. Our own network stands at more than 21,000 screened professionals, and the honest point about any such number is that the funnel behind it matters more than the number itself. When you evaluate providers, ask for the stages, the pass rates and who conducts the interviews; we have published the full set of questions to ask a staff augmentation company before signing.

The fit layer is yours and cannot be delegated. Nobody else can judge whether a candidate suits your codebase, your standards, your pace and your team. A partner can put three strong, pre-screened candidates in front of you within days; only your senior engineers can tell you which one to choose. The rest of this guide is about running that fit layer well, in roughly ninety minutes of interviewing per candidate.

Before any interview: write the brief

Most bad hires are made before the first conversation, in a vague brief. Before reviewing a single CV, write down:

• The first three months of real work. Not the job title, the actual tickets. A “senior React developer” brief hides whether the work is greenfield product build or untangling a legacy dashboard, and those need different people.
• Must-have skills versus trainable ones. Insisting on your exact stack shrinks the pool for little gain. A strong engineer picks up a new state-management library in a week; judgement and code quality are not learned on your time.
• The seniority you need, defined by autonomy. Junior means supervised, senior means owns outcomes with minimal direction. Write which one the role requires, because it changes every interview question that follows.

A good partner will pressure-test this brief with you at intake. If you are still deciding what shape of team to hire into, start with our guide on how to build an offshore team and come back to vetting once the roles are clear.

Stage 1: read the CV for evidence, not keywords

Keyword-matching CVs is how weak candidates get through and strong ones get missed. Read for evidence instead:

• Shipped things, described concretely. “Built the payments reconciliation service handling the company’s card volume” beats a list of eleven frameworks. Vagueness at CV stage rarely improves in person.
• Tenure and trajectory. A pattern of four-month stints deserves a question, not automatic rejection; contract markets produce short engagements legitimately. What you want is a candidate who can account for the pattern.
• Depth in something. Broad lists with no visible specialism usually signal shallow exposure. One system understood deeply predicts better than ten touched briefly.

This stage should take minutes per CV, because its only job is deciding who gets an hour of your engineers’ time.

Stage 2: a technical assessment that respects everyone’s time

Somewhere between the CV and the live interview, verify baseline competence. Two formats work:

• A short, timed assessment on realistic problems in the candidate’s claimed stack. Its job is filtering, so keep it under an hour; you learn little more from four hours than from one, and strong candidates decline bloated tests.
• A compact take-home that mirrors a real task from your codebase, capped at two to three hours, with the cap stated. Review it as you would a pull request: correctness first, then structure, naming and tests.

Whichever you use, have a human read the result. An automated score tells you the code ran; it does not tell you the candidate wrote readable code, handled the edge cases thoughtfully, or made sensible trade-offs under the time limit. If your provider ran an assessment in its own funnel, ask to see what was assessed rather than re-running a duplicate; use your assessment slot for something closer to your actual work.

Stage 3: the live technical interview

This is the highest-signal hour in the whole process, and the person running it must be a senior engineer who will work with the hire. Structure it around real work rather than puzzles:

• Read code together. Give the candidate a real excerpt, yours or prepared, and ask what it does, what is wrong with it and what they would change. Engineers spend far more time reading code than writing it, and this exercise separates practised understanding from rehearsed syntax in minutes.
• Extend, do not perform. Pair on a small change to a working example: add a validation, fix a failing test, handle a new case. Watch how they navigate unfamiliar code, whether they ask clarifying questions, and how they respond when their first approach hits a wall.
• Go one level deeper than the CV. Pick the project they are proudest of and ask why it was built that way, what they would do differently, and what broke in production. Depth is unfakeable at three questions down; candidates who did the work go deeper happily, and candidates who watched someone else do it run out of detail fast.
• Leave algorithm trivia out of it. Inverting a binary tree on a whiteboard predicts whiteboard performance. Unless the role genuinely involves algorithmic work, test the job, not the folklore.

Stage 4: communication and working style

For a distributed team, communication is a core technical skill, not a soft extra. Test it deliberately:

• Interview on video, in English, about technical substance. The question is not accent, it is whether the candidate can explain a decision clearly, disagree constructively and say “I do not know” when it is true.
• Ask for something written. A short paragraph explaining a technical choice to a non-technical stakeholder tells you what their pull requests, ticket updates and incident notes will read like. Written clarity is the skill that makes a four-hour time zone offset stop mattering, a point we develop in our guide to managing an offshore team.
• Confirm the practical details in the interview, not after it. Working hours and the live overlap window with your day, in hours. Their setup for calls and pairing. How they flag being blocked. None of this is awkward to ask; all of it is awkward to discover in week two.

Red flags that end a candidacy

• A portfolio or CV project the candidate cannot walk through in depth
• Fluent recitation of definitions, but silence when asked to apply them to a scenario
• No questions about your product, your codebase or your team, in an interview for a role inside all three
• Evasiveness about what they personally did versus what their team did
• Perfect written English in the take-home and broken communication live, or the reverse, without an explanation that holds

One flag deserves care in the other direction: nerves are not a red flag. A candidate interviewing in a second language for a role four time zones away is allowed a slow first ten minutes. Judge the substance once they settle.

After the yes: the first ticket is the final interview

No process, however careful, predicts perfectly. Treat the first weeks as the last stage of vetting rather than the end of it: a small, real, shippable first ticket in week one, code review in both directions from the start, and a written 30, 60, 90 day expectation both sides can check the ramp against.

This is also where the commercial terms behind the hire matter. However good your interviewing, some placements do not work out, and what separates providers is what happens next. Ask for written replacement terms before anyone starts, and hold the provider to a replacement shortlist in days rather than a restarted search. Ours are set out plainly in how it works, and the honest way to compare the full cost of any offshore hire, screening and replacement cover included, is broken down in what offshore staffing actually costs.

Vetting offshore developers is not a different discipline from vetting anyone else. It is the same discipline, applied with slightly more structure because you cannot rely on hallway impressions to fill the gaps. Companies that run this process hire offshore engineers who perform like in-house ones, because they were selected like in-house ones.