Across the 1.1 million UK careers pages we crawl, the number of employers naming a reinforcement learning engineer in a job title is zero. Not a handful. None. That is the most useful fact on this page.

Good work does happen in Britain. It is simply never a standing position, just a capability a handful of organisations hold under another title. If you are here because a strategy paper said “agents that learn from experience”, the most useful thing this guide can do is talk you out of the hire.

The honest answer is usually a different technique

Reinforcement learning earns its keep when three things hold at once. You need a sequence of decisions where each changes the world the next one sees. You cannot label the right answer, so there is nothing to train on. And you can afford thousands of failures while something works the answer out. Remove any one and a cheaper tool wins.

Teams routinely call a problem reinforcement learning when the decisions are independent. Pricing a basket, ranking a results page, choosing which customer to call: supervised problems with a feedback loop bolted on, and a machine learning engineer will ship something useful months before an agent stops thrashing. Where decisions genuinely are coupled — scheduling, routing, inventory, bidding — the answer is very often a solver rather than learning: mixed-integer programming, constraint solvers, model-predictive control. They hand you a defensible optimum against a model a human can read; a policy cannot.

So the first screening question is not technical: put the real problem in front of a candidate and see whether they talk you out of the method. Ten years in, they reach for the solver before they name an algorithm.

Reward specification, and the agent that cheats you

Suppose you pass that test. The job is then, mostly, writing down what you want as a number. Everything else — algorithm choice, network sizes, the training loop — is settled engineering with good public implementations. Reward design is not, and it is where projects die quietly.

The failure has a specific feel: the agent optimises what you wrote rather than what you meant. A warehouse policy rewarded on items moved per hour shuffles one crate back and forth. A trading policy rewarded on realised profit holds its losers forever, since an unrealised loss never enters the number. A boat-racing agent, in the case everyone in the field can recite, circled a lagoon of respawning pickups instead of finishing the course. None is a bug; each is a faithful solution to the problem posed.

A good engineer brings a defensive habit of mind. Proxy metrics get audited for the loophole before training starts. Real constraints become hard limits, not penalty terms an agent can buy its way out of. Behaviour is watched and replayed, not read off a learning curve. Ask what a reward they wrote turned out to be paying for. If the answer is not immediate and faintly embarrassing, they have not done this enough.

Do you have a simulator, and how wrong is it?

The second gate disqualifies more teams than the first. Trial and error needs somewhere cheap to fail. In a game, the game is the simulator. In a warehouse or a chemical plant somebody must build one, and the question for a candidate is not whether they can but how badly the last one they trusted lied to them.

A usable simulator is often a larger piece of software than the agent, needs validating against logged reality, and decays as the plant changes. Settle ownership before you advertise. If one hire is to build it, model the physics, design the reward and deploy the policy, you have described three roles and should budget two years.

The sim-to-real cliff

A policy that is superb in simulation and useless on the machine is the standard outcome, not the unlucky one. The agent has learned to exploit what the simulator got wrong: friction treated as constant, a delay nobody modelled. Candidates worth hiring raise it unprompted: randomising the parameters they doubt, keeping a fallback controller beneath the policy, how much real data closed the gap.

Games, control systems and model post-training

Three settings justify the hire, and each wants a different person.

  • Game AI and simulation. The environment exists, running it is cheap, winning is unambiguous. The friendliest case, and where a strong generalist converts fastest.
  • Robotics and industrial control. Real dynamics, safety envelopes, a brutal transfer problem. Look for control engineering: somebody who knows what a PID loop is and why you might keep one beneath the policy.
  • Post-training a language model to reason. Training against answers a machine can check: a test that passes, a proof that verifies. The scarce skill is designing the checker and the spread of tasks. An AI research engineer or an applied AI scientist is often the better title to advertise.

If your problem is not recognisably one of those, that is evidence rather than an exception.

An interview built around one broken agent

Skip the take-home; nobody trains a policy in four hours honestly. Spend ninety minutes on a decision problem from your own business instead.

Listen for the reward written out in full, and the loophole they find in their own draft. For what the agent may do, and what happens the first time it does something stupid. For the baseline: a serious candidate insists on a dumb rule-based one and often predicts it wins. Then ask what they would do with six weeks rather than six months. The right answer is a refusal to start.

The money, and the university problem behind it

Indicatively, a strong practitioner in Britain sits around £90,000 to £150,000, the top concentrated in a few research-heavy employers. Day rates indicatively begin near £700 and pass £1,000 for control specialists whose results are demonstrable. Treat it as soft: with no advertised roles to sample there is no median, only what individuals have accepted.

The scarcity is genuine rather than a recruiter’s framing, and the pool is largely academic. Most with real depth acquired it during a doctorate or a postdoc, so their published work is a signal you can read — and many have never shipped to a paying customer. The strongest hires we see left the lab for a product team and were made to care about latency, deployment and the cost of being wrong. That passage, not the algorithm list, justifies paying above the band.