Before you hire an LLM engineer, there is one question most teams skip: what specific mix of skills does this application need? Skip that question and you hire the wrong person, then spend three months finding out.
What the wrong hire looks like
Two patterns appear with some regularity.
The first: you hire someone with an ML research background, strong publications, possibly a PhD. When teams decide to hire a machine learning engineer for LLM work, they often see this profile and assume that research depth translates to product delivery. In the first quarter, this person spends most of their time choosing between frameworks, building an evaluation harness, and documenting a model selection process that has not been tested on real traffic. Nothing ships. When you ask for a timeline, the answer involves more evaluation.
The second: you hire a solid backend engineer who has not worked with language models before. Strong systems instincts, clean code, good judgment on the architecture side. In the first quarter, they iterate on prompts by trial, run without a feedback loop, and never converge on stable output. The system works on the examples in the ticket and fails on the first round of live traffic.
Both of these are competent people in the wrong role. The ML researcher knows how to train and evaluate. They may not know how to ship against a product deadline, or how to manage a prompt pipeline in a production system that cannot afford to be rebuilt between evaluations. The backend engineer knows how to build systems. They may not know how language models fail or how to diagnose failure when it is quiet and the user just closed the tab.
Both failures trace back to the same source: a job description written before anyone answered the real question. What does this application actually require, and which part of that skill mix will be harder to find?
What this role actually covers at a small company
At companies that train or fine-tune frontier models, an LLM engineer works on a narrow slice of the stack: training pipelines, serving infrastructure, or evaluation at scale. Those are real jobs. They are not the jobs at the kind of company you probably run.
At a ten-to-three-hundred-person company, one person covers more ground:
Connecting the model to existing systems. Not calling an API in isolation, but wiring the language model into a product that already has data, users, and state. Custom LLM integration in practice shows what that scope of work looks like.
Writing and version-controlling prompt pipelines. A prompt is not a constant. It changes as the product changes, and without version control, a change made in production is untraceable when output degrades. There is no rollback, no audit trail, and no way to isolate whether the problem is the prompt, the model, or something upstream.
Wiring observability so bad output is visible before it reaches users at scale. Production language model failures are often quiet. A user gets a wrong answer, closes the session, and churns. Semantic drift, where outputs shift in tone or accuracy without any code change, can run for days before it shows in product metrics. Good observability catches the pattern before the damage compounds.
Choosing the model and the provider, and knowing when to switch both. Understanding cost and latency tradeoffs well enough to make the call without a lengthy evaluation cycle.
Testing on real data. Not a set of examples constructed to illustrate a use case, but real traffic with the edge cases that only appear in volume.
The kind of integration work that connects these components, including the interfaces that let models take actions in other systems, is day-to-day work for this role. At a large company, these concerns belong to several separate teams. At yours, they belong to one person.
When to hire, when not to
The most useful frame is not "do we need AI capability" but "how much of this work is one-time versus ongoing."
If you decide to hire an LLM engineer, the timing question matters more than most teams realize. A full-time hire makes sense when the first version will generate enough ongoing operation and iteration that the person has real and varied work six months after the initial build. If the scope is "build one feature that uses a language model, then maintain it," you may be hiring a senior person into a limited role. That is a position that is difficult to fill well and difficult to retain.
An LLM engineer for hire, brought in for a defined scope rather than an open-ended role, is often the better fit when the work is predominantly one-time. When you hire an LLM developer this way, the engagement has a clear deliverable and a clear end, which is easier to staff, scope, and evaluate than an open requisition. Whether you then hire an AI engineer full-time depends on what the ongoing operation looks like. If most of the ongoing work is genuinely sustained, a contractor eventually costs more than a full-time hire over twelve months. That is the threshold worth modelling.
The market has also shifted over the past year, and it is worth naming that shift here. The pattern of commissioning a specific scope of work from an experienced practitioner has grown relative to the pattern of hiring a person for an open-ended role. Whether that shape fits your situation is a decision worth making deliberately, before a requisition appears. The full argument for that case belongs in a separate piece; here it is enough to name the fork.
What the role costs, honestly
Strong LLM engineers are priced near senior backend engineers, with a current market premium on top. There is no specific figure in this article because that number moves, and any figure you read today will not hold through the interview process.
The more useful cost to think about is the cost of the wrong hire. If you hire someone who cannot deliver for this role, you lose roughly three to six months before the evidence is conclusive enough to act on. During that period, product decisions are deferred because the system is not reliable. Engineering teams build workarounds. Dependent features wait on an integration that keeps changing. When you finally act, you restart the recruitment cycle: sourcing again, interviewing again, then another onboarding period before the replacement is operating at full capacity. None of that cost appears in the salary line.
Frame it this way: the cost of the right hire is predictable. The cost of the wrong hire is not, and it is usually larger.
Five questions before you make an offer
Technical screens for this role tend to favor credentials over demonstrated shipping ability. These five questions filter differently.
- Show me a live system you have shipped, and walk me through where it goes wrong in production.
You are not looking for a flawless system. You are looking for someone who has watched a language model fail in production and can describe that failure specifically. A candidate who has not shipped one will describe what they would build, not what they observed.
- How do you decide when to switch models or providers on a system that is already running?
A candidate who has not done this will give you a theoretical answer. A candidate who has done this will name a specific decision, the signal that triggered it, and what they changed as a result.
- How do you keep operating cost visible on a system where token usage varies per request?
Token usage is the variable cost of a language model system and it is easy to ignore until the bill arrives at the end of the month. A good answer describes instrumentation and alerting built into the system, not an intention to monitor it.
- When the model returns something outside expectations, what does your code do next?
This is about defensive architecture. The failure surface of a production language model system is wider than most teams expect, and a candidate who has not thought through it will not have an answer that goes beyond catching the exception.
- What would you refuse to build if we asked you to, and why?
This is a judgment question. You are looking for a candidate who can articulate what makes a system any team can service six months after it ships, not just a system that shipped on time and became opaque shortly after.
If you worked through these five questions and concluded that what you need is a specific system built rather than an ongoing hire, there is a direct option: one senior engineer, your codebase, a working system in roughly a week. Documented so any future developer can service it. No proprietary platform, no monthly fees to a platform you do not control, cost agreed before the work starts.
