How to Interview and Hire ML/AI Engineers

Hiring is one of those things everyone agrees matters and almost nobody does well, especially in ML and AI where the skill set is weirdly split between software engineering, statistics, and a tolerance for models that just refuse to behave predictably. Eugene Yan, writing with a collaborator named Jason, lays out a framework built from real interview experience rather than theory, and the most interesting part isn't the coding exercises — it's everything around them.

On the technical side, coding ability is table stakes. Candidates might validate a simulated warehouse robot's route, stand up an inference endpoint with logging and monitoring, or build a batch pipeline that later needs to handle streaming data. But Yan is blunt that finishing the exercise means little on its own. He's seen candidates solve the problem correctly and still get rejected because their approach was sloppy, unstructured, or didn't hold up to feedback. What matters is how they think, not whether the answer runs.

Data literacy gets unusually heavy emphasis here, and for good reason. Yan argues that a huge chunk of real ML work is unglamorous — staring at rows of data, spotting missing values, noticing when server-side and client-side logs disagree, catching a join that quietly duplicated half your rows. He quotes Jeff Bezos's line about anecdotes usually being right when they clash with the data, which is a nice way of saying good engineers get suspicious when numbers look too clean. Interviewers probe this by asking what messy data problems a candidate has actually hit and fixed, not just what tools they know.

There's also a section on comfort with opaque, stochastic models, which is a nicer way of saying: can this person live with the fact that an LLM might give a different answer to the same prompt twice? Some engineers, Yan notes, never fully adjust to that uncertainty, and that's fine — they're just better suited elsewhere. For research-adjacent roles, the piece adds three more axes: breadth across ML domains, depth on a chosen project, and the ability to apply judgment to an open-ended design problem with no clean answer.

Beyond the technical stuff, Yan introduces an acronym — AICE, for ambiguity, influence, complexity, and execution — as a lens for evaluating senior candidates. It's basically asking how messy the problem was, how far the candidate's impact reached beyond their own keyboard, how many moving parts they juggled, and whether they actually shipped something under real constraints. None of this is flashy, but it's the kind of scaffolding that turns a gut-feel interview into something closer to a repeatable process.