How to Hire an AI Engineer for Your Business

Do not start with, “We need an AI engineer.” Start by completing this sentence:

In the next 90 days, this person will turn [a specific workflow] into [a measurable result], using [the data and systems we actually have], without violating [our reliability, privacy, cost and approval constraints].

If you cannot fill in those blanks, you do not yet have a hiring brief. You have a fashionable title searching for a job.

That distinction matters because “AI engineer” now covers several different kinds of work. A researcher training models, a product engineer adding an LLM feature, and an integration engineer rebuilding a customer workflow may all use AI, but they should not receive the same job description or interview.

The current OpenAI Applied AI Engineer role is a useful picture of production applied-AI work: opportunity selection, architecture, prototypes, evals, integrations, reliability, latency, cost, security, governance and adoption. Success is described in terms of production systems and meaningful customer outcomes, not the number of models or frameworks someone can name.

Most businesses do not need every capability on that list at equal depth. They need to find their bottleneck, hire the closest role, and test whether the candidate can do that work.

Choose the bottleneck before the title

This is a practical map, not an industry-standard taxonomy. One person may cover two columns in a small company. Pick the dominant job for the next 6–12 months.

Your real bottleneck	Role to look for	Evidence that matters	You may be hiring the wrong role if…
Turning a known customer or employee workflow into a useful AI feature	Applied AI / AI product engineer	Shipped product features, backend and frontend integration, evals, user feedback, latency and cost trade-offs	The interview is mostly ML theory even though you plan to use hosted models
Connecting models to messy business systems, data and stakeholders	AI integration / forward-deployed engineer	Requirements discovery, APIs, permissions, workflow redesign, customer communication and production debugging	Nobody can explain who owns the workflow or what systems it must touch
Building reusable model access, observability, routing and evaluation for several teams	AI platform / evaluation engineer	Internal platforms, test datasets, tracing, reliability, model migration and developer experience	You have one small use case and no product team ready to use a platform
Improving a proprietary prediction or decision system from substantial domain data	Machine-learning engineer	Data pipelines, training and validation, deployment, drift monitoring and domain-specific metrics	A prompt, retrieval system or deterministic workflow would solve the problem without custom training
Improving model capabilities or training methods that existing models cannot provide	Research engineer / scientist	Experiments, publications or equivalent research output, training systems and rigorous empirical reasoning	Your unmet need is ordinary product delivery, integration or adoption

The expensive mistake is not choosing the “less impressive” title. It is hiring an excellent person for work your business does not have.

For example, a 40-person insurer that wants to draft claim summaries from existing documents probably needs an applied or integration-minded engineer who can work with permissions, source citations, review queues and audit logs. Hiring a specialist in pretraining large models would not solve the immediate bottleneck. A company building a new speech model may reach the opposite conclusion.

Write the hiring brief as a system, not a wish list

Before writing qualifications, give the role a one-page operating brief.

1. Name one workflow

Avoid “drive AI transformation.” Name the work:

• draft a support reply from the ticket and approved knowledge base;
• extract fields from supplier documents for human verification;
• help account managers prepare a renewal brief;
• classify inbound requests and route uncertain cases;
• let analysts search a governed set of internal research.

2. Define a useful outcome

Choose a result the business can observe, such as:

• reduce median handling time while keeping the escalation rate within an agreed range;
• increase the percentage of documents processed without manual re-entry;
• shorten time to a first draft without increasing material correction errors;
• help a team complete a task more often, not merely generate more text.

Do not make “launch an AI agent” the success metric. That is an implementation choice.

3. List the operating constraints

At minimum, document:

• what data the system may read and retain;
• which actions require a person’s approval;
• acceptable latency and operating cost;
• the integrations and identity model;
• the consequences of a wrong answer;
• who reviews failures after launch.

The NIST Generative AI Profile frames AI risk work across governance, mapping, measurement and management over the system lifecycle. You do not need to turn a small hire into a compliance programme, but the principle is useful: risk decisions belong in the use case and architecture, not in a safety paragraph added after the demo.

