How to find and hire AI engineers

What an AI engineer does, and what the title hides

A paper carries a first author and a supervisor. Between them sit the people who made the training run finish, kept the inference server up under load, and got the evaluation harness to produce a number anyone believed. That is the work of an AI engineer, and it is measured by systems that keep working after the person who built them has moved on.

The title covers several jobs. Someone who trains models on a cluster, someone who puts a finished model behind an endpoint, and someone who builds the product around an API call all get called AI engineer, and they are found in different places. If you have not settled which one your problem calls for, start with AI researcher, applied AI engineer or AI product engineer. This guide is about the first two: the people who build and operate the machinery.

One question separates the profile from the title: what did you ship that other people came to depend on. An engineer answers with a system, a date and a failure they handled. A candidate who answers with a list of frameworks has described a curriculum.

Where AI engineers come from

Four pools, of very different sizes. Knowing which one you are fishing in decides where you look and what you read.

• Software engineers who moved toward models. The largest pool by far. A backend or infrastructure engineer took on the inference server, the data pipeline or the training job, and two years later runs it. Their résumé still says Software Engineer. Their commit history says otherwise, which is why keyword search never finds them.
• Researchers who prefer building. People who finished a doctorate, or left one, and would rather ship than publish. They know the models from the inside and often lack production habits, which the work sample below reveals in an afternoon. Our index dates the end of doctorates; see how to find and hire AI researchers for the timing.
• Engineers inside industry labs and platform teams. The fourth to ninth names on a lab's papers, the people who built the pipeline the paper ran on. They publish, but never first, so citation-based search ranks them last.
• Maintainers of the tools you already run. The people merging pull requests on the serving framework, the tokenizer library or the training stack you depend on. Small pool, highest signal per name, and the easiest to approach with a specific message.

Where to look, in order of yield

The former colleagues of your own engineers

Ask every engineer on your team for the five people they would hire again, with names, and do the outreach yourself rather than waiting for introductions. A message that opens with a shared former colleague gets answered at a rate no cold channel reaches, and the reference is already done. This channel runs dry after one round, which is why the next four exist.

Public code, read for evidence

Everything a job board knows about an engineer, that engineer wrote about themselves. Everything a repository knows about them, they did: commits with dates, issues answered, releases cut, code that other projects came to depend on. The pool is large and mostly passive. StarHunt's State of Developer Reachability 2026, measured across 275,000 public GitHub profiles, found that only 14% of developers signal they are open to work, while 61% of those still active and locatable publish an email address or a LinkedIn profile anyone can use. The people you want are reachable. They are simply not looking, which is why they never appear where candidates apply.

We built a tool for this half of the search: StarHunt, GitHub sourcing for AI engineers. It reads GitHub in real time and filters on stack, recent activity and the kind of AI work people commit, the same principle as our research index, applied to code. With or without a tool, five minutes on a profile answers four questions.

• Does anyone else depend on it. Issues opened by strangers, pull requests from outside the author's account, forks that are ahead rather than abandoned. Software with users has been maintained under pressure, which is the skill you are hiring.
• Is there a release history. Tags, a changelog, a version scheme. The author has thought about someone else's upgrade path, which almost nobody does before they have had to.
• What do the tests cover. A coverage percentage tells you little. Look for tests around the hard parts: concurrency, numerical edge cases, retry logic.
• How long has it been alive. Two years of intermittent commits on one project says more than forty repositories created over a weekend. Star counts measure promotion.

The middle of the author list

Search the literature of your subject and read past the first author. On a paper with eight names, positions three to seven are where the engineering sits: the person who wrote the data loader, the one who made distributed training converge, the one who built the evaluation. Our index lists every co-author of every paper it holds, with their affiliation and their other papers, and can be filtered to junior profiles and to people who have co-signed with an industry lab. Search it by subject and sort the result by what you need rather than by citations.

Contributors to the tools you already run

Open the merged pull requests of the serving framework, the training library or the tokenizer you depend on, and read the issue threads. The people who answer other users' bugs, with a reproduction and a fix, are doing your job interview in public. A message that names the pull request and explains what you are building gets a reply from people who ignore every recruiter template.

Job posts, written for engineers

Posts work last and work only when they are specific: the stack, the model sizes, the compute available, the problem for the next six months, and who the person would work with. A generic "AI/ML engineer" post reaches the people who optimised their headline for that phrase, and the engineer who spent two years on distributed training, still titled Software Engineer, never sees it.

