How to trial an engineer before you commit

Why founders want a trial

A CV and two calls tell you little about how someone works. Founders in our calls had been burned before: a vendor that overstated what its team could do, an engineer who needed hand holding, code that looked fine until it shipped. So they asked to see code samples, to interview several candidates, and above all to run a trial.

A trial is not a hoop for the engineer. It is the cheapest way to learn what you would otherwise find out in month three.

Pick the right trial task

• Real, not a puzzle. A ticket from your backlog beats a take-home. You see how they work in your context, with your tools.
• Bounded. One feature, one integration or one migration that can ship in about a week.
• Outside the core if you are nervous. Several founders asked for a scoped project outside the main codebase first: an internal tool, a prototype, a test harness. It limits access while you learn.
• Matched to the role. For a design engineer, a scoped mock-up or one polished screen shows taste fast. One founder planned a short part-time trial built around exactly that.
• Something you can judge. If no one on your side can review the code, pick a task whose result you can see working.

Set the review point before day one

1. Write down what done looks like: merged, deployed, demoed to you.
2. Pick the review date, usually the end of week one or week two.
3. Name who reviews: the founder, the CTO or a technical advisor you trust.
4. Agree the options at the review: extend, swap the engineer or stop.

Founders who set this up front ended their trials with a clear answer. Without it, a trial turns into a fuzzy month nobody decided on.

What to look at during the trial

• How they scope. Do they ask the questions you would ask? Do they flag what is unclear before building?
• How they communicate. A short written update each day tells you more than one weekly call.
• Pace and quality together. Fast and messy becomes a review burden. Slow and perfect becomes a runway burden.
• What they do when stuck. Try two things, then ask. That's the habit you want.
• Code you can follow. Walk through one pull request together. Asking to see code they wrote before is fair too.

When to swap, extend or stop

A trial only works if you act on it. If the fit is wrong, swap early: a second engineer with the right context beats three more weeks of the wrong one. If the fit is strong, extend and plan the next scope. One founder asked to extend a short trial within days because the fit was obvious. That's the outcome you want.

If you hire through a partner, ask upfront what happens when the first week doesn't work. At Lyra, you meet the engineer on an intro call before anything starts, and if you're not happy with the first week, Lyra refunds it in full.

Common trial mistakes

• A task so small it proves nothing, or so big it can't finish.
• No one assigned to review it.
• Judging only the code and ignoring communication.
• Starting with your most tangled system and no context.
• Letting an average trial roll into a long engagement by default.