You've probably been there. Eleven interviews in, every CV says Python, TensorFlow and "hands-on machine learning experience"; everyone sounds clever on the call, and you're no closer to knowing who can build the thing.
We talk to founders and CTOs on this spot pretty much every week. And the fix is rarely "interview more people". It's usually "get much clearer on who you're looking for".
So that's where we'll start.
Here's the mix-up behind most bad AI hires. "AI engineer", "data scientist," and "ML researcher" get used interchangeably as if they're the same job. They aren't. Not even close.
The AI engineer is a builder. They take a model (sometimes one they trained, more often one that already exists) and turn it into a feature people use. That means data pipelines, APIs, cloud deployment, and monitoring. If it breaks on a Saturday, they're the ones who fixes it.
The data scientist is more of an analyst. Give them a messy question like "why did churn go up last quarter?" and they'll come back with a proper answer. Some of them build models, too. Getting those models into a live product, though? Often not their strong suit, and that's fine. It's a different job.
Then there's the ML researcher, who invents new methods and writes papers about them. Amazing people. You almost certainly don't need one unless you're building something truly new at the model level.
If you're trying to put AI into a product, you want the first one. Keep that in your head while you write the job description, because it changes everything that follows.
Most AI job ads open with a wall of tools. We'd start somewhere else entirely. Ask yourself: six months from now, what will this person have shipped?
Maybe it's an internal assistant that answers HR questions from your policy documents. Maybe it's cutting the time your finance team spends on invoices in half. Or a recommendation engine that nudges customers into a second purchase.
These sound similar on a slide. They're not. The HR assistant is a language model and retrieval job. Invoices are OCR and document AI. Recommendations are classic machine learning plus a lot of data engineering. Write the outcome down first, and you'll find the skills list practically writes itself.
A quick word on seniority, too. If nobody on your team has shipped an AI system before, your first hire really should be senior. We've seen talented juniors struggle badly with no one to learn from, and it's not their fault.
At the heart of it, you need a decent software engineer first. That sounds obvious, but it's the part people skip. Clean Python, tests, Git, sensible APIs. Lots of candidates are brilliant with models and a bit wobbly here, and it shows up the minute something has to go live.
On top of that sits applied machine learning, and what you're really testing is judgement. When will a simple model do? When should you just use a pre-trained one? When is a big language model worth paying for? And can they prove whichever choice they made actually works?
Then data. People underestimate this every time. Can they write SQL without thinking? Do they spot duplicate rows and weird outliers before those reach the model?
Then the deployment side: cloud, containers, monitoring, and keeping an eye on inference costs so they don't quietly double over a few months.
One last thing, and it's a big one. Can they explain stuff to people who aren't technical? Ask them why a model got something wrong. If the answer is a cloud of jargon, your sales or ops team is going to have a hard time working with them.
Please don't ask candidates to define overfitting. Everyone can. It tells you nothing.
Ask about something that went wrong instead. "Tell me about an AI project that didn't go the way you planned." Then just listen. People who've shipped real systems light up a bit here, because they've got war stories. The training data that turned out to be half duplicates. The model that worked perfectly until the first public holiday. The cloud bill nobody saw coming.
A couple of follow-ups we like: "How did you decide it was good enough to release?" and "Once it was live, what broke first?" And if you want to see how they think on their feet, try "You've got two weeks and a small budget for our problem. What do you do on Monday morning?"
Pay attention to what they talk about. Experienced engineers bring up edge cases, user complaints, latency and cost without being asked. Less experienced ones mostly talk about accuracy scores.
After the interview, give shortlisted people a small paid task. Four hours, give or take. Make it look like your real problem, or adapt this one:
"Here's a CSV of 5,000 past customer orders. Build a simple model that predicts which customers are likely to buy again in the next 60 days. Send us your code, a short note on how you checked the model, and one thing you'd do differently with real production data."
When it comes back, resist the urge to jump straight to the accuracy number. Read the note first. Did they notice the missing values? The duplicates? Did they say why they went simply (or didn't)? Did they think about retraining as new orders arrive? That note is a pretty good preview of how they'll work with you.
Then hop on a 45-minute call and have them walk you through it. Push back on one decision, politely. Good engineers will happily defend it, and they'll just as happily tell you what they'd change.
Some patterns make us slow down. The candidate who reaches for the biggest, fanciest model every single time, even when a few if-statements would do. The one who can't really explain how they checked their past work. The CV that's all courses, tutorials and Kaggle notebooks, with nothing that ever went live.
And the shrug when you ask about data privacy. "Not really my area." Hmm.
None of these is an automatic no. People grow, and context matters. But if you're spotting two or three in the same person, trust your gut.
There's no universally right answer here, just trade-offs.
Hiring full time gets you someone who'll own this for years. It also takes months, and senior AI salaries are not small anywhere in the world. Freelancers are brilliant for something short and well defined, though things can get awkward when they move on, and nobody else understands the code.
A third route is getting more popular, and it's the one we obviously know best: working with an offshore development partner. You get engineers who've already been vetted, a team that can grow or shrink as the project changes, and one company accountable for delivery. It's often the fastest way to get an AI product in front of real users. And nothing stops you building your own team later, once you know exactly what you need.
This is the part companies rush and then wonder why things are slow.
In week one, get your new engineer access to the real data. Not a sample of somebody exported last spring. Introduce them to whoever owns the project on the business side, the person who'll ultimately decide if this is working. Then agree on one small, visible win for the first month. A rough prototype a few colleagues can poke at is more than enough.
From there, a quick weekly demo goes a long way. Fifteen minutes, no slides. It keeps everyone honest and catches wrong turns while they're still cheap. Aim to have something running in production by the end of month three, even if only one team is using it.
If there's one thing to take away, it's this: hire for what you need to build, not for the buzzwords. Know which of the three roles you're after. Test with something that looks like real work. And listen for real stories.
If you'd like experienced AI engineers without sitting through a long hiring cycle, an AI development company like Techiebutler can help. We build dedicated engineering teams for startups and growing businesses, matched to your stack and goals, so you can keep your attention on the product. Tell us what you're working on, and we'll help you work out the right setup.
Pretty close, and the titles overlap a lot. ML engineers tend to lean towards building and training models. "AI engineer" has become a broader label, and these days it usually covers language models and plugging AI into products too.