How to test an AI engineer in an afternoon

The work predicts the work. Everything below can be done in half a day and tells you more than a week of interviews.

• A paid work sample in your own codebase. Four hours, a real and bounded task: make this evaluation reproducible, cut the latency of this endpoint, find why this data pipeline drops rows. Pay for it. You learn how they read unfamiliar code, what they ask, and whether they finish.
• An hour reading their code together. They pick the repository. You read it with them and ask why each decision was made and what broke afterwards. Ownership shows in the answers, and so does its absence.
• A systems conversation with numbers. Tokens per second, memory per batch, cost per million tokens, what happens when the queue doubles. Someone who has run the thing knows the numbers from memory and knows which ones surprised them.
• References about incidents. Ask former colleagues what broke and what the candidate did about it, at the time and afterwards. Praise is easy to give; an incident story is specific or it is invented.
• Skip the rest. Algorithm puzzles, oral quizzes on machine-learning theory and unpaid week-long take-homes select for free time and exam habits, and the best candidates decline them.

What it takes to close

Strong AI engineers have several offers and choose on the same few things, in roughly this order: the problem for the next year, the compute they will have and who queues for it, the people they would sit next to, how much they decide themselves, and then the money. Cover the first four in the first call, with specifics, or the fifth never gets discussed.

On money, say the range early. Candidates compare against the large labs and will find out anyway, and a range on the table before the work sample saves both sides a week. Base plus equity is the usual structure; explain the equity in numbers rather than percentages. Keep the whole loop, from first call to written offer, inside two weeks. A loop that stretches to a month loses the candidate to whoever moved faster, however good your offer was.

How long it takes, and what goes wrong

With active sourcing, expect six to ten weeks from the first list of names to a signed offer, most of it spent waiting for replies and scheduling. Four mistakes account for most failed searches.

• Hiring a researcher for an engineering job. A strong publication record and a strong production record seldom sit in the same person, and the roles are paid and managed differently. Decide which you need before you search.
• Screening on keywords. The people you want are titled Software Engineer and describe their work in the language of the system, not of the model.
• Waiting for the person who does everything. The engineer who also does research and also runs the product exists in job posts and rarely elsewhere. Hire the profile, add the second one later.
• Letting the loop stretch. Every week between first contact and offer is a week for a competing offer to land.

The other half of an AI team

If your search also covers the people who define what gets built, the sources change and so does the method: see how to find and hire AI researchers. If you are hiring specifically for someone who puts finished models into production, see how to hire an applied AI engineer. And if the choice between the three profiles is still open, start with AI researcher, applied AI engineer or AI product engineer.

Common questions

Where do AI engineers come from?

Mostly from software engineering: backend and infrastructure engineers who took on a model-serving or training system and kept it. Smaller pools are researchers who prefer building, engineers inside industry labs who appear in the middle of author lists, and the maintainers of open-source AI tooling.

How do you find AI engineers who are not on job boards?

Through the former colleagues of your own engineers, through public code where commits, releases and issue threads are dated records of what someone built, through the middle authors of the papers in your field, and through the contributor lists of the tools you already run. Each of these exists for engineers who have never written a job-board profile: across 275,000 GitHub profiles measured by StarHunt, only 14% signal they are open to work, yet 61% of the active ones can be contacted directly.

What should you look for in a candidate's GitHub profile?

Whether other people depend on their code: issues opened by strangers, pull requests from outside their own account, forks that are ahead rather than abandoned. Then a release history, tests around the parts that are hard to get right, and sustained activity over years on a small number of substantial repositories. Star counts measure promotion rather than capability.

How do you interview an AI engineer?

With a paid work sample of about four hours in your own codebase, an hour reading the candidate's own code together, a systems conversation with real numbers on throughput, memory and cost, and references that ask about incidents. Algorithm puzzles and unpaid week-long take-homes select for free time and the strongest candidates decline them.

How long does it take to hire an AI engineer?

Six to ten weeks from the first list of names to a signed offer when sourcing is active, most of it spent on replies and scheduling. The interview loop itself should run inside two weeks from first call to written offer; longer loops lose candidates to faster competitors.

What is the difference between an AI engineer and an AI researcher?

An AI researcher is measured by published work that establishes whether something can be done. An AI engineer is measured by shipped systems that keep working. The two records overlap in few people, and the roles are sourced, tested and paid differently.