How to vet a software developer before they touch your code

Most hiring processes are very good at one thing: finding people who interview well.

Résumés reward good writers. Algorithm puzzles reward people who practiced algorithm puzzles. Culture-fit chats reward charm. None of them tells you whether someone will ship working software in your codebase, on your timeline, while telling you the truth about how it is going.

We vet developers for a living, and we still do not trust interviews on their own. Here is the process we use, in four gates, and how to run a version of it yourself.

Gate 1: Screening for proof, not keywords

The goal of screening is to find verifiable production experience, not a matching list of technologies.

What to look for:

• Shipped products you can see. A live app, a public repo with real history, a case study with specifics. “Worked on a fintech platform” is not proof. “Built the payout reconciliation job for X” is closer.
• Ownership language. “I built,” “I owned,” “I migrated.” Compare with “was involved in” and “contributed to.”
• Stack depth over stack breadth. Someone who lists 30 technologies has usually used most of them once.

Most applicants stop here. That is the point. Every later gate is expensive, so the first one should be strict.

Gate 2: A live technical session

Give the candidate a realistic problem from their specialty and watch them work through it live. For designers, have them walk through a portfolio piece and the decisions behind it.

A few rules that make this gate much more useful:

• Let them use their normal tools, AI included. You are hiring someone to work with Cursor or Copilot, so test that. We allow AI tools in our live sessions and evaluate whether the person understands what ships. There is more on this in how to hire a Cursor developer.
• Use real problems, not trivia. Adding a feature to a small existing codebase beats reversing a linked list.
• Ask them to explain. “Why this approach? What would break it? What would you do with another day?”
• Change a requirement halfway. How someone handles a shifting spec tells you more than how they handle a fixed one.

What you are looking for: clear thinking, honest uncertainty (“I’m not sure, let me check”), and whether they test their own work before calling it done.

Gate 3: References and communication

Technical skill is half the job. The other half is clear updates, reliability across time zones, and ownership when something goes wrong.

References are the best way to check this, if you ask questions that get honest answers. Skip “Were they good?” Everyone says yes. Try:

• “Would you hire them again for the same role?” Listen for hesitation.
• “What did you have to manage them on?” Everyone needs managing on something. “Nothing” is not believable.
• “How did they tell you when something was going to be late?”
• “What kind of project would you not put them on?”

Also pay attention to your own experience so far. How fast did they reply? Were their messages clear? Did they show up on time? The hiring process is a preview of the working relationship.

Gate 4: A paid trial week

This is the gate that matters most, and the one most companies skip.

Before a full commitment, the candidate works a scoped task for about a week: either a real task from your backlog or a representative brief. You see real output, not interview performance.

How to run a good trial:

1. Sign an NDA first, then grant only the access the task needs.
2. Pick a real, self-contained task. Something that would take a strong developer three to five days. Not a toy, not your hardest problem.
3. Define “done” in writing. Merged, tested, deployed to staging, whatever applies.
4. Pay for it. Always.

What to watch during the week:

• Questions in the first day. Good developers ask clarifying questions early instead of guessing.
• Pull request size and clarity. Small, well-described changes are a sign of a careful developer.
• Communication without prompting. Did you hear about blockers, or discover them on Friday?
• The result. Does it work? Is it tested? Would you want to maintain it?

A trial week will occasionally show you that a strong interviewer is a weak collaborator. That is exactly what it is for. Finding out now costs one week. Finding out in month three costs a lot more.

What skipping vetting actually costs

A bad hire costs more than their salary. You lose the weeks it took to hire them, the weeks before you admitted it was not working, the time your team spent reviewing and fixing their code, and the weeks to replace them. Meanwhile the product did not ship.

Compared with that, a week of paid trial is cheap.

How we do it at Hiring.co

Every developer and designer we place passes all four gates: screening, a live technical or portfolio review, a reference check, and a paid trial week on a real task. We do not publish an acceptance percentage. Candidates who do not clear all four are not placed.

Then we stand behind the result. If a hire does not perform to the standard we promised, we replace them at no extra cost. Chloe Reynolds stays on the account and checks in on output, so a problem surfaces while it is still small.

You can read the full vetting process, browse vetted developer profiles, or book a call and tell us what you need built.