For systems that can take actions, security is part of the engineering job. The OWASP guidance on excessive agency recommends limiting tool functionality, permissions and autonomy, then enforcing authorization in downstream systems. A candidate who proposes giving an agent broad production access because “the prompt says not to misuse it” has revealed an important gap.

4. State what exists on day one

Tell candidates whether they are joining:

• a nontechnical team with only the workflow and data;
• a product team with a prototype;
• an established application that needs an AI feature;
• several teams that need a shared platform;
• a research effort with compute and training data.

“Build from zero” can mean five very different jobs.

Screen for evidence of the full loop

The strongest resume is not necessarily the one with the longest list of model names. Look for evidence that the candidate has completed the loop from problem to production learning.

Use this six-part screen:

Criterion	Strong resume evidence	Follow-up when the resume is unclear
Problem framing	Defines the user, workflow, failure cost or business outcome	“What did the team decide not to automate, and why?”
Hands-on engineering	Personal contribution to code, architecture, integrations or debugging	“Which component did you personally own?”
Evaluation	Test cases, quality metrics, human review, regression checks or failure analysis	“Show how you knew version two was better than version one.”
Production operation	Monitoring, incidents, fallbacks, latency, cost or scale	“What changed after real users touched it?”
Security and data judgment	Permissions, privacy, threat modelling, data boundaries or auditability	“What could the model access, and what prevented an unsafe action?”
Adoption and communication	Worked with domain experts or users and changed the system from feedback	“Who disagreed with the original approach, and what changed?”

Use demonstrated, suggested, or not shown rather than pretending every resume settles every criterion. “Not shown” is a question for the next stage, not automatic proof that the candidate lacks the skill.

If you are screening a large PDF batch, you can put these criteria into Resume Ranker and ask it to cite the exact evidence behind each note. Use the output to order human review and surface questions, not to auto-reject applicants.

Signals to treat cautiously

These may support a case, but they are weak filters on their own:

• a long list of rapidly changing framework names;
• “prompt engineering” without a shipped workflow or evaluation method;
• a chatbot demo with no representative test set;
• a famous employer without a clear personal contribution;
• an arbitrary degree requirement for product-integration work;
• years of experience in a field whose current tools are much younger;
• claims of eliminating hallucinations rather than measuring and managing failure.

Do not replace evidence with a prestige contest. Define the job-related capability and let candidates demonstrate it through employment, independent work, open source, consulting, research or an appropriately designed exercise.

Use a realistic work sample, not AI trivia

The US Office of Personnel Management describes work samples as tasks that mirror work performed on the job. Its structured interview guidance likewise recommends predetermined, job-related questions and a common rating scale. Those principles travel well beyond government hiring: ask everyone to do comparable work, decide how you will score it in advance, and assess the job rather than the person in the abstract.

For an applied AI hire, use a short, sanitized version of your actual problem. Allow the tools the person would reasonably use at work, including AI assistants. The test is not whether they can hide their tool use. It is whether they can produce and defend a sound result.

A copyable 90-minute exercise

Give the candidate:

• a one-page description of the workflow and user;
• 10–15 representative, sanitized inputs, including difficult cases;
• a simple baseline output or weak prototype;
• the available systems and constraints;
• an explicit statement that implementation can be code, pseudocode or an architecture sketch depending on the role.

Ask them to produce:

1. a proposed first version and the boundary of what it will not do;
2. an evaluation table with test cases, expected behaviour and failure severity;
3. one production risk involving data, permissions or unsafe actions;
4. a debugging plan for a quality regression;
5. the first trade-off they would make among quality, latency and cost;
6. three questions they need answered before building.

If you require a substantial implementation beyond a short exercise, consider making it paid. Never ask candidates to solve live commercial work for free.

Score it before the interview

Use a 100-point rubric:

Area	Points	What earns a strong score
Problem and scope	20	Finds the user outcome, constraints and a sensible non-AI or human fallback
Technical approach	20	Chooses a proportionate architecture and explains important trade-offs
Evaluation and debugging	20	Uses representative cases, observable criteria and a plan to isolate failures
Reliability and operations	15	Covers monitoring, fallbacks, latency, cost and change management
Security and data boundaries	15	Applies least privilege, protects sensitive data and identifies unsafe actions
Communication	10	Makes assumptions visible, asks useful questions and explains decisions clearly

