The Two-Week Paid Trial: How We Actually Evaluate Senior Engineers Before an Offer

Every agency has a story about the senior hire who aced the interview and then couldn't ship a feature without three PRs of hand-holding. We've had that story more than once. After enough of them, we stopped trusting interviews and started paying candidates to work with us for two weeks before either side commits.

This isn't a hot take about how take-homes are broken — that argument has been done. This is the actual mechanics: what the trial looks like, what we pay, what we measure, and where it's gone wrong.

Why interviews keep failing us

Agency work is a specific animal. On any given Tuesday a senior engineer needs to jump into a client's ten-year-old Rails monolith, negotiate scope with a non-technical stakeholder over Slack, review a mid-level's PR on a Next.js project, and remember which of four clients uses trunk-based deployment. A four-hour interview loop tells us almost none of that.

What interviews are good at: filtering out people who can't code at all, and detecting obvious communication red flags. What they're bad at:

• How someone behaves when a ticket is ambiguous
• Whether they ask questions or invent requirements
• How they respond to code review — giving and receiving
• Whether they can context-switch between stacks without breaking
• What their instinct is when a client changes the spec mid-sprint

All of those are the actual job. So we started measuring them directly.

The shape of the trial

A candidate who passes the first two conversations — a screening call and a technical chat — is invited to a paid two-week engagement. Not a take-home. Not a "contribute to our open source repo." A real, scoped piece of work on a real project, with a real slack channel and a real standup.

The terms we offer:

• Duration: 10 working days, part-time acceptable (minimum 4 hours/day)
• Rate: Their expected contractor rate, or 60–70% of it if they're currently employed and moonlighting
• Scope: A pre-defined slice of work, roughly 3–5 tickets, with clear acceptance criteria
• Exit: Either side can end it after day 5 with full payment for time worked
• Outcome: At day 10, we either make an offer (permanent or ongoing contract) or we don't, and they keep whatever they shipped as portfolio evidence

Candidates almost never say no to this. When they do, it's usually a signal — either they're already deep in another process, or they don't want to be evaluated on real work. Both are useful information.

What we pick as the work

The trial ticket set has to be honest. If we hand someone a greenfield side project while the actual job is untangling a client's legacy PHP, we've learned nothing. We pick from three buckets:

1. A real client project, with the client's consent and an NDA. This is the best signal but hardest to arrange.
2. Internal tooling — our own admin dashboards, deployment scripts, or the CMS behind our marketing site. Realistic, messy, has actual users.
3. A recovery ticket set — bugs and small features from a project that shipped 6+ months ago, running in a maintenance branch.

We avoid: pure algorithm puzzles, "design our next product," and anything with no existing code to read.

The scoring rubric

Here's roughly what we track. It lives in a shared Notion doc that the hiring manager and one other engineer both fill in independently.

trial_evaluation:
  shipping:
    tickets_completed: 0-5
    quality_of_completion: 1-5  # did it actually work, edge cases?
    time_to_first_pr: hours
  communication:
    asked_clarifying_questions: 1-5
    standup_clarity: 1-5
    written_updates: 1-5  # slack, PR descriptions
    handled_disagreement: 1-5
  code:
    readability: 1-5
    fit_with_existing_style: 1-5
    test_coverage_instinct: 1-5
    pr_size_discipline: 1-5
  autonomy:
    unblocked_self: 1-5
    knew_when_to_ask: 1-5  # inverse of the above, both matter
    ownership_beyond_ticket: 1-5
  red_flags:
    - list any specific incidents

The numbers are less important than the conversation they force. Two evaluators comparing rubrics catches things one person misses. In our experience, the knew_when_to_ask score is the single strongest predictor of whether someone will thrive in an agency context. Engineers who go silent for two days then submit a 900-line PR are a liability no matter how good the code is.

The one metric that isn't on the rubric

Do other people on the team want to work with this person again? We ask everyone who interacted with the candidate — designers, PMs, junior devs — a single question at the end: "Would you be happy to be on their next project?" A hesitant yes is a no.

The war stories

We've run this process maybe forty times over the last few years. Some patterns:

The staff engineer who couldn't finish anything. Brilliant on paper, great in interviews, could talk architecture for hours. During the trial, shipped one ticket in ten days and spent the rest rewriting our ESLint config. We didn't extend an offer. He was probably a great fit for a research role somewhere; not for us.

The mid-level who scored like a senior. Applied for a senior role, and on the rubric came in below our senior bar. But her communication and autonomy scores were exceptional. We offered her a mid-level role with a 12-month path to senior. She accepted, and she's now leading a client team.

The candidate who caught our own bug. On day three, he opened an issue against our internal tool pointing out an auth flaw that had been sitting there for months. That's the ownership signal. Offer extended day six.

The one that hurt. A candidate we really liked bailed on day four because a competing offer came in with a signing bonus. We paid him for four days and moved on. This will happen. Budget for it.

The economics

A trial costs us real money. At senior contractor rates, ten days is somewhere between $6,000 and $12,000 depending on the market. If we don't offer, that's a sunk cost.

But compare it to the alternative: a bad senior hire costs three to six months of salary, project delays, team morale, and often a client relationship. We've done that maths and it's not close. One avoided mis-hire pays for eight or nine trials.

The other economic wrinkle: the work they produce during the trial has value. Even the candidates we don't hire usually ship two or three tickets we would've paid someone else to do. It's not free labour — they're paid at market rate — but the output isn't wasted.

Where this doesn't work

Be honest about the limits:

• Candidates in stable senior roles often can't take two weeks off, even part-time. We've lost people to this. Sometimes we compress to one week or offer weekend-heavy schedules, but the signal degrades.
• Junior hires don't need this. A well-designed take-home and pairing session is plenty, and juniors can't realistically self-direct on a real codebase in ten days.
• Highly specialised roles — a staff ML engineer, say — may need a different process because the work is harder to scope into a trial slice.
• Regulated markets. Depending on your jurisdiction, paying someone for two weeks without a formal contract can create employment classification issues. Get your lawyer to draft a proper short-term contractor agreement. We use one that explicitly disclaims employment and IP-assigns anything they build.

Where we'd start

If you're an agency owner reading this and your last three senior hires haven't worked out, don't add another interview stage. Add a trial stage and cut something else. Specifically:

1. Pick one open senior role you're currently hiring for.
2. Write a ten-day scope from a real project — three to five tickets, clear acceptance criteria, realistic mess.
3. Draft a short contractor agreement with your lawyer (one page is fine).
4. Offer the trial to the next candidate who clears your first two rounds instead of a final panel.
5. Score them with two evaluators using a rubric like the one above.

You'll learn more in the first trial than in the last five interview loops combined. And if you want to talk through how we've folded this into a broader engineering hiring process, we're happy to compare notes.