Most bad offshore hires were visible before anyone signed anything. The signs were there in the interview, in the code sample, in how the candidate answered a question they didn’t fully understand. They just weren’t checked, usually because the hiring team was in a hurry and the CV looked right.

This is the checklist we use when we screen engineers, and the one we’d suggest you use on anyone we, or any other vendor, put in front of you. None of it needs a specialist. It needs about two hours of your team’s time per candidate, which is a lot cheaper than three months with the wrong person.

1. Ask for code they wrote, then ask them to explain it

A take-home test tells you whether someone can solve a puzzle. Real code tells you how they work. Ask for a repository, a pull request or even a snippet from a past project they’re allowed to share, then spend twenty minutes walking through it together. Why this structure? What would you change now? Where did it break? Engineers who wrote the code answer easily. People presenting someone else’s work run out of detail fast.

2. Give them a vague ticket

Real tickets are rarely complete. Describe a small feature loosely and see what happens. A senior engineer asks questions before writing anything: who uses this, what happens on failure, is there an existing pattern. A weaker one starts coding immediately. This single exercise tells you more about day-to-day working than most technical tests.

3. Check depth in your stack, not years in software

“Eight years of experience” can mean eight years of the same year. Ask about the last three versions of the main framework you use, a problem they hit with it and how they solved it, and something about it they dislike. Genuine depth shows up as specific, slightly opinionated answers.

4. Test written communication

Offshore work runs on writing: tickets, pull request descriptions, Slack updates, handover notes. Ask the candidate to write a short summary of a technical decision, or review a pull request in writing. Clear writing matters more than a polished accent on a video call.

5. Watch how they handle “I don’t know”

Ask one question slightly beyond their stated experience. The best answer is an honest “I haven’t done that, but here’s how I’d find out.” Bluffing in an interview turns into bluffing in standups, and that is very expensive to discover later.

6. Do a live debugging session, not a whiteboard

Share a small broken piece of code and debug it together for thirty minutes. You’ll see how they read code, form hypotheses and use tools. It is closer to the actual job than algorithm questions, and harder to rehearse.

7. Ask who employs them and what happens if they leave

This one is for the vendor as much as the engineer. Is the developer on the vendor’s payroll, a subcontractor or a freelancer? What notice do they have to give? What happens to your project if they resign in month two? A vendor who can’t answer clearly is passing that risk to you.

8. Confirm the working hours in writing

Agree the exact overlap hours before the start date, and check the candidate has agreed to them too, not just the vendor. Mismatched expectations on hours cause more early friction than skills gaps do.

9. Speak to a reference about collaboration

Skip “were they good?” and ask “what was it like to review their code?” and “how did they handle disagreement?” A former lead’s answers to those two questions are far more useful than a general endorsement.

10. Plan a real first two weeks

Vetting doesn’t stop at the offer. Give the new engineer a small, real task in week one and a code review from your best reviewer. By the end of week two you will know whether the hire works. That’s also why a replacement window matters: our engagements typically include replacement candidates within the first 30 days if the fit is wrong.

The short version

Read their real code, give them a vague problem, test their writing and make the first two weeks count. If a vendor resists any of these steps, that tells you something too. If you’d like to see how we screen for a specific role, each of our role pages explains what we look for and the questions worth asking.