Hire the Robot Learning Engineer Who Owns the Demonstration Data

The Policy Worked in the Lab and Failed at the Customer's Bench

The grasp policy succeeded nineteen times out of twenty in your lab. At the customer's bench it failed six times in twenty, and nobody on the team can say why, because the only artifact anyone kept was a video and a checkpoint file. The demonstrations came from two operators over four days, one of whom always approached the bin from the left. That is the failure a robot learning engineer is hired to prevent.

Four traits separate a real one from a strong researcher who has never shipped on hardware, and each has a tell you can check in one conversation.

The first is ownership of the collection rig. Ask what changed between version one and version two of their dataset. A real answer describes the physical setup: a different gripper, a fixed camera that moved, an operator instruction rewritten because half the episodes started mid-reach. A performed answer describes the architecture instead.

The second is counting. Ask for a success rate and then ask how many trials it rests on. People who have run hardware evaluations answer with a number, a protocol and a date, because they know twenty trials on a Tuesday afternoon is a hunch. They will also volunteer the failure taxonomy, since that is the artifact that tells you what to fix.

The third is knowing what not to learn. The strongest candidates can name a subtask they pulled out of the policy and handed back to a scripted controller or a motion planner, and they can name the reliability number that justified it. Enthusiasm for learning everything end to end is a research position, not an engineering one.

The fourth is what the robot does when the policy is unsure. Ask it plainly. Good answers describe a detection signal and a defined behavior: stop, retreat to a known pose, request a teleoperator. Candidates who have only worked in simulation often have no answer, because in simulation an uncertain policy just fails cheaply.

The category is still forming, which is worth saying out loud to candidates rather than pretending the job ladder exists. Figure AI's public board carries a whole Helix AI Engineer family split by Robot Learning, Reinforcement Learning, Video Pretraining, Perception and Training Performance, plus a Reinforcement Learning Engineer for whole body control, and Scale AI posts a Director of Engineering for Physical AI ¹. That is a handful of employers defining the role in public, not a settled profession.

Which Backgrounds Produce a Robot Learning Engineer Who Ships on Hardware?

Reinforcement learning and computer vision researchers are the obvious feeder and convert well when they have touched a real robot. Classical controls engineers convert better than the discourse suggests. The unexpected sources are the ones worth opening: simulation and game physics engineers, data infrastructure engineers, and the teleoperation operators who collected somebody else's dataset.

The research case is straightforward and comes with a known risk. Someone from an imitation learning or offline reinforcement learning background already has the vocabulary and the training instincts. What they often lack is patience for the physical loop, where an experiment costs a day of robot time and a broken finger joint costs a week. Ask what their longest gap was between having an idea and seeing it run on hardware.

Controls engineers arrive with the thing researchers most often miss: an internal model of what the machine can actually do. They know the actuator limits, the latency budget, the safety interlocks and the difference between a trajectory that looks smooth on a plot and one that will not shake the mount loose. Their gap is statistical thinking, and it is teachable. A controls engineer who has already retrained on modern policy learning is one of the strongest profiles on the market and one of the least advertised.

Simulation engineers are underrated because their work looks like tooling. Someone who built domain randomization for a physics engine has spent years on exactly the question that decides whether a policy transfers, and they usually have opinions about which parts of a simulator lie.

Data infrastructure engineers are the surprise. A large share of this job is a pipeline: many hours of multi-camera video plus joint states plus operator annotations, versioned, deduplicated, and joined to evaluation results months later. Someone who has run that kind of pipeline elsewhere solves a problem your researchers will otherwise solve badly in notebooks. The overlap with the AI infrastructure engineer is real, and on small teams it is the same hire.

Teleoperation operators deserve one line of their own. The people who collected thousands of episodes know which instructions produced clean data and which produced garbage, and a few of them have taught themselves training. That is a promotion path most robotics teams have not noticed they already have.

Ask How the Candidate Taught Themselves, Not Which Papers They Read

Ask directly how they got good, and listen for practice rather than reading. The answers worth hearing describe a loop the person ran on themselves: a policy that behaved confidently and wrongly, a check they now run every time because of it, and the specific moment that installed the habit. Papers are the cheap part of this field. Robot hours are the expensive part.

