Contract hiring compresses the usual timeline. A permanent hire can take weeks of interviews; a contractor is often expected to start soon and be useful quickly. That makes the screen before a candidate ever reaches the hiring manager much more important. It is where most of the filtering has to happen.
It is also where much of the industry is weakest. A CV that lists the right technologies is not evidence that someone can do the work, and a recruiter matching keywords cannot tell the difference. This is how we think a screen for contractors should work.
What the screen is for
A technical screen for a contract role has a narrower job than a full interview loop. It needs to answer:
- Can this person do the specific work in the brief? Not the job title in general, the actual work.
- Can they do it without much ramp-up? Contractors are usually expected to be productive within days.
- Is their experience what the CV says it is? Depth, recency and their own role in the work.
- Will they work well in this kind of team? Communication, handling ambiguity, asking for help.
It does not need to rank candidates against an abstract bar or test things the role will never use.
Who should run it
The screen should be run by someone who does, or has recently done, the same kind of work. A data engineer screens data engineers. A Salesforce consultant screens Salesforce consultants.
This matters because a practitioner can follow up. When a candidate says they "led the migration", a practitioner can ask what the rollback plan was, what broke, and what they would do differently, and can tell a real answer from a rehearsed one. A generalist reading from a question sheet cannot.
What a good screen looks like
We run screens as a working conversation of roughly 45 to 60 minutes. Formats vary by specialism, but most include some of the following.
A walk through real past work
Ask the candidate to describe something they built, tested, secured or delivered recently, and go deep on it:
- What was the problem, and what constraints did they have?
- What did they personally do, as opposed to the team?
- What went wrong, and how did they find out?
- What would they change now?
This is the most reliable part of the screen. Depth of detail is hard to fake, and it shows whether their experience matches the role.
A problem from the role itself
Take a realistic, simplified problem from the brief and work through it together. For an engineer, it might be designing a small feature or debugging a described failure. For a QA engineer, deciding what to automate first on a new product. For a business analyst, turning a vague stakeholder request into requirements.
The point is to see how they think, what they ask, and where they would get stuck, not whether they reach a particular answer.
Targeted technical questions
A few focused questions on the skills the brief marked as essential. Keep them to things the role actually uses, and prefer "how would you approach" over trivia that anyone could look up.
Working style
For contract roles, a few minutes on how they handle joining an existing team: how they get context, when they ask questions, how they handle disagreement with a permanent team member, and what they need from a manager in the first week.
What to avoid
- Trivia and gotchas. Knowing an obscure API flag is weak evidence of anything.
- Long unpaid take-home tasks. Experienced contractors often decline them, and the ones who have time for them are not necessarily the strongest.
- Puzzle questions unrelated to the role. They screen for practice at puzzles.
- Testing the nice-to-haves as if they were essential. Every extra requirement narrows the pool.
Turning the screen into something useful
A screen is only worth doing if the result reaches the hiring manager in a usable form. "Strong candidate, recommend" is not enough. For each candidate on a shortlist we write notes that cover:
| Section | What it says |
|---|---|
| Summary | One or two sentences on fit for this specific role |
| Strengths | What they did well, with examples from the screen |
| Weaker areas | Where they were less convincing, stated plainly |
| Suggested follow-ups | What the hiring manager should probe in their interview |
| Practical details | Rate, availability, notice period, work authorisation |
The weaker areas section is the one most often left out, and it is the most useful. A hiring manager who knows where to probe can run a shorter, sharper interview. A shortlist where every candidate is described as excellent tells them nothing.
Feedback to the candidate
Candidates should get feedback after the screen, whatever the result. It does not need to be long: what went well, and what would have made the difference. Contractors talk to each other, and a firm that screens people and then disappears soon finds good candidates stop taking its calls.
How this changes the hiring manager's job
When the screening is done properly, the hiring manager's interview becomes a confirmation and a conversation about fit, not a first filter. That is the reason we aim to send a shortlist of usually three candidates, each with written notes, rather than a long list of CVs.
If you have a contract role and want a shortlist that has already been through a practitioner-run screen, request talent. If you are a contractor and want a screen that is a conversation rather than a quiz, see our open roles.