Score the work independently before discussing it as a panel. The point is not mathematical certainty; it is stopping the most confident interviewer from silently inventing the criteria after meeting the candidate.

Ask five structured interview questions

Use the same core questions for every finalist and define what a strong answer contains.

1. Tell us about an AI system you helped move from prototype to real use. Listen for personal contribution, users, constraints and what changed after launch.
2. How did you decide whether it was good enough? Listen for representative cases, baselines, multiple failure types, human calibration and ongoing monitoring—not one average score.
3. A model or prompt update improved the demo but hurt some production users. What do you inspect first? Listen for traces, segmented metrics, retrieval and tool behaviour, changed inputs, rollback and reproducibility.
4. The system reads untrusted documents and can update a customer record. How would you limit the damage from a malicious or misleading input? Listen for least privilege, constrained tools, downstream authorization, validation, logging and approval for consequential actions.
5. When would you remove the model from this workflow? Listen for the judgment to choose deterministic software, search, rules or a human process when they are safer, cheaper or easier to evaluate.

Evaluation deserves its own question. Anthropic’s account of agent evals in production describes why manual testing and intuition begin to break down as systems scale, and why automated evals should be combined with production monitoring, user feedback and human review. A practitioner recap from a 2026 AI-production event made a similar point: Ryan Wang reported that teams discussed shared ownership between engineering’s inner-loop tests and product’s customer-level outcomes. Treat that post as a useful field observation, not a universal survey.

A worked example: hiring for customer-support automation

Suppose a growing software company wants an AI system to draft responses for billing and account-access tickets. A support agent must approve every reply. The knowledge base is inconsistent, and the product contains sensitive account data.

The 90-day brief could be:

Build and pilot an agent-reviewed reply workflow for two ticket categories. Reduce median drafting time by 30% on the pilot queue while keeping material correction errors below the agreed threshold. The system may read approved help content and the minimum account fields required for the ticket; it may not send a reply or change an account without a person’s explicit action.

That points toward an applied AI or integration engineer, not a research scientist. The resume screen should prioritize shipped customer workflows, API and identity work, evaluations, fallbacks and collaboration with support or operations.

The work sample could provide 12 sanitized tickets, an imperfect knowledge-base excerpt and a baseline set of draft replies. A strong candidate might:

• separate answer quality, citation correctness, tone and unsafe-action failures;
• decline to answer when the source material is missing;
• keep account updates outside the model’s permissions;
• propose a small pilot and a review interface before autonomous action;
• log model, prompt, retrieval source, latency, cost and reviewer correction;
• explain when a deterministic template is better than generation.

Notice what the exercise does not require: memorizing transformer equations, naming every orchestration framework, or building a polished unpaid feature. It tests the work the business is actually hiring for.

Copy this AI engineer hiring brief

Business workflow:
Primary user:
Current process and bottleneck:

90-day outcome:
How we will measure it:
Cost of a wrong result:

Data the system may use:
Systems it must integrate with:
Actions that require human approval:
Latency and operating-cost constraints:
Security, privacy or regulatory constraints:

Dominant role for the next 6–12 months:
Why this role matches the bottleneck:

Resume evidence criteria:
1.
2.
3.
4.
5.
6.

Work sample:
Scoring rubric:
Structured interview questions:

30-day evidence of progress:
60-day evidence of progress:
90-day evidence of progress:

If a hiring manager, technical adviser and domain owner cannot agree on this page, pause the search. Their disagreement will not disappear when candidates arrive; it will simply become inconsistent screening.

The short version

1. Define the workflow, result and constraints before choosing the title.
2. Hire for the dominant bottleneck: product delivery, integration, platform/evals, ML or research.
3. Screen for evidence across problem framing, engineering, evaluation, production, security and adoption.
4. Run a short job-shaped work sample with realistic cases and allowed AI tools.
5. Score it with a predefined rubric, then ask every finalist the same core questions.
6. Judge success by a dependable, adopted workflow—not a dramatic demo.

You do not need to become an AI expert before hiring one. You do need to be specific about the business problem, honest about the operating constraints, and disciplined enough to ask candidates for evidence that resembles the job.