How to Vet Staff Augmentation Developers: A Client-Side Vetting Process

Who vets what: you and the vendor

In a staff augmentation deal, vetting happens twice. The vendor screens people before hiring them and again before presenting them to you. Then you decide whether a particular person fits your team. Problems start when either side assumes the other did the work. Clients skip the technical interview because "they're pre-vetted"; vendors send borderline candidates because "the client will interview anyway".

A sensible split: the vendor guarantees general competence, English, reliability and background checks. You test fit: your stack and its versions, your kind of problems, your communication style, your time zone needs. Your funnel can be short if the vendor's is good, so start by checking the vendor's.

What to ask the vendor about its own vetting

If the vendor's answers are strong, your own funnel can be the light version below. If they're weak, either add stages or pick another vendor. Our staff augmentation RFP guide turns these questions into a written request, and the list of IT staff augmentation companies is a starting point for a shortlist.

The client-side funnel at a glance

Here's what a healthy funnel looks like for one hire when the vendor does its part. The numbers are typical of what we see; a hard-to-fill stack (senior iOS, ML engineering, niche frameworks) widens the top.

Stage 1: the profile screen

Write a one-page role brief before you ask for profiles: the work for the first three months, the stack with versions, must-haves (three at most), nice-to-haves, overlap hours and seniority. A vague brief produces a pile of generic CVs and a long funnel.

Then spend five minutes per profile on these checks:

• The candidate's own role on each project. "Built the payment module in NestJS" beats "worked on a fintech platform". If every line is about the product and none is about them, ask in the interview.
• Depth over breadth. A mid-level CV listing 25 technologies is a keyword list. Look for two or three areas with years of real use.
• Recent hands-on work in your stack within the last 18 months. Frameworks move; React from 2019 isn't React in 2026.
• Tenure patterns. Several three-month stints in a row deserve a question. Long engagements with one client are a good sign for augmentation, where continuity matters.
• Similar problems, not similar industries. Someone who built offline sync for a logistics app can probably do it for a healthcare app.

Watch for profiles that look identical in structure and phrasing across candidates. That usually means the vendor rewrote them, which is fine for formatting but not for content. Ask for the engineer's own original CV or LinkedIn profile if anything looks polished beyond recognition.

Stage 2: one technical interview that tells you enough

One well-designed interview of 60–75 minutes, run by the person who will review this engineer's code, tells you more than three generic ones. Have a second engineer join for calibration on the first few hires. A structure that works:

1. Context (5 minutes)Your product, the team, what the first months look like. Candidates answer better when they know what you're looking for.
2. Walkthrough of their past work (15 minutes)Ask them to explain a system they built: the architecture, a decision they'd reverse, a bug that took days. Follow-ups reveal depth quickly. People who did the work have opinions; people who watched it have summaries.
3. Practical exercise (25 minutes)A small piece of code close to your real codebase: find and fix a bug, extend a function with a test, or review a pull request with planted issues. Let them use their normal tools and narrate their thinking.
4. Design discussion (15 minutes, mid and senior)A simplified version of a real problem you've had. You're looking for questions about requirements before answers about technology.
5. Working style (10 minutes)How they handle an unclear ticket at the end of their day when you're asleep, how they respond to review feedback they disagree with, what they need from a team to do good work.
6. Their questions (5 minutes)Good candidates ask about the codebase, the release process and the team. No questions at all is a mild warning sign.

None of this means candidates shouldn't use AI at work. Most of your team probably does. What you want to know is whether the candidate understands the code when the assistant is off, and whether they can tell when its suggestion is wrong. Our article on AI in staff augmentation covers which skills to test for now.

Stage 3: a paid trial beats a long test task

The strongest signal is real work. You have three options, in order of preference:

During a trial, evaluate what you'd evaluate in month three, just scaled down: did they ask good questions early, are pull requests small and clean, do they respond to review feedback quickly, do they communicate blockers before they become delays? Time to first merged pull request is a fair benchmark; under five working days is healthy. We list more early signals in staff augmentation metrics.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Real estateModernizing a Multi-Service Real Estate Marketplace→FinTechAndroid application for FinTech industry→Pharmacy · DACHRedesigning and modernizing an Online Pharmacy mobile app→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Score every candidate the same way

Unstructured interviews produce decisions based on who was most likeable. A scorecard filled in right after each interview, before discussing with others, keeps you honest and makes it easy to compare candidates from different vendors. Use the one below as it is or adjust the criteria.

Stage 4: references that actually tell you something

Company references ("a US fintech was happy with us") say nothing about a particular person. Ask the vendor for one client reference for the specific engineer, from the last two years, and talk to the tech lead or engineering manager, not procurement. Fifteen minutes is enough if you ask about behavior:

• How long did it take them to work without close supervision?
• What did they own by the end? Who took it over when they left?
• How did they react to critical review comments?
• How did they handle the time zone difference: written updates, availability, blockers?
• Would you take them back on your team? If you hesitate, why?

The last question does most of the work. Listen for hesitation more than for the words.

Red flags, ranked by how much they should worry you

Vetting at speed without lowering the bar

Good augmented engineers get offers quickly. A process that takes four weeks loses the best candidate in week two. Some habits that keep the funnel to one or two weeks:

• Block interview slots for the coming week as soon as you send the request for profiles.
• Give the vendor feedback on every rejected profile within 24 hours. One sentence ("needs more backend depth") improves the next batch more than anything else.
• Decide within 48 hours after the last interview.
• Prepare the trial tickets and access before the trial starts, using the readiness list in how to manage staff augmentation.

If you're still deciding between augmentation and other models, our comparison of staff augmentation and traditional hiring sets out the trade-offs, and pros and cons of staff augmentation scores your situation.

FAQ

Where Gilzor fits

We'd rather you vet our engineers properly than take our word for it. Ask us the vendor questions from the table above before you share a role, and we'll answer them in specifics. Once you pick a candidate, development can start within two weeks of the agreement. See how team extension works or browse the stacks we cover on our tech stack page.