Most technical interviews measure the wrong thing well. They test whether a candidate can invert a binary tree on a whiteboard under stress — a skill they will use approximately never — and skip whether they can read someone else’s messy code, ask the right question before building, or say "I don’t know" out loud. Vetting software developers is our core business risk: when a client brings in one of our engineers, that developer’s first month is our reputation. So we rebuilt the process around one principle: test the job, not the trivia.
Here is the actual process, stage by stage, and the reasoning behind each gate.
Why résumés and puzzle interviews fail
A résumé tells you where someone sat, not what they did there. "Five years of React" can mean five years of growth or one year repeated five times. And algorithm puzzles under observation mostly measure interview practice and nerves — decades of hiring research keep pointing the same direction: work-sample tests, where candidates do a realistic slice of the actual job, predict performance better than almost anything else, and unstructured "gut feel" conversations predict worst of all. That is why vetting software developers through friendly chats produces coin-flip results — and why our funnel is built on work samples instead. Every stage is a sample of real work, scored against a rubric written before the interview.
Our four stages for vetting software developers
Stage 1: The code-reading test
Before anyone writes code for us, they read some. We hand candidates a deliberately imperfect pull request — around 200 lines with a subtle bug, a security smell and a couple of design questions buried inside — and ask them to review it. This filters more decisively than anything else we do. Developers spend far more time reading code than writing it, and a candidate who reviews carefully, catches the bug and phrases feedback constructively has just demonstrated three job skills in forty-five minutes. Weak candidates skim and comment on formatting.
Stage 2: A realistic build exercise
Next comes a small, time-boxed project mirroring real work: a small API with validation and tests, or a feature added to an existing codebase we provide — because extending existing code is the daily reality, and greenfield toys hide the skill that matters. Take-home, four to six hours, on their own tools and schedule. We score it on a rubric: correctness, error handling, tests, clarity of naming, and the README explaining their trade-offs. That last item is deliberately weighted: an engineer who writes "I skipped caching because the brief didn’t justify the complexity" is showing judgment, which is the actual product.
Stage 3: The defense conversation
We walk through their submission together and change the requirements live: "Now it needs to handle ten times the load. Now two clients want conflicting behavior. What breaks first?" This is where copy-pasted or AI-generated submissions collapse in minutes — you cannot defend design decisions you never made. It is also where strong engineers light up, because defending trade-offs against shifting requirements is what senior work is. No trick questions, no gotchas. Just the job, out loud.
Stage 4: Communication under real conditions
The final stage runs in English, on video, and simulates the client relationship: explain a technical problem to a non-technical stakeholder, push back politely on a bad idea, write a short status update on the exercise they built. For nearshore work this is not a soft skill — a brilliant engineer who cannot flag a risk clearly in a Tuesday standup will cost you more than an average one who can. Working in U.S. time zones means our developers talk to your team all day, so this stage carries real veto power.
The red flags we treat as disqualifying
- Blaming every previous team or codebase — the common factor is the candidate.
- Zero questions asked before building the exercise. Real requirements are never complete; someone who fills gaps with silent assumptions will do it in production too.
- Cannot explain their own submitted code in the defense round.
- Bluffing instead of saying "I don’t know." We ask one question outside anyone’s stack on purpose, because honesty about limits predicts how they will handle production incidents.
What this means for you
Roughly one candidate in ten clears all four stages, which is the point: when you bring in developers through nearshore staff augmentation, the vetting already happened — against the job, not the whiteboard. And because the engagement lives or dies on month-two performance rather than interview-day polish, an ongoing partner is structurally incentivized to filter for the long haul; that difference is much of what separates a nearshore software development partner from a résumé forwarder.
Frequently asked questions
Can we interview the developers ourselves?
Yes, and we encourage it. Our process gets candidates to the table; your interview confirms fit with your team and stack. You always keep the final yes.
What if the developer isn’t working out?
You say so, early, and we replace them. Structured vetting makes this rare — but a guarantee you never need is still worth having in writing. We also run our own monthly check-ins during the first quarter of every engagement, because the earliest signals of a mismatch usually show up in process friction before they ever show up in the code.
Do you test for AI-assisted coding?
We allow it in the build exercise, because your team uses it too. Stage 3 is the control: you can generate code with a tool, but you cannot defend decisions you didn’t make.
If you want engineers who were tested on the job instead of the whiteboard, schedule a call and we will show you the rubric we’d use for your stack.
Finding this analysis useful?
Get one email a week with the most important developments in AI and business technology — explained in plain English, with real numbers and zero spam.
Want this working in your business?
Book a free 30-minute session: we look at your case and tell you what is worth doing (and what is not) — no strings, no sales pitch.
Book a free session →