SKIP TO CONTENT
HIRING6 minHiring for Production / Ep. 1 · Stage 1-2

AI Engineer Trial: How to Test Before You Commit

You liked the interview. Before you sign, what should a short paid test show you?

XIN

IN 30 SECONDS

A paid working session is a short, bounded task meant to show how a candidate decides. This stage walks through one, the brief to send, and how to choose the format.

KEY TAKEAWAYS · 3

  • Agree the time limit and the pay for any trial, and share a cleaned-up example with no client data.
  • Send a brief in five parts: outcome, inputs, authority, acceptance and delivery.
  • When data access or integration complexity is still unknown, use a paid discovery phase with clear limits.
On this page

IN SHORT A short, paid session is meant to show how someone decides, including what they refuse to automate.

WORDS TO KNOW

Production
The live system real users rely on, as opposed to a demo.
Discovery phase
A short, paid first step meant to map your data and systems before anyone commits to a delivery plan.
Handover
Passing the system to the team that will run it, with the code, the notes and a way to undo a release.

I prefer a bounded task to an unpaid build for Production The live system real users rely on, as opposed to a demo. See the glossary. Agree the time limit and the pay first, then share a cleaned-up example with no client data.

WATCH OUT

The exercise below is made up, for a document assistant. It is a hiring test, not a report on a client system and not a full security review.

STEP BY STEP

Flow diagram: 5 stepsFlow diagram: 5 steps. Set up the files, then Define a supported answer. Define a supported answer, then Change the conditions. Change the conditions, then Locate the failure. Locate the failure, then Plan the next step.1Set up the files2Define a supported answer3Change the conditions4Locate the failure5Plan the next step

Step 1. Set up the files. Supply a current file, an obsolete one and a question the files don’t answer. Mark who can open each file.

Pick a step to see it move
  1. Set up the files Supply a current file, an obsolete one and a question the files don’t answer. Mark who can open each file.
  2. Define a supported answer Ask for a minimal read-only answer path. First, the candidate says what a supported answer is.
  3. Change the conditions Switch the user and remove a source. Watch whether the system refuses and explains the missing evidence.
  4. Locate the failure Can they say where a failed case broke: retrieval, extraction, access or generation? And write the test that catches it next time?
  5. Plan the next step Ask for the next step, the biggest open risk and an estimate with its assumptions written out.
An illustrative hiring exercise in five steps. The strongest signal often comes at step 4, after a failed case.

Coming up next: And what do you send before the work starts?

Write a brief someone can estimate

IN SHORT A brief in five parts gives a candidate what they need for an honest estimate.

I’d send this brief with the job post, unknowns in plain sight, so discovery can clear them up.

THE BRIEF
Layered stack diagram: 5 layers, top to bottomLayered stack diagram: 5 layers, top to bottom. Layer 1, OUTCOME: One user, one recurring task, today’s process as the baseline. Layer 2, INPUTS: Systems, document types, source owners, Access limits, test data or not. Layer 3, AUTHORITY: Read-only answers, suggested actions, executed actions, A named human approver for consequential changes to data. Layer 4, ACCEPTANCE: Test cases, failure handling, cost, who signs off, Thresholds set from your own risk. Layer 5, DELIVERY: Environment, target date, review time, support after handover.OUTCOMEOne user, one recurringtask, today’s process as thebaselineINPUTSSystems, document types,source ownersAccess limits, test data ornotAUTHORITYRead-only answers, suggestedactions, executed actionsA named human approver forconsequential changes todataACCEPTANCETest cases, failurehandling, cost, who signsoffThresholds set from your ownriskDELIVERYEnvironment, target date,review time, support afterhandover
Read from the top. Don’t skip authority: it decides what the software may do.

If those inputs are unclear, pay for a short Discovery phase A short, paid first step meant to map your data and systems before anyone commits to a delivery plan. See the glossary first. It should hand you a data-access map, one tested guess about how the systems connect, first test cases and a scoped proposal. How long it takes depends on your access constraints.

A delivery date promised before anyone has looked at your access constraints is not a useful estimate.

Coming up next: Then: a mission or a permanent hire?

Decide who owns the system after launch

IN SHORT Pick the format by who will own the system once it ships.

IN PLAIN WORDS

A bounded mission works when your team can take the Handover Passing the system to the team that will run it, with the code, the notes and a way to undo a release. See the glossary and keep the result running. A permanent role makes more sense when AI work is a lasting part of your product.

WHO OWNS IT AFTER LAUNCH?
Decide: Who will own the system after launch?Decision tree: Who will own the system after launch? If your team can receive and maintain it, then Contract mission. If AI is an ongoing product responsibility, then Permanent role. If the inputs are still unknown, then Paid discovery first.DECIDEWho will own the system afterlaunch?If your team can receiveand maintain itContract missionShould end with an acceptedworkflow, reviewed code,deployment notes, a runbook(a guide for running it)and a named receivingengineer.If AI is an ongoing productresponsibilityPermanent roleShould own a product area,with access to users, roomto improve integrations andtime to keep evaluationscurrent.If the inputs are stillunknownPaid discovery firstMap data access and testthe key assumptions beforeyou commit to eitherformat.
Three common answers. The third comes first while the inputs are still unknown.

ITEM GET

Owner first, format second

Name who runs it after launch; the format follows.

My work combines production AI engineering and integration with systems where actions need clear permissions. If that fits, send me the workflow and the brief. You can start with the business problem; you don’t need to have picked your AI tools.

AI engineer hiring questions

Skills around the model: links to your systems, permissions, failure tests, cost and handover. Ask them to walk you through one live workflow and a failure they can back up. Knowing a framework alone doesn’t prove they can own it in production.

If the task follows fixed rules, a backend workflow may be enough. If it needs language or document search, look for someone who can test those model steps. Many projects need both skills in the same person.

It depends on the workflow, source systems, data-access limits, tests and support. Ask for discovery, delivery and running costs one by one. The model bill is only one part: integration, data cleanup and human review can change the scope a lot.

Adam works on AI agents in production, retrieval systems and linking software together. He is open to talking about contract missions and senior engineering roles.

STAGE CLEAR

What you now know

  • A short, bounded, paid session is meant to show how a candidate decides; the failed case often teaches you most.
  • What a brief needs: outcome, inputs, authority, acceptance and delivery, with the unknowns left visible.

Check yourself

Tap or click a question to see the answer.

Your team has no engineer who could maintain the system, and AI will be a lasting part of the product. Which format fits?

A permanent role makes more sense: AI is a lasting part of the product, and no one on the team could take the handover.

Next episode:What should you write down before you ask a Solidity developer for a quote?6 min
Adam Boudjemaa
Adam Boudjemaa

Former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft. Building production AI and regulated Web3 systems.

Have a project to ship or a role to fill?

Discuss your project or role
LinkedInTwitterGitHub
Follow the engineering notes

Get new articles on production AI and smart contracts by email.