How to Evaluate a Senior Backend Contractor With a Paid Pilot
Interviews show conversation. A paid pilot shows whether someone can work in your repository. Ten days is enough to see that, and too short to prove they should own the domain forever.
Whiteboard interviews and algorithm drills answer a question most product companies are not actually asking: can this person solve puzzles under observation. They do not answer whether the person can find the real bottleneck in a messy service, write a change that your team will merge, and explain the trade-off in Slack without starting a religious war.
A paid pilot is the evaluation that matches the job. You pay for days. They work in the real repository. You look at the output the way you would look at a colleague’s. That is also why a 10-day paid backend engineering pilot is a commercial offer rather than a metaphor: ten working days is long enough to ship something that exists, and short enough that a bad fit is a bounded invoice rather than a six-month SOW.
It is not a guarantee that the person is the right owner of the system for three years. Do not pretend otherwise.
What interviews miss
Interviews reward people who are practised at interviews. Seniors who have spent the last five years in production sometimes interview worse than people who interview for a living. You also cannot see:
- how they behave when the ticket is wrong
- whether they ask for logs before proposing a rewrite
- whether their PR is reviewable
- whether they disappear when the problem is political rather than technical
- whether they can work with incomplete information without manufacturing certainty
A take-home that is unrelated to your stack has the same problem as LeetCode: it is a different sport.
Design a pilot around real work
Pick a problem that is already on the backlog, that would have been done by a senior internally, and that is bounded enough to finish or to reach a clear checkpoint in ten days. Production-relevant does not mean “touch billing on day one.” It means the code path is real: a worker, an endpoint, a failing test suite, a migration that staging already needs.
Give them the same tools a new teammate would get: repo access, staging, the runbook that exists, a named counterpart. If your onboarding cannot do that in two days, the pilot will measure onboarding, not the contractor. Fix that first, whether you hire contractor versus full-time or not.
Real repository
No greenfield demo app. No “rebuild this in Go over the weekend.” The value is friction with your code: the surprising foreign keys, the dead feature flags, the CI job that fails on Tuesdays.
Bounded production-relevant problem
Examples that usually work: reduce p95 on one endpoint with evidence; add a missing index and the code that stops the N+1; extract a pure function with tests from a god class; make a worker retry-safe; write the decision record for a queue choice the team has been arguing about, then implement the first slice.
Examples that do not: “improve the architecture”; “help us with PHP”; “see what you think of the system.” Those are not pilots. Those are unpaid consulting with extra steps.
Code review
Require a pull request. Review it as you would an internal senior’s. Look at the diff size, the tests, the commit messages, whether they asked for a review early. A brilliant local branch that never becomes a PR is not delivery.
Architecture reasoning
Have one conversation in the first three days about the shape of the change, in writing afterwards. You are listening for whether they reached for a rewrite, whether they named rollback, and whether they noticed the operational constraint you forgot to mention.
Communication
Daily written notes: what moved, what is blocked, what is unsafe to touch. Silence is a signal. So is a wall of unsolicited architecture essays with no diff.
Testing and documentation
If they ship a behaviour change without a test in a codebase that has tests, that is information. If the codebase has no tests, do not score them for not inventing a suite in ten days. Scoring must match the ground.
Incomplete information
Leave one requirement slightly wrong on purpose, or omit a consumer of the API. Seniors ask. People performing seniority guess and write a lot.
Working with the existing team
Introduce them to the person who will review the PR. A contractor who cannot take review from your mid-level engineer is a contractor versus agency problem in miniature: you will be stuck with a hero, not a teammate.
What a 10-day pilot cannot tell you
- Whether they should own the domain for years
- How they behave in a six-month grind of unglamorous tickets
- People-management skill
- Whether they will still be motivated after the interesting problem is gone
- Security posture against a determined attacker
- How they handle a Sev-1 at 02:00 unless that is explicitly in scope and staffed
Ten days also cannot repair a team that does not want an outsider. If the pilot is sabotaged by access delays or by ignoring their PRs, you have evaluated your organisation, not them.
Sample scorecard
Score 1–5. Require written comments on anything below 3. Do not average a 5 on code with a 1 on communication into a “hire.”
| Signal | What 5 looks like | What 1 looks like |
|---|---|---|
| Problem selection | Clarified scope on day one, pushed back on a rewrite | Accepted a vague ticket and vanished into a branch |
| Evidence | Profiler, EXPLAIN, logs, or a failing test before the fix |
Opinion-first, measurement never |
| Diff quality | Reviewable slices, tests where the repo has tests | 2,000-line PR, no tests, “will clean up later” |
| Rollback | Named how to undo or feature-flag | Forward-only courage |
| Communication | Daily notes the counterpart actually reads | Status by telepathy |
| Collaboration | Used review; did not bypass the team | “Just merge it, I know this pattern” |
| Knowledge left behind | Decision note or runbook update | Only they understand the change |
| Time use | Ten days produced a checkpoint you could ship or demo | Ten days of exploration, no artefact |
A passing pilot is not a perfect score. It is “we would let this person continue on this codebase next week.”
Access and setup before day one
The pilot measures the contractor only if the environment is ready. Agree in writing, before the first day: repository access, staging, the CI badge that is allowed to be red, a named counterpart who can answer domain questions the same day, and the ticket that is in scope. If a laptop, VPN or SSO request takes a week, start the ten-day clock after that is done, not on the contract signature.
Do not hide the messy parts. A sanitized demo branch is an interview in disguise. The value is friction with the real foreign keys, the flaky job, and the review culture your team actually has.
Pay the day rate for the pilot. Unpaid “trials” select for people who can afford to work for free, not for people who can own a service. Ten days at a senior rate is a bounded invoice. It is not a hostage situation and it is not a guarantee.
After the ten days
Decide in writing: stop, continue at an agreed cadence, or continue while a permanent hire process runs in parallel. If you need two days a week rather than five, that is a fractional backend engineer conversation, not a failed pilot.
If you want that evaluation on real PHP or Go work, the commercial form is already the 10-day paid backend engineering pilot: €400/day, B2B, EUR, CET/CEST overlap, real repository, stop or continue when the ten days are done. That is the lowest-risk way I can show you the work instead of another interview loop.