Think Build Implement Repeat
London, UK +44 7367 067226
WhatsApp FOLLOW f in X
  1. Home
  2. Blog
  3. Trialling a Developer Before a Long Engagement
Software Strategy

Trialling a Developer Before a Long Engagement

A two-week paid trial tells you more than any interview. How to design one that is fair, useful, and actually predicts the engagement.

Updated 2 min readBy SpiderHunts Technologies

Free estimateNo obligation

Get a free estimate

Tell us what you need. A senior engineer reads every enquiry.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →

Quick answer — TL;DR

A short paid trial on real work predicts an engagement far better than interviews. Design it around a genuine task with a clear finish, pay for it, and decide against criteria you wrote down before it started.

The short answer

Two weeks of real work, paid at the normal rate, on a task that matters but is not on the critical path. You learn how they handle your codebase, your review process and your ambiguity, none of which an interview reveals.

Write the criteria down before it starts. Deciding afterwards what you were looking for produces a judgement about whether you liked them.

Why interviews predict poorly here

An interview tests how someone performs in an interview. Augmentation asks something different: can they become useful inside an unfamiliar system, with incomplete documentation, while asking a reasonable number of questions.

  • Reading unfamiliar code is the core skill and is rarely tested
  • Knowing when to ask rather than guess is a judgement call
  • Working within existing conventions matters more than personal preference
  • Handling review feedback well is visible only in review

Designing the trial

  1. Pick genuine work with a clear definition of done, ideally two or three days of effort for someone who knows the system.
  2. Prepare it properly: context, acceptance criteria, where to look.
  3. Give the same onboarding you would give for a full engagement.
  4. Let them go through the whole process including review and deployment.
  5. Hold a short conversation at the end about what was unclear.

That last step is genuinely useful regardless of the decision. Someone seeing your process for the first time will point out friction your team stopped noticing.

What to judge

Look atGood signConcern
Questions askedSpecific, after lookingNone at all, or constant
First pull requestFollows existing conventionsPersonal style imposed
Response to feedbackAbsorbed and appliedRepeated, or argued at length
Handling ambiguityRaises it, proposes an answerGuesses silently, or stalls
CommunicationProactive about blockersSilence until asked

The ambiguity row is the most predictive. Every real engagement contains unclear requirements, and how someone handles the first one tells you how the next six months will go.

Pay for it

Unpaid trials get you people with no better options, and they are not a fair test because nobody does their best work for free. Pay the normal rate for real work you keep.

It also changes the relationship. A paid trial is the start of an engagement that you might not extend. An unpaid one is an audition, and people behave differently in auditions.

Be honest about what happens next

Say at the outset that it is a trial, what you are assessing, and when you will decide. Suppliers and developers both plan around availability, and being vague costs them real money.

If you decide not to continue, say why. It is a short conversation and it is the difference between a supplier who will work with you again and one who will not.

FAQ

Frequently asked questions

The questions readers ask us after this guide.

Still have a question?

Ask us directly — a senior engineer will get back to you.

Ask about your project

How long should a trial be?

Long enough to get through onboarding and a full piece of work, which is usually one to two weeks. Shorter than that mostly tests your onboarding.

Will suppliers agree to a trial?

Most will, particularly for a longer engagement. Some price it differently. Being clear that it is paid removes most of the objection.

Should the trial work be thrown away?

No. Use real work you intend to keep. Throwaway tasks are less motivating and less informative.

What if we like them but the timing is wrong?

Say so and keep in touch. Someone who has already onboarded is considerably cheaper to bring back than a new person.

Keep reading

More on Software Strategy

Software Strategy

Machine Learning Myths That Waste Budgets

Eight beliefs about machine learning that quietly inflate project costs, what is actually true instead, and how to spot each one in a proposal.

Start here

Thinking about adding developers to your team?

Tell us what you are building, what your team looks like now and where the gap is. We will come back with an honest view on whether augmentation fits, how many people it would take and what it costs. If hiring directly would serve you better, we will say so.

  1. You tell us what you needTwo minutes on the form, or a message on WhatsApp.
  2. A senior engineer reviews itAnd comes back with questions, a realistic range and an honest view on fit.
  3. Free 30-minute scoping callWe talk through scope, options and a realistic estimate — with no obligation.
Free estimateNo obligation

Talk to someone who builds this

Send a short brief and we will come back with an honest view and a realistic range.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →