I stopped interviewing developers. Here's what I do instead.
In 2020 I hired a developer who nailed the architecture explanation in the interview, answered every PHP question correctly, and impressed two people on the team. Four months later I let him go. Not because he was incompetent in the abstract — he just couldn't work in our actual context.
After that, I stopped doing traditional interviews.
What interviews actually test (and what they miss)
An interview is a performance. The candidate knows they're being evaluated, they've prepared, they're showing you their best 90-minute version. That's fine, but it doesn't tell you how they handle a three-day-old Bitrix module with no documentation, a vague task from a client, and the one person who knows the context currently on vacation.
I spent months onboarding people who were great at explaining things but couldn't work in our environment. That's expensive. Not just in money — in missed deadlines, in conversations with clients about delays, in the psychological cost of watching someone struggle. I close risks, not tickets, and hiring is no exception.
The cost of a bad mid-level hire runs between three and six months of their salary when you account for onboarding, code rework, and project delays. Three days of a paid trial costs a fraction of that.
The 3-day paid trial: how it works
The setup is simple. I offer candidates three working days in our real environment. The task is small but genuine — something like adding caching to a Bitrix component without changing its existing interface, or setting up a job queue with RabbitMQ in an existing PHP project. Not a synthetic exercise. An actual slice of our repository.
For those three days, the candidate gets paid at their normal rate. I don't ask anyone to work for free.
This matters for a few reasons beyond the obvious ethics. Developers who are worth hiring don't do unpaid tests. Paying also removes artificial pressure — the person works normally instead of performing. And if things don't work out, they leave without feeling used.
Technically: I create a separate branch, give dev environment access, do a 30-minute onboarding call. Then they work like any other team member.
Three signals you only see in real work
I'm not primarily watching the output. I'm watching how the person works.
First: questions. A good developer asks clarifying questions within the first few hours. Not because they don't understand the task — because they understand that every real task has gaps. Someone who silently starts working and shows up 24 hours later with "done" has usually built something for a version of the task that exists only in their head.
Second: blockers. Real code always has something in the way. Do they message right when they hit a wall, or do they dig in silence for two days? Do they ask permission for every decision, or do they make reasonable judgment calls and flag them afterward?
Third — and this one's subtle — is how they talk about legacy. We have code that's five to seven years old. If someone starts flagging every line as "needs a rewrite," that's worth noticing. Not because they're necessarily wrong — sometimes they're right. But in the first three days they don't yet understand why things were written the way they were. Rushing to criticize code you don't understand yet usually signals limited experience with other people's codebases.
How good candidates react differently
One of the best developers I've hired was quiet and careful in the initial conversation. Not much detail, slightly guarded. But on the first day of the trial, he found a bug in the task I gave him, reported it without drama, and proposed two options: do it as written or fix the bug first. I said fix it. He fixed it, completed the task, then wrote two tests I hadn't asked for.
That's not someone who sells himself well in interviews. That's someone who knows how to work.
The candidates who don't work out on the trial usually have one thing in common: they need constant reassurance. "Am I doing this right?" every two hours. "Did you see what I sent?" That's not a character flaw — it just tells me they need a level of supervision that doesn't fit our workflow.
The math: cost of a bad hire vs. three days
At a rate of €40-50/hour, three days of a paid trial comes out to around €960-1200. That sounds like a lot until you compare it to the alternative: three to four months of onboarding someone who turns out not to fit, plus the delays and rework that follow.
I've run more than 20 paid trials over the past three years. About six ended with no hire — either I decided it wasn't the right fit, or the candidate realized our context wasn't for them. In every one of those six cases, we spent three days instead of several months.
Trial-to-offer conversion rate: around 70%. Offer-to-still-here-after-one-year: around 85%. That's math I'm comfortable with.
When the trial doesn't work — honest answer
There are situations where this model breaks down.
If you need someone urgently, you don't have three days for a trial. That's a real constraint.
If the candidate is full-time somewhere else and can't take three days, the trial doesn't happen. Sometimes we compromise: a task over a weekend, a longer timeline. But it's a weaker signal.
If the work involves confidential systems where you can't give a stranger repository access, you need either an NDA first or a synthetic task. Synthetic tasks work, but they're less accurate.
And the model only works if you have a real task ready. If there's nothing concrete to hand off for three days, you end up testing for something different than what you want to know.
In the end
An interview is a sales process. The candidate is selling, you're buying. Three days of real work isn't sales. It's work.
I'm not saying skip the initial conversation — a 30-minute call still matters. But if you want to know whether someone will fit your team and your codebase, the only reliable way is to work together. Even just three days.