What a good technical assessment for AI work should feel like
5 minute read. Updated 2026-08-08.
A good technical assessment for AI work uses a real, scoped problem from the client's own domain, tells you upfront how it will be judged, and pays for anything beyond a couple of hours. It should feel like a preview of working with them, not an audition you have to win at any cost. Push back on open-ended builds, unpaid multi-day work and vague evaluation criteria; accept short, paid, clearly scoped tasks instead.
What it's testing, and what it isn't
A well-designed assessment for AI work tests judgement on a problem close to what you'd actually be doing: reviewing a flawed pipeline, critiquing a model choice, sketching an approach to a stated business problem. It is not testing whether you can complete a generic coding puzzle under time pressure, because that skill has little to do with the job you'd actually be hired for.
Good assessments come with a stated evaluation method before you start: what the assessor is looking for, roughly how long it should take, and who will review it. If a client can't tell you how the work will be judged, that's often because they haven't decided what they're hiring for yet, and the ambiguity will follow you into the contract if you take it.
What to accept
A paid assessment, even a short one, is a reasonable ask and worth accepting. A half-day or day of paid work reviewing a real problem gives both sides useful information about fit. A take-home task capped at 2 or 3 hours, clearly scoped and unpaid, is also reasonable for most engagements, especially at day rates that reflect this level of the market.
Accept a technical conversation with the person who will actually manage the work, not only with a recruiter or a generalist interviewer. That conversation, more than any written test, tells you whether the engagement will be well run and whether your judgement will be given room to matter.
What to push back on
An unpaid multi-day build is not a reasonable ask, whatever justification is offered for it. If a client wants a working prototype rather than a design document, that's scoped delivery work and should be paid, even at a reduced rate against the eventual engagement.
Push back on assessments framed as show us what you'd do with no defined problem attached. Open-ended tasks like this usually signal that the client hasn't scoped their own need yet, and the assessment quietly becomes an unpaid discovery exercise for them rather than a test of you.
Watch for IP language buried in an assessment brief. Some briefs quietly claim ownership of anything produced during the test, including code or ideas that go well beyond what a fair evaluation requires. Read the brief for this before you start, not after you've built something they can keep for free.
How to push back without losing the engagement
State the concern plainly and offer an alternative, rather than declining outright. I don't do unpaid builds beyond a couple of hours, but I'm glad to do a paid half-day assessment against a real problem, or talk through my approach to one of yours on a call, moves the conversation forward instead of closing it down.
Frame the pushback as protecting the quality of the assessment, not as suspicion of the client. A client asking for scoped, paid work will usually agree, because it produces a better signal for them too. A client who refuses any paid option, on work beyond a couple of hours, has already told you something about how they'll treat scope creep later in the contract.
What the assessment predicts about the engagement
How an assessment is run tells you more than its content. A client who moves the goalposts mid-assessment, adds scope without discussion, or takes weeks to give feedback is showing you, in miniature, how the actual contract is likely to run once you're inside it.
A client who gives a fast, specific decision, whether yes or no, and explains their reasoning, is usually a good sign. Decision speed on the assessment is a reasonable proxy for decision speed once the contract starts, which matters more in AI work than most, because scope tends to shift as findings come in.
What to do about it
- Insist on knowing how the assessment will be judged before you start it.
- Accept short paid assessments and time-capped unpaid tasks under a couple of hours.
- Refuse unpaid multi-day builds regardless of how the ask is framed.
- Check the brief for IP language before doing any work, not after.
- Offer a paid alternative when declining an unreasonable ask, rather than a flat no.
- Treat how the assessment is run as a preview of how the contract will run.
Questions people also ask
Is it reasonable for a client to ask for a paid technical assessment before hiring for AI work?
Yes, and it's often a good sign. A paid half-day or day assessing a real problem gives both sides genuine information about fit, which benefits you as much as the client. Be more cautious about assessments that are unpaid and open-ended, since those usually signal the client hasn't scoped their own need yet, or expects free discovery work disguised as an interview.
How long should an unpaid take-home task take?
A couple of hours is a reasonable ceiling for unpaid work. Beyond that, the task has moved from an assessment into scoped delivery, and it's fair to ask for payment or push the task into a short paid assessment instead. If a brief doesn't state an expected time, ask before starting, and treat a vague answer as a signal in itself.
What should I do if a client won't tell me how the assessment will be evaluated?
Ask directly what they're looking for and who will review the work. If the answer stays vague, that usually means the role itself is loosely defined, which tends to cause scope disputes once the contract starts. You can still take the work, but go in with clearer boundaries on scope and change requests than you otherwise would.
Can a client keep the code or ideas from a technical assessment?
Check the brief for IP language before you start. Some briefs claim ownership of anything produced during the assessment, which goes beyond what a fair evaluation needs. If a brief is silent on this, ask directly rather than assuming; get any answer in writing before you submit work you'd rather they didn't keep for free.
Where the figures come from
Every rate and salary quoted in this article is a median or percentile of figures advertised in UK job postings over the six months to 8 August 2026. They are not rates paid, and the gap widens at the top of a range.
- IT Jobs Watch, UK contract rates, 6 months to 8 August 2026, read 2026-08-08.
- IT Jobs Watch, UK permanent salaries, 6 months to 8 August 2026, read 2026-08-08.