Hiring for vLLM is almost always a symptom of one decision: you have stopped paying an API provider per token and started serving open-weight models yourself. That changes what the role is. You are not hiring somebody to make a model cleverer — you are hiring somebody to make a fixed amount of GPU produce more answers per pound, without the quality moving.

It is a narrow, measurable and unusually verifiable job, and the interview should reflect all three.

Work out whether self-hosting is actually your problem

Before the advert, do the arithmetic. Self-hosting wins on cost at volume, and loses on almost everything else: you take on capacity planning, GPU availability, upgrades, and being the person who is paged when generation stalls.

The rough shape of the decision is that a provider API is cheaper until your request volume is steady and high enough to keep accelerators busy, and self-hosting becomes compelling when you are running the same model constantly, when your data cannot leave your infrastructure, or when you need a fine-tuned model served at production latency. If you are self-hosting to save money on bursty, low-volume traffic, you will spend more in idle GPU than you saved in tokens, and no engineer can fix that for you.

Being honest about which of those you are in will tell you whether you need a full-time hire or six focused weeks of contract work. A surprising number of these engagements should be the latter.

The concepts the interview should actually cover

This is a domain where the vocabulary is shallow and the understanding is not, so ask about mechanisms rather than settings.

Paged attention and why memory is the bottleneck. The central insight of the tooling is that key-value cache memory, not compute, is what limits how many requests you can serve at once. A candidate who understands that talks about cache utilisation and eviction; one who does not talks about GPU model names.

Continuous batching. Ask what happens to a short request that arrives behind a long one. Strong answers explain that requests join and leave a batch as they finish rather than waiting for the slowest, and why that transforms throughput under mixed traffic.

The latency pair. Time to first token and inter-token latency are different numbers with different causes, and a user notices them differently. Anybody who has run a streaming interface knows this without prompting.

Quantisation, with a caveat. Ask what they would check after quantising a model. The answer you want involves measuring quality on a task-specific set, not quoting a benchmark — the whole risk of quantisation is that it looks free until it is not.

Ask for the numbers, then ask how they got them

This role produces figures, which makes it one of the easier technical hires to assess honestly. Ask for tokens per second, requests per second at a given latency ceiling, accelerator utilisation, and cost per million tokens — before and after their work.

Then ask how the benchmark was constructed. This is where weak candidates come apart: throughput measured on identical short prompts is meaningless, because real traffic has a distribution of input and output lengths, and a batching strategy tuned on uniform requests falls over on mixed ones. A candidate who volunteers that their load test was built from production traffic shapes is telling you they have been wrong about this before, which is exactly what you want.

Where this role goes wrong after the hire

  • Optimising the wrong end. Weeks spent on serving throughput when the actual latency was in a retrieval step or a slow tool call. Insist on an end-to-end trace before anybody tunes anything.
  • Quality regressions nobody measured. A quantisation or a sampling change ships, cost falls, and three weeks later somebody notices the outputs got worse. The engineer should build the quality gate before they need it.
  • Capacity that only works on a quiet day. Configurations tuned at median load and never tested at peak, so the first busy afternoon queues.
  • A single point of knowledge. Serving stacks accumulate undocumented tuning. If one contractor leaves with all of it in their head, you have bought a liability.

What it pays, and the honest state of the market

Indicatively, £90,000 to £140,000 permanent for somebody genuinely strong, and day rates from around £650, higher where the work involves multi-node serving or unusual hardware.

The reason those bands are wide is worth stating: across the UK careers pages we index, only around 120 employers name the tool at all, against roughly 1,200 for PyTorch. There is no reliable benchmark for a title this new, and anybody offering you a precise median has derived it from something else. The practical effect is that candidates price themselves against what they could earn as a general infrastructure or platform engineer, so that is the number to know before you open the conversation.

The adjacent hires to consider instead

Two alternatives are often better value. If the real problem is cost and capacity across your whole stack rather than one serving layer, an AI infrastructure engineer covers more ground and the pool is deeper. If the model is fine but the answers are wrong, the problem is upstream of serving entirely and you want a RAG engineer instead.

Serving specialists are worth hiring when the serving layer is demonstrably the constraint, and you should be able to show that with a trace before you advertise.