Every technical interview process has the same problem: it measures how someone performs in a technical interview.
That is not nothing. It correlates with something. But if you have ever hired someone who interviewed brilliantly and then struggled for six months, or passed on someone who fumbled a whiteboard and later turned out to be excellent elsewhere, you already know the correlation is weaker than the process's confidence suggests.
For external engineers — a dedicated team, a contractor, an agency placement — you have an option that direct hiring rarely offers: a paid trial period on your actual codebase, before you commit to a longer term. It is the single highest-signal screening mechanism available and most buyers either skip it or run it badly.
Here is how to run it properly.
Length: two to four weeks
Shorter than two weeks and you are measuring onboarding speed, not working style. The first week is mostly environment setup, codebase orientation and figuring out who to ask about what — legitimate signal, but not the signal you need.
Longer than four weeks and you have committed anyway, in practice if not on paper. You will have built roadmap dependency on the arrangement and the sunk-cost pressure will distort your judgement.
Three weeks is usually right. Pay full rate. A discounted trial invites a discounted effort and, more importantly, changes the relationship into something adversarial before it has started.
The task: real, ambiguous, non-critical
This is where most trials fail, and the failure is always in the same direction — the task is too clean.
Do not give them a toy problem. A standalone exercise measures whether they can solve a standalone exercise. Your actual work involves an existing codebase with existing conventions, some of which are bad, several of which are undocumented.
Do not give them something critical. The trial should be able to fail without anybody's quarter being damaged. If it cannot fail safely, you will unconsciously smooth their path and destroy the signal.
Do give them something ambiguous. This is the important part. The task should have at least one decision point where the correct answer is not written down anywhere — where the requirement as stated is incomplete, or two reasonable interpretations exist.
Good candidate tasks:
- A feature request written the way your stakeholders actually write them, which is to say incompletely
- A bug that reproduces intermittently and requires reading unfamiliar code to locate
- An integration with a real third-party dependency, including its undocumented behaviour
- A refactor with a clear goal and no prescribed approach
Bad candidate tasks:
- Anything fully specified down to the function signature
- Anything isolated from the rest of the system
- Anything you have already solved and are comparing their answer against
What to watch
Technical skill is the least interesting thing you will learn, because it is the thing your interview already screened for reasonably well. Watch four other things.
Ambiguity handling. When they hit the underspecified part, what happens? The good pattern is a question early, framed with a proposed answer: "The spec doesn't say what happens on partial failure — I'm assuming we retry twice then dead-letter, does that match?" The bad pattern is silence followed by a surprise at the end. The worst pattern is silence followed by a large, confidently-built implementation of the wrong interpretation.
Code review engagement. Leave substantive review comments, including at least one you are not certain about. Do they push back with reasoning? Do they accept everything without discussion? An engineer who never disagrees during review will never disagree about architecture either, and you are buying judgement, not compliance.
Communication cadence. Do you know what they are working on without asking? Is a blocker surfaced within hours or discovered at standup the next day? This is almost entirely a habit, and habits do not change after the trial.
Response to being wrong. Give them a chance to be wrong about something — it will happen naturally. Watch closely. This is, in my experience, the single most predictive signal for a long engagement, and it is invisible in every other screening step.
Structuring the feedback loop
The trial tests your process as much as theirs, and this is a feature.
Commit to a review turnaround — under four hours during overlap. If you cannot manage that for one trial engineer, you will not manage it for four permanent ones, and you have learned something valuable about whether you are ready for this model at all.
Have one named person who owns their questions. Not a rotation, not a channel. A person.
Do a short mid-trial check-in — twenty minutes at the halfway point. Not a performance review; a calibration. Here is what is going well, here is one thing I would like to see differently. How they respond to that adjustment tells you more than the remaining week of output will.
The decision
At the end, the question is not "was the work good?" It is: would I want this person to own a meaningful area of this system for the next year?
Those are different questions and the second is the one that matters. Good work from someone you have to chase, who never disagrees, and who surfaces blockers late is a worse long-term outcome than adequate work from someone who is easy to work with and gets better.
And if the answer is no, say so directly and pay for the work. The industry is smaller than it looks, and a clean no is remembered better than a drawn-out maybe.
Full guide to the model — costs, contract terms, vetting a vendor's bench, onboarding and measurement: Hire Dedicated Developers in 2026. We also help teams structure these engagements when the stakes justify getting it right first time.
Frequently Asked Questions
Should a trial be paid?
Always, at full rate. A discounted or unpaid trial invites reduced effort, filters out the people with options, and starts the relationship on an adversarial footing. The cost of three weeks of billing is trivial against the cost of discovering a mismatch in month four.
What if the vendor refuses to let me interview or trial specific engineers?
Treat it as a serious signal. The most common failure in this industry is a strong engineer on the sales call and a different one on the project. A partner confident in their bench will not object to you meeting and trialling the named individuals.
Is two weeks long enough?
Marginally. The first week is largely orientation, so a two-week trial gives you roughly one week of representative signal. Three weeks is the sweet spot; beyond four you have committed in practice regardless of what the contract says.
What is the strongest single signal to watch for?
How they respond to being wrong. It predicts long engagements better than technical depth, and it is invisible in interviews because interviews rarely create genuine opportunities to be wrong in front of someone.
Should I compare their solution to one I already have?
No — that turns the trial into an exam with a known answer and tells you nothing about how they handle genuine ambiguity. Give them something you have not solved, with a decision point that is not written down anywhere.
What if the trial reveals problems in my own process?
That is one of the most useful outcomes available. If you cannot turn around code review in a day for one engineer, you are not ready to add four — and finding that out during a three-week trial is far cheaper than finding it out in month three.
Top comments (0)