Part of the guide: Nearshore Software Development: A Field Guide
To vet a contract software developer well, test the work they will actually do, not the work that's easy to test. A résumé tells you where someone has been. A puzzle tells you how they do under a stopwatch. Neither tells you whether they'll make good decisions in your codebase with nobody watching, which is the thing you're paying a senior contractor for.
Contract engagements make this harder, not easier. You usually have less time, the developer usually has other options, and there's no long probation period to catch a bad fit. So the vetting has to be short and it has to be real. Here's how I'd approach it.
What you're actually checking for
Before choosing any test, write down what "good" means for this engagement. For a senior contract developer it's usually four things:
- Judgment. Given two reasonable approaches, do they pick the one that fits your constraints, and can they say why?
- Depth in your stack. Not familiarity with its name. Production experience with its sharp edges.
- Communication. On a remote or nearshore team, most of the work is read before it's run. Tickets, pull requests and design notes are where a contractor either saves your team time or costs it.
- Reliability. Do they say early when something is off, and do they finish what they start?
Everything below is a way of gathering evidence on those four. If a step doesn't tell you anything about one of them, drop it.
Start with the work they've already done
The cheapest evidence is work that already exists. Ask for two or three things they've built in the last few years and a short walkthrough of one of them: what the problem was, what they decided, what they'd change.
You're not grading the project. You're listening for the decisions. A strong senior developer talks about trade-offs, constraints and consequences. A weaker one describes features. If most of their recent work is under NDA, that's normal for contractors; ask them to describe the shape of a problem instead of showing the code.
Choose a technical test that looks like the job
Every technical test is a trade-off between how realistic it is and how much it costs both sides. Roughly, from least to most realistic:
- Algorithm puzzles. Easy to run and easy to compare, but they mostly measure practice at puzzles. Senior people often decline them, and the ones who don't may not be the ones you want.
- Take-home exercises. More realistic, but unpaid take-homes filter out busy senior developers first, and you can't tell how much of the result was theirs. AI tools make that harder still: generating plausible code is cheap now, so a finished exercise proves less than it used to.
- Live pairing in a real codebase. The most realistic option. You watch how they read unfamiliar code, ask questions, and change their mind when something doesn't fit. It takes a couple of hours of an engineer's time, and it's worth it.
- A short paid trial. A few days on a real, well-bounded task. Very realistic, and fair to the developer because it's paid. It needs a task that's ready to hand over and someone available to review it.
For a senior contractor, live pairing or a paid trial will tell you far more than the first two. Our own four-gate vetting funnel ends with a two-hour live pairing session for exactly this reason.
Test written communication on purpose
Most vetting processes test code and assume the writing will be fine. For remote work that's backwards. Ask for something written: a short description of how they'd approach a problem you give them, or the pull request description for a change they made during pairing.
Read it the way your team will read their work every day. Is it clear on the first read? Does it say what was decided and why? Does it flag what they're unsure about? A developer who writes well will make everyone around them faster. One who doesn't will generate meetings.
Check references for the things you can't observe
References are only useful if you ask about things a short evaluation can't show. Skip "were they good?" and ask:
- "What kind of work did you give them, and what did you stop giving them?"
- "When something went wrong, how did you find out?"
- "Would you engage them again for the same kind of work?"
Pay attention to hesitation more than praise. A pause before the third answer tells you more than a paragraph of compliments.
Red flags worth taking seriously
- Every past project was a success. Senior people have scars and can describe them without blaming anyone.
- No questions before the first answer. On an unfamiliar problem, a senior developer's first move is almost always a question.
- Vague answers about stack depth. "I've worked with it" without a specific problem they solved in it.
- Friction over a paid, realistic test. Declining an unpaid take-home is reasonable. Declining a paid trial on real work is worth a follow-up question.
- Overlapping commitments they won't discuss. Contractors often work with more than one client. That's fine if it's said up front and the hours you need are actually available.
Don't forget the paperwork
Vetting the person is half of it. A contract engagement also needs a contractor agreement that covers who owns the work, confidentiality, how and when they're paid, and the right tax forms for where they live. With a developer in another country, that last part gets complicated quickly. A contractor of record handles it for you, so your team can focus on the technical evaluation.
Vet yourself, or check the vetting
You can run all of this yourself, and for one engagement it's manageable. Once you're doing it repeatedly, most teams hand the screening to a partner and spend their own time on the last conversation. If you go that way, ask the partner the same questions you'd ask yourself: what do you test, how realistic is it, and how many people don't get through? A vague answer means there isn't a real bar. We wrote a longer checklist for choosing a partner if you're at that stage.
We publish ours because we think buyers should be able to check. We bring on roughly 3.9% of the developers who apply, and how it works explains what happens between their application and your first conversation.