How to Vet a Developer You'll Never Meet in Person

Anyone can pass a 45-minute interview. That's exactly the problem.

You're hiring someone you'll never share an office with — maybe never meet in person at all. All you get is a resume, a video call, and a gut feeling. And the interview, the one tool everyone leans on, is the one most likely to lie to you. Here's how we actually vet engineers when that's all you have to work with — from a team that's placed dedicated engineers this way for 7+ years.

Why Interviews Lie

An interview measures how good someone is at interviewing. That's a real skill. It's just not the skill you're paying for.

The candidate who rehearses answers to "tell me about a hard bug," who's memorized the fifteen algorithm questions everyone asks, who's warm and articulate on a call — that person can be a genuinely great engineer, or a genuinely mediocre one who's great at this. The interview can't tell the difference. It rewards performance under a spotlight nobody ever actually works under.

The real job looks nothing like that. Real work is deciding what to build when the ticket is vague. It's reading a codebase you didn't write and not making it worse. It's saying "this'll bite us in six months" before it does. None of that shows up in a whiteboard round.

So we mostly stopped trusting interviews. Not because they're useless — because they're the weakest signal we have, and everyone treats them as the strongest.

The Short Answer

The signals that actually predict a good remote hire aren't the ones interviews measure. They're these:

• Shipped work, not trivia. What have they built that survived contact with real users? Show me the messy, maintained, real thing — not the tutorial repo.
• Decisions under ambiguity. Hand them an underspecified problem and watch what they do. Do they ask the right questions, or just start typing?
• A real code review — both directions. Can they read code and find the risk? Can they take feedback on their own without getting defensive?
• Behavior over time, not behavior for an hour. Nothing beats watching someone work for two weeks. It's the only test the candidate can't cram for.

The rest of this is how we run each one — and the honest proof we put behind it.

The Vetting Playbook We Actually Use

1. Shipped work over trivia

The first thing we look at isn't a quiz score. It's what they've shipped — and, more importantly, what happened to it after they shipped it.

Anyone can build something that demos well on a Friday. We want the thing that's been in production for two years, that other people had to maintain, that broke at 2am and got fixed. We ask: what would you build differently now? A good engineer always has an answer — because a good engineer keeps arguing with their own past decisions. The one who says "I'd change nothing" hasn't looked hard enough.

2. Decisions under ambiguity

Then we deliberately give them a problem that isn't fully specified. Not a trick — a realistic one, the kind of half-formed request a founder actually sends on a Tuesday.

What we're watching for isn't the answer. It's the approach. Do they surface the assumptions hiding in the request? Do they ask what the user actually needs before choosing a tool? Do they flag the tradeoff they're making instead of quietly making it for you? Judgment is the thing you can't teach in onboarding, and ambiguity is the only place it shows.

3. A real code review, in both directions

We do two code reviews, and the second one matters more than the first.

First, we hand them real code with real problems buried in it and ask what they'd change. This tells us whether they can read — spot the race condition, the missing test, the abstraction that'll rot. Plenty of people who write fine code can't read it, and reading is 80% of the job on an existing product.

Then we review their code, live, and push back. Not to be harsh — to see how they hold a disagreement. The engineer who defends every line is going to be exhausting on your team. The one who says "good catch, here's why I did it, but you're right" is the one you want in your codebase for the next two years.

4. A paid, embedded trial — not a take-home into the void

Everything above sharpens the odds. None of it beats watching someone actually work.

So the final filter isn't a test at all. It's real, paid work on a real project, embedded with a team — where the only thing being measured is how they actually operate day to day. Communication, follow-through, how they handle being stuck, whether they say "I don't know" when they don't. You cannot fake two weeks. That's the whole point.

Our 2-Week Embedded Trial — the Honest Proof

Here's where I stop describing vetting in the abstract and tell you what we actually do, because a playbook you can't verify is just a nice paragraph.

Every engineer we place is vetted before you meet them. By the time a dedicated engineer shows up on your call, they've already been through the shipped-work review, the ambiguity problem, and the code review — internally, on our side, so you're not spending your first two weeks doing our job for us.

Then there's the 2-week embedded trial. The engineer works inside your team, on your real backlog, and you decide at the end whether it's a fit. Not a demo. Not a sales pitch with a friendly account manager. The actual person, doing the actual work, where the only thing that matters is what you see with your own eyes.

The proof this works isn't a testimonial — it's the number: 80%+ of our engagements are still running long after that trial ends. When you vet for behavior instead of interview performance, people stay. That's also why we run dedicated engineers rather than a rotating pool — you can't build trust with a name that changes every month. And it's why our offshore model out of India leans on 4–6 hours of real timezone overlap: the trial only means something if you can actually watch the work happen.

Red Flags to Walk Away From

Some signals are worth more as warnings than the whole rest of the process combined. Walk away when you see:

• A perfect interview and nothing shipped to back it up. Polish with no production scars is a tell, not a credential.
• No pushback, ever. An engineer who agrees with everything you say will happily build the wrong thing on schedule. You want someone who'll tell you no — that's the whole value.
• Defensiveness in code review. How someone takes feedback in week one is how they'll take it for two years. Multiply accordingly.
• A rotating cast instead of a named person. If a vendor won't tell you exactly who you're getting — or reserves the right to swap them out — you're not hiring an engineer, you're renting a seat.
• A "yes" to every timeline. Real engineers give you a range and the risks behind it. "Sure, no problem" to everything means they haven't thought about it yet.

Want to Skip the Guesswork?

If you'd rather not build a vetting process from scratch — and you shouldn't have to — that's the part we handle before you ever get on a call. Tell us what you're building and we'll match you with a dedicated engineer, vetted the way I just described, on a 2-week embedded trial. If it's not a fit, you walk. No commitment, no sales pitch.

Book a Call or see how our dedicated developers work.

Related reading: How to Hire Developers for Your Startup Without Getting Burned | The Honest Guide to Offshore Development in India | What Is IT Staff Augmentation? An Honest Guide