AI assistance shows up in the honest answers in a specific shape. Candidates describe using models to write the unglamorous half of the job faster: data loaders, kernel tuning, conversion between recording formats, a first pass at labeling video segments that a human then corrects. The good ones can also name where the assistance misled them. A model that confidently produces a coordinate frame convention, or asserts that a library's quaternion order matches another library's, will cost a week if nobody checks it against the hardware.

That check is the trait to probe, because it transfers to everything else. Ask what they do when a model, a paper or a teammate states something that would be expensive to be wrong about. Strong candidates describe going outside the conversation: running the calibration, printing the actual tensor shape, putting the robot in the pose and measuring it. Describing this habit is easy and performing it is not, which is why an interview alone reads it poorly.

On format, avoid the whiteboard architecture round. It rewards vocabulary, and a candidate who says behavior cloning plus a diffusion policy head plus action chunking may have trained six policies or read one thread, and both transcripts look the same. Better: hand over a real dataset with a known defect, some evaluation logs, and half a day. Ask what they would collect next and why. The answer separates people fast, and it is the same judgment the job requires on the first Monday.

Find Robot Learning Engineers Where Failed Rollouts Get Discussed

Look where hardware results get posted rather than where robot demos get announced. Academic venues remain the densest pool: the Conference on Robot Learning, Robotics: Science and Systems, and the workshop tracks at ICRA are where this population actually gathers, and workshop attendance is a better filter than the main track because that is where negative results get discussed.

Open source is the second route and the cheapest. Robot learning has a real public codebase and public datasets, and the people filing detailed issues against them, with a hardware setup described and a reproduction attached, have demonstrated more than a portfolio site does. So has anyone who published an evaluation writeup saying which policy failed and how it was measured.

For direct outreach, the adjacent titles are perception engineer, motion planning engineer, simulation engineer and machine learning infrastructure engineer, plus the automation engineers inside manufacturers who have deployed real cells and watched them break. Employers already posting the title in public are the obvious poaching ground and also the obvious competition ¹.

Closing this hire turns on access, not on pitch. The offer dies when the candidate works out that robot time is rationed by another team, that the data collection budget is a maybe, or that a hardware failure means a two-month wait for a part. It dies again when the publication policy is undefined and the candidate came from a lab.

Three things close it. Name the hardware they will have and how many hours a week of it are theirs. Name who owns the data collection budget and how a request gets approved. And be specific about what the role decides on its own, because this population has watched projects stall between a research group and a deployment group that report to different people. Where the deployment side is a separate function, say so and introduce them to the site AI engineer who will own the customer floor.

What Does a Robot Learning Engineer Cost, and Can the Work Be Remote?

No public wage series covers this title, and any point estimate you find was synthesized from a few postings by a few employers. The honest answer is qualitative: this role hires against your machine learning research engineer band, not your controls or mechatronics band, and the gap between those two bands is why teams that budgeted for the second one lose their finalists. Price it against the last competitive machine learning offer you actually closed.

The general wage pressure is documented even though this specific title is not. PwC's 2026 AI Jobs Barometer, analyzing roughly one billion job advertisements, reports an average wage premium of 62 percent for roles requiring AI skills ². Read that as background pressure rather than a band for this job. It says the direction of the market, and it says nothing about what a humanoid robotics startup in the Bay Area will offer your finalist next week.

Equity is a larger share of the package here than in most engineering roles, because a meaningful fraction of the employers defining the title are venture-funded companies at pre-revenue or early-revenue stage ¹. If you are an established manufacturer competing against them, compete on hardware access, data volume and shipping to real customers rather than on cash. Those are the things this population actually complains about not having.

On location, be blunt in the job posting. This work is substantially on-premise, because the robot is on-premise and evaluation means standing next to it. Teams that advertise fully remote and then require four days a week in the lab lose people in month two. The workable pattern most groups converge on is hybrid with an asymmetry: training runs, dataset work and analysis happen anywhere, while evaluation weeks and any new task bring-up happen at the robot. Say which weeks are which before the offer.

One planning note that is not legal advice. A learned policy on a machine that moves near people sits inside your site's existing machinery safety regime, and the safety case for a policy that was trained rather than specified is genuinely harder to write than for a scripted one. Bring your safety engineer into the role definition early, and check the applicable requirements for your jurisdiction and site with counsel rather than reasoning from a summary.

See a sample report >