October 19, 2026·5 min read
Contract hiring moves at a different speed. Somebody needs to start next Monday, the budget is approved, and a four stage interview loop is not going to happen. That is the correct instinct: a freelancer who is available on Monday is usually not available in three weeks.
The problem is what gets skipped. A portfolio tells you what somebody built alone, with no deadline, no legacy and no second developer. A reference from a previous client tells you whether they were pleasant and on time, which matters, and not whether the code they left behind cost anything afterwards.
Both questions can be answered in one session, if the session is the right shape.
The permanent hiring question is: will this person get better here over two years. The contract question is narrower and more immediate:
That last one is the whole risk. A contractor who hides an unfinished edge costs more than one who was slower and said so.
Give them a task in a copy of a real repository. Not a toy project, and not a greenfield exercise: the point is the friction of arriving somewhere that already has opinions.
Pick something small and genuinely representative: add a field end to end, fix a bug with an existing test, extend an endpoint. An hour is enough, because the first hour on an unfamiliar codebase is exactly the hour you are buying.
The environment should be set up already. You are not testing whether they can install your dependency chain, and watching someone fight an environment for forty minutes tells you nothing you wanted to know.
Do they look for the convention before writing? A contractor who finds the existing pattern and follows it is worth more than one who writes better code in a different style. Consistency is what survives them.
Do they run the tests early? Early means before they are confident, not after. It tells you what they will do on a Friday afternoon.
Do they ask about scope? The right question in a short engagement is almost always: is this in scope, or should I leave it and tell you. Someone who silently refactors a neighbouring module is a risk even when the refactor is good.
What do they say at the end? Ask for a two minute handover. The answer separates people faster than the code does: what is done, what is not, what they would do next, what they are unsure about.
If you take one reference, do not ask whether they would hire them again. Ask: what did you have to do after they left?
The answers are specific and hard to coach. Nothing, it just worked. We had to rewrite the deployment part. Nobody could run their tests. It was fine until we needed to change it.
That single question tells you about the handover, which is the whole product in a contract engagement.
Two practical points that decide more contracts than skill does.
Agree what done means before the start date. Not a list of features, a list of conditions: tests pass, it runs on a clean environment, a README that a colleague can follow. Write it down in two lines. Most contract disputes are definitional.
Decide who owns the environment. If the contractor works on their own machine with their own stack, you inherit code that worked somewhere you cannot reproduce. Giving them a workspace that matches yours removes that whole class of argument, and it is the same reason onboarding a contractor in a day is worth setting up once.
Four rows, for every candidate, written down before the session:
Technical ability is not a row, because it is a precondition. If somebody cannot do the task at all, the session ends early and you have your answer in fifteen minutes rather than three weeks.
This only works if the candidate can be dropped into a working copy of your world in a minute, with the dependencies installed, the database seeded and the tests runnable. Sending a repository and hoping is how you end up grading an environment rather than a person.
EasyEnv gives you a disposable workspace with your repository, your toolchain and your tests, identical for every candidate, available on a link. For a one hour contract screen that is the difference between starting at minute one and starting at minute twenty five. Sessions are recorded, so when two people on the team disagree about a candidate, they can look rather than argue.
The limits, plainly. Preparing a representative task takes an afternoon the first time, and it should come from your own repository rather than a sample. Somebody technical has to watch or review the recording. And for a very small engagement, a few days of work, this process costs a meaningful fraction of the job: a short paid task may simply be cheaper.
Do not run a four stage loop for a four week contract, and do not skip the assessment because the engagement is short. Run one hour, in your repository, on a task that is genuinely yours.
Watch whether they look for the convention, run the tests early, ask about scope, and tell you honestly what they did not finish. The work ending well matters more than it starting fast.
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Support interviews test warmth and scripts, then the job turns out to be technical from the first ticket. Here are four tasks on a real box with a real symptom, reproducing a vague report, separating configuration from defect, reading the logs that matter, and writing the reply.
Anyone can draw the migration diagram. Migrations fail at the cutover, at 2am, when half the traffic is on the new platform and the old database is still taking writes. Here are four tasks that test the parts that actually go wrong.
Read more
Hiring someone to build with models is not the same as hiring someone who codes with one. Here are four tasks on a running LLM service, output that fails to parse, a change nobody can prove is an improvement, a context window that grows until it costs real money, and a provider having a bad afternoon.
Read more
