The Vetting Framework: How to Verify a Developer's Real Experience

What you actually need to know

• A developer's resume tells you what they claim. A two week paid trial tells you what they can actually do. The gap between those two things is where most bad hires live.
• Verification does not require technical knowledge. It requires the right questions and a willingness to make two phone calls.
• The three most reliable signals are: a live walk-through of their own code, a reference call where you ask if they would hire them again, and how they handle a mid-project surprise.
• Experienced developers welcome scrutiny. Unqualified ones avoid it or redirect to credentials.
• Most founders skip verification because they feel awkward. The awkwardness costs six to twelve months of runway when the hire turns out wrong.

The core argument

Most non-technical founders treat hiring a developer like hiring an accountant. You look at credentials, you check a reference, you pick someone. That works for professions where output is standardized. Software is not standardized. Two developers with the same resume line can produce work that is orders of magnitude apart in quality, reliability, and maintainability. The credential gap is real and visible. The skill gap is hidden until something breaks.

The reason verification matters more for developers than for most hires is the time-delay between hiring and consequence. If you hire a bad accountant, you find out at tax time. If you hire a bad developer, you find out six months after launch when the codebase is so tangled that nothing new can be added without breaking three things. By then you have paid the developer, built on their foundation, and have a product that your next developer will spend weeks untangling before they can add value.

The framework I use is three steps, in order. First, a screening call where I ask questions that require specific answers. Second, a portfolio verification where I ask them to show me the work live on a screen share. Third, a paid two week trial on a real slice of the actual project. Each step is a filter. Most bad hires are caught by the first or second step. The trial catches the ones who present well but work slowly or communicate poorly.

References belong after the screen share and before the trial. They cost ten minutes. The right three questions reveal information that no resume or portfolio will surface, particularly what the person was like to work with under pressure.

The three step framework

Step one: the screening call

The questions are designed to require specificity. Not "have you worked with React?" but "walk me through a React project where you had to make a performance decision under time pressure." A developer who has actually shipped that kind of work will describe the tradeoff, name the constraint, and tell you the outcome. A developer who has only done tutorials will generalize.

Ask about failures. The most revealing question in a screening call is "what is a technical decision you made in the last two years that you regret?" Senior engineers have a specific answer within thirty seconds. They name the decision, explain the context, describe the consequence, and tell you what they learned. Anyone who says they cannot think of one has either not shipped enough to have failures, or is unwilling to be honest. Both are signals.

Step two: portfolio verification

Ask them to share their screen. Navigate to a repository they built. Ask them to explain the folder structure, point to the part they are most proud of, and describe one decision they made that is not obvious from reading the code. Someone who built the thing can do this naturally. The screen share takes twenty minutes and eliminates a significant fraction of inflated portfolios.

Step three: the paid trial

Two weeks. A real slice of your actual project. Not a toy problem, not a whiteboard exercise. Pay them for the two weeks regardless of outcome. You are not testing them, you are working with them. The trial tells you how they communicate when they hit a blocker, how accurately they estimate, and whether their output is clean enough for the next person to maintain.

How much does it cost

The trial cost is the relevant number. At a mid range independent rate, two weeks of work lands between two and five thousand dollars. That is the price of the information you need to make a six to twelve month commitment. Skipping it to save three thousand dollars is how founders spend forty thousand dollars on the wrong developer.

What to look for in the verification process

• Specific language. "I used Redis to cache session data because database reads were adding 200ms to every page load" beats "I am experienced with caching."
• A willingness to name limitations. Developers who tell you what they will not work on are more trustworthy than developers who say yes to everything.
• Consistent commit history across multiple repositories, not one polished portfolio project.
• References who answer "would you hire them again" with a yes that takes less than three seconds. A long pause before yes is a soft no.
• Communication during the trial that surfaces blockers early, not on deadline day.
• A handover document at the end of the trial that another developer could pick up from. If they cannot summarize what they built, they cannot maintain it.

Expert opinion

The founders who hire well are the ones who treat verification as a product sprint, not a compliance exercise. Two weeks of paid trial work costs less than two weeks of developer time correcting a mistake that crept into the codebase because the first hire was never properly verified. I have never heard a founder say they wished they had skipped the trial. I have heard dozens say they wished they had run one.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A founder came to me after spending four months and roughly thirty thousand dollars with a developer who had a polished portfolio and declined to do a trial. The work that developer shipped was real, but the codebase had no tests, the deployment was manual, and the database schema had no migrations, meaning any change required manually editing production. The developer had presented well. They had simply shipped work that was optimized for their own speed, not for the next person's maintainability.

The three step framework would have caught this. The screen share would have surfaced the absence of tests in the first conversation. The reference call would have revealed that the previous client had the same experience. The trial would have confirmed the pattern before any significant commitment was made. When I work with founders on their hiring questions process, the verification framework is always the second conversation, because the questions and the verification are different muscles and both need to be exercised.

The projects where this has gone best are the ones where the founder treats the trial as the beginning of the relationship, not a test to pass or fail. The developer who builds something useful in two weeks, communicates clearly, and hands over a document explaining what they did is almost always the developer you want on the longer engagement. For more on how to set up that engagement, why some developers cost three times more covers how to calibrate the rate against the risk.

Common mistakes

1. Skipping the screen share because it feels confrontational. It is not confrontational. Any developer who builds real work expects and welcomes it.
2. Treating reference calls as a formality. Call them. Ask the three questions. The answers matter.
3. Running an unpaid test instead of a paid trial. Unpaid tests filter out experienced candidates and reward people who are good at tests, not at building.
4. Evaluating only the code and not the communication during the trial. How a developer handles a blocked day is a better signal than the code they write on a smooth day.
5. Accepting a portfolio without verifying which parts they actually built. Group project work, open source contributions, and agency work where the code was reviewed by a lead are all different from solo production work.
6. Hiring based on credential alone. A computer science degree from a good university is a positive signal and a very weak predictor of practical output.
7. Not giving the developer a chance to ask questions during the screening. The questions a developer asks about your project reveal their depth faster than any answer they give.
8. Ending the trial without a debrief. Sit with the developer for thirty minutes after the trial ends and ask what surprised them. The answer is one of the most useful things you will hear before signing.

A 30 day plan

1. Days one to three. Write the screening questions before you talk to anyone. The questions should require specific answers. Test them on a developer friend if you have one.
2. Days four to ten. Run three to five screening calls. After each one, score the specificity of the answers. You are not grading on technical depth. You are grading on honesty and precision.
3. Days ten to fourteen. For the top two candidates, run the screen share portfolio review. Ask the same questions to both. Compare.
4. Days fifteen to sixteen. Call two references per candidate. Three questions each. Write down the answers immediately.
5. Days seventeen to thirty. Run a paid two week trial with the top candidate. Clear scope, daily standups, a Friday demo, and a written handover at the end.

For more on what to ask before the trial starts, the ten questions every non-technical founder must ask covers the conversation that sets up everything that follows. And if the developer you are evaluating is part of a larger team or agency, agencies that win founder trust covers the habits that separate the ones worth hiring from the ones that only look good in a proposal.