{"id":336,"date":"2026-08-11T19:15:02","date_gmt":"2026-08-11T19:15:02","guid":{"rendered":"https:\/\/talently.tech\/en\/blog\/what-is-an-ai-engineer-hiring-guide-by-company-maturity\/"},"modified":"2026-08-21T17:39:20","modified_gmt":"2026-08-21T17:39:20","slug":"what-is-an-ai-engineer-hiring-guide-by-company-maturity","status":"publish","type":"post","link":"https:\/\/talently.tech\/en\/blog\/what-is-an-ai-engineer-hiring-guide-by-company-maturity\/","title":{"rendered":"Nobody Knows What an AI Engineer Is: A Hiring Guide by Company Maturity"},"content":{"rendered":"Reading Time: <\/span> 6<\/span> minutes<\/span><\/span>\n

“AI engineer” is not a role. It’s a shopping category that four different professions got dumped into, and the mismatch shows up as a six-month search ending in a bad hire or no hire. Decide which of the four jobs you actually need, and whether your company is even at the stage where that job exists.<\/p>\n\n\n\n

\n

TL;DR<\/h2>\n
    \n
  • “AI engineer” covers at least four distinct jobs<\/strong>: AI\/LLM application engineer, ML engineer, research scientist, AI platform\/MLOps engineer. They share almost no day-to-day work.<\/li>\n
  • Most companies posting for an “AI engineer” need a strong product engineer<\/strong> fluent with LLM APIs, retrieval, evals, and agent loops, not someone who trains models.<\/li>\n
  • Hire in sequence<\/strong>: application engineer first, then evals\/data, then platform. Research scientists are the last hire for most companies (for many, never).<\/li>\n
  • Pre-PMF, a research hire is a liability.<\/strong> They’ll optimize a model while you’re still guessing at the product.<\/li>\n
  • Enterprise gets this backwards<\/strong>, hiring modelers before it has inference infrastructure, cost controls, or observability, then wonders why nothing ships.<\/li>\n
  • The fastest JD fix<\/strong>: describe the artifact the hire ships by month three. If you can’t, you don’t have a role: you have a budget line.<\/li>\n<\/ul>\n<\/div>\n\n\n

    The four jobs hiding behind one title<\/h2>\n\n\n

    AI\/LLM application engineer.<\/strong> A product engineer whose surface area is the model. They wire LLM APIs into a product: prompt and context design, retrieval (RAG) over your data, tool calling and agent loops, fallbacks when the model returns garbage, token and latency budgets, and (the part everyone skips) an eval suite so you know whether Tuesday’s prompt change made things worse. Roughly 80% software engineer, 20% applied ML intuition. They rarely touch a training loop.<\/p>\n\n\n\n

    ML engineer.<\/strong> Trains, fine-tunes, and serves models: feature pipelines, labeled datasets, offline\/online metrics, drift, retraining cadence. Justified when you have proprietary data and a task where an off-the-shelf model genuinely underperforms: ranking, fraud, forecasting, pricing. If your “AI feature” is a chat interface over your docs, this is not your hire.<\/p>\n\n\n\n

    Research scientist.<\/strong> Invents new modeling approaches, publishes, runs experiments with no guaranteed ship date. Valuable when the model is<\/em> the product. Expensive, slow to yield, and mismatched to a company that needs revenue in two quarters.<\/p>\n\n\n\n

    AI platform \/ MLOps engineer.<\/strong> Owns the substrate: inference serving, GPU cost, model gateways and routing, caching, prompt versioning, tracing, guardrails, deployment and rollback. Their KPI is cost per request and p95 latency, not model accuracy.<\/p>\n\n\n

    Role vs. stage: who to hire first<\/h2>\n\n\n
    Stage<\/th>Hire first<\/th>Hire second<\/th>Do NOT hire yet<\/th>Realistic first-year output<\/th><\/tr><\/thead>
    Pre-PMF (seed, <20 eng)<\/strong><\/td>AI\/LLM application engineer<\/td>Second application engineer<\/td>ML engineer, research scientist, platform<\/td>3-6 shipped AI features, a basic eval harness, a killed idea or two<\/td><\/tr>
    Series A\/B (20-150 eng)<\/strong><\/td>2-4 application engineers + an evals\/data owner<\/td>AI platform engineer, once spend or latency hurts<\/td>Research scientist<\/td>Eval-gated releases, cost per request down 40-60%, first fine-tune if data justifies it<\/td><\/tr>
    Enterprise (150+ eng)<\/strong><\/td>AI platform team<\/td>ML engineers per business domain<\/td>Research, unless AI is the product<\/td>Shared inference layer, governance, dozens of teams shipping safely<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    The pattern is boring and consistent: capability before infrastructure, infrastructure before science.<\/strong> Companies that invert it burn a year.<\/p>\n\n\n

    Pre-PMF: one product engineer fluent in LLM APIs<\/h2>\n\n\n

    The bottleneck here is not model quality. It’s that you don’t know which AI feature is worth building. Your hire needs to ship five variants in six weeks, instrument them, and tell you which one users pull on.<\/p>\n\n\n\n

    Hire a senior product engineer<\/strong> who has shipped LLM features to real users. Concretely: they’ve built a RAG pipeline and can explain why the retrieval query rewrite mattered more than chunk size; they’ve had an agent loop spin into infinite tool calls in production; they keep 50-200 test cases with expected behavior and run them before merging. That last one is the strongest signal here, because most candidates who “work with AI” have never built an eval and ship on vibes.<\/p>\n\n\n\n

    What not to hire: a PhD who wants to fine-tune a 7B model on your 4,000 support tickets. That takes a quarter, costs more than the API calls it replaces, and leaves you a model to maintain. Skip the platform hire too: your infra is an API key and a vector store.<\/p>\n\n\n

    Series A\/B: evals become a job, platform becomes a bottleneck<\/h2>\n\n\n

    Two things break here. Quality regressions go invisible: twelve prompts across four features, three load-bearing for a named customer, and nobody knows when one degraded. And the bill arrives: inference spend that was rounding error at seed is now a line the CFO asks about.<\/p>\n\n\n\n

    So hires two and three are someone who owns evaluation and data<\/strong> (offline eval sets, LLM-as-judge with human spot checks, trace sampling, labeling workflow), then an AI platform engineer<\/strong> when latency or cost genuinely hurts. Note the order: platform work without evals just makes bad output cheaper.<\/p>\n\n\n\n

    This is also the first stage where an ML engineer<\/strong> may be justified, against a specific test: do you have proprietary data, a measurable task metric, and evidence a general model underperforms on it? If you can’t state all three in one sentence, you’re buying a title. The realistic JD reads: “You’ll own the eval harness for our agent workflows, cut p95 latency below 2s, and reduce cost per resolved ticket by 40%.”<\/em> That’s a role. “Drive our AI strategy” is not.<\/p>\n\n\n

    Enterprise: platform and governance before models<\/h2>\n\n\n

    Large organizations have the opposite problem: plenty of data scientists, nothing in production. The gap is almost never modeling talent. It’s that there’s no paved road: no shared inference gateway, no approved model list, no cost attribution, no tracing, no rollback for a prompt change, and a security review that takes eleven weeks because nobody answered the data residency question once.<\/p>\n\n\n\n

    So the first AI hires at enterprise scale are platform engineers<\/strong>, not modelers. Build the road, then let each domain add application engineers on top of it. Domain ML engineers come after, attached to specific P&L outcomes. Research stays out unless AI is literally your product, and even then it belongs in a separate org with a separate time horizon.<\/p>\n\n\n

    Write the JD around the artifact, not the buzzwords<\/h2>\n\n\n

    Three-line test before you post. One:<\/strong> name the artifact the hire ships by month three. Two:<\/strong> name the metric it moves. Three:<\/strong> name what they will not<\/em> do. A JD listing “LLMs, RAG, agents, fine-tuning, MLOps, PyTorch, distributed training” describes four people, and strong candidates will read it as a company that doesn’t know what it wants, accurately.<\/p>\n\n\n\n

    Drop the PhD requirement unless you’re hiring research: it filters out the strongest application engineers and attracts candidates whose instinct is to research a problem you needed shipped. And keep the level honest: a great LLM application engineer is a senior product engineer with a specific extra skill set<\/strong>, priced as such, not as a scarce researcher.<\/p>\n\n\n

    Interview signals that separate the four roles<\/h2>\n\n\n

    Interview for the job you’re hiring, not for “AI knowledge” in the abstract.<\/p>\n\n\n\n

      \n
    • Application engineer:<\/strong> hand them a broken RAG pipeline or a flaky agent and watch them debug. Ask how they’d evaluate a summarization feature, and what they’d do when the eval and user complaints disagree. Ask about a time they removed AI from a feature because a SQL query worked better. Good ones have that story.<\/li>\n
    • ML engineer:<\/strong> dataset construction, leakage, offline-vs-online metric divergence, retraining triggers. Ask what happened the last time a model did worse in production than in the notebook.<\/li>\n
    • Platform engineer:<\/strong> cost per token per feature, routing and fallback across providers, caching, tracing a slow request end to end, rolling back a bad prompt version.<\/li>\n
    • Research scientist:<\/strong> research taste: what they’d try next and why, on a problem with no known answer. Publications are context, not proof of usefulness.<\/li>\n<\/ul>\n\n\n\n

      For LATAM hiring this taxonomy matters even more, because the pool is deep and badly labeled: many senior product engineers who have shipped LLM features in production (exactly what most US teams need) and far fewer research scientists. Write the req for the first group and you fill it in weeks. Write it for the fourth and you stay open for months, then blame the market.<\/p>\n\n\n

      Frequently Asked Questions<\/h2>\n\n

      Do we need an ML engineer if we’re only using LLM APIs?<\/h3>\n\n\n

      Almost certainly not. If your work is retrieval, prompting, tool use, and evals against hosted models, that’s application engineering. Bring in an ML engineer when you have proprietary data plus a task where a general model demonstrably underperforms, and you’re ready to own a retraining pipeline indefinitely.<\/p>\n\n\n

      Should our first AI hire be a manager or an individual contributor?<\/h3>\n\n\n

      An IC, and a senior one. When you’re still defining the first AI features, the scarce thing is someone who can ship and make judgment calls in code, not coordinate a team that doesn’t exist yet. Add leadership past three or four AI engineers.<\/p>\n\n\n

      Can a strong backend engineer become an AI application engineer?<\/h3>\n\n\n

      Frequently, yes. It’s one of the better internal moves available. The gap is usually evals and probabilistic thinking, not the API surface. Give them a real feature with an eval suite as the deliverable; three months is a reasonable ramp for a senior who already knows your product and data.<\/p>\n\n\n

      What’s the single strongest signal in an AI engineer interview?<\/h3>\n\n\n

      Whether they can describe how they measured quality. Candidates who ship on vibes talk about prompts they wrote. Candidates who ship reliably talk about the test set they built, the failure modes they catalogued, and the regression an eval caught before customers did.<\/p>\n\n\n

      When does a research scientist actually make sense?<\/h3>\n\n\n

      When the model itself is your differentiated product, you have a multi-year horizon, and there’s a genuine open problem in your path. For most companies buying AI capability that isn’t the situation, and the hire will be under-utilized and gone within eighteen months.<\/p>\n","protected":false},"excerpt":{"rendered":"

      Reading Time: <\/span> 6<\/span> minutes<\/span><\/span>“AI engineer” is four different jobs in one title. Here is which one you actually need, in what order to hire, and how to write a JD that fills.<\/p>\n","protected":false},"author":2,"featured_media":19,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[6],"tags":[],"class_list":["post-336","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hiring-challenges"],"_links":{"self":[{"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/posts\/336","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/comments?post=336"}],"version-history":[{"count":6,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/posts\/336\/revisions"}],"predecessor-version":[{"id":403,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/posts\/336\/revisions\/403"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/media\/19"}],"wp:attachment":[{"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/media?parent=336"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/categories?post=336"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/tags?post=336"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}