What Humanoid Robot Companies Look For in Software Engineers

Humanoid robot companies hire software engineers who can show they made hardware behave under timing pressure, not the candidates with the longest framework keyword list. Interviews circle one machine you owned end to end, so explaining why a leg oscillated matters more than whether you used ROS 2 or HORUS. That flips at large integrators, where a named framework filters applications before a human reads them. The rest of this post is for software engineers deciding what to learn or build next in order to reach a humanoid team.

You have watched the demo videos and read the funding announcements, and you have concluded, correctly, that these companies are hiring. Then you open a listing and it asks for whole-body control, contact-rich manipulation, real-time systems, C++, Python, and five years of shipping robots, and you have written web services for six years and a line-follower once.

The advice you find does not agree with itself. One person says nobody gets in without a controls background and a doctorate. Another says the whole field is short of good software engineers and will take anyone who can write correct concurrent code. A third tells you to learn the framework every listing names and stop worrying.

Meanwhile you cannot tell what the job actually is. Some of these roles look like machine learning. Some look like embedded firmware. Some look like the distributed systems work you already do, only the servers are legs. You do not know which one you would be good at, and you do not know which one to spend the next six months preparing for, because each one costs the same six months.

What do humanoid robot companies actually look for in a software engineer?

They look for evidence that you made a physical machine do something repeatable and understood why it worked. Humanoid teams are small relative to the problem, so every hire has to close ground rather than occupy a slot, and the fastest predictor of that is what someone has already made move. The recruiter screen still runs on keywords. Past it, an engineer talks to you, and that conversation almost always becomes a story about something that broke. A candidate who says the arm stopped before it hit the table because the limit check ran inside the control cycle rather than in the planner, and who can say how they found that out, is more convincing than a candidate listing five frameworks. The unstated question underneath every interview is whether you have felt the difference between code that is correct and a machine that is safe. Those are not the same skill, and only one of them is visible on a CV.

What is humanoid robot software engineering in plain terms?

It is the work of keeping a machine with many joints upright and useful while several programs disagree about what time it is. A humanoid has legs that must catch it, arms that must not crush what they hold, and cameras producing pictures already slightly out of date by the time anything reacts to them. The software is stacked: drivers talking to motors, a control layer deciding joint commands many times a second, a planning or policy layer deciding what the body should attempt, and perception feeding both. The humanoid difference is that nothing is stable by default. A wheeled robot that stops is sitting still. A biped that stops is falling over, and the fall costs a knee actuator and a week. That fact reshapes the software: errors cannot be handled by halting, late data cannot be handled by waiting, and every layer needs defined behaviour for the case where the layer above goes quiet. Which is why these teams care so much about timing and so little about elegance.

What skills can you actually build toward, and which ones do these companies hire for?

There are about eight tracks you can invest a year in, and humanoid teams hire from all of them, weighted differently and opened at different points in a company's life. You can go deep on the ROS 2 ecosystem and its tooling. You can learn whole-body control and rigid-body dynamics properly. You can specialise in learned policies and the data pipelines behind them. You can work on embedded firmware and motor drivers. You can build simulation and evaluation infrastructure. You can do hardware bring-up and test rigs. You can build teleoperation and data-collection tools. And you can do systems work underneath all of it: ROS 2 is the largest robotics ecosystem and the name most humanoid listings print, while HORUS is an open-source real-time robotics middleware for Rust, Python and C++ where the three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised — exactly the problem when a Python perception program and a compiled control loop share one onboard computer. Read the table as descriptions of candidates, not a ranking.

What should you build if you are coming from web or backend software?

Build one machine that moves, keeps moving, and recovers from something you do to it on purpose. Your background is worth more than you think and less than you hope. Worth more, because humanoid stacks are distributed systems with actuators attached, and you already understand processes, queues, backpressure, and what happens when a component stops answering. Worth less, because your instincts about failure are wrong in a specific way: in a web service, when something is uncertain, the correct move is to retry or return an error. On a legged robot, stopping is a fall and retrying is a delay you cannot afford. The project that converts your existing skill fastest is a small mobile or legged robot, or a two-joint arm, where you deliberately break something while it runs — unplug a sensor, saturate the computer, delay a message — and make the machine degrade instead of collapsing. On how transferable your existing habits are, see from web developer to robotics developer.

What hardware do you need before a humanoid team takes you seriously?

Far less than a humanoid, and considerably more than nothing. Nobody expects an applicant to own a bipedal robot, and hiring managers know the price of one. What they want is evidence you have dealt with the properties a humanoid has, and several of those are available cheaply. A small legged robot, a hobby arm with real servos, a balancing two-wheeler, or a quadruped kit all present the same class of problem: gravity does not wait, actuators have limits, sensors lie a little, and something must run on time or the machine misbehaves. A balancing robot on a desk is a good demonstration, because balancing is the humanoid problem in miniature and it fails visibly. Pure simulation counts too, but only if the simulated machine faced uncertainty — a push, a delay, a noisy sensor, a failed motor — because a scene where nothing goes wrong proves only that you can configure a simulator. Spend on actuators before computers. The one you already have is almost always enough.

What if your job search starts next month?

Then stop learning new things and finish one thing, because a month is enough to present work and not enough to acquire a specialty. Take the most complete robot project you have, get it running again, record an uncut video of it working, and write down what does not work yet. Then read the listings you want and match your vocabulary to theirs — if they say whole-body control and you say inverse kinematics, a human will connect those but a keyword filter will not. Apply to smaller companies as well as famous ones, because a team of a dozen engineers reads every application and a team of hundreds does not. Prepare one story in detail: a failure, how you localised it, what you measured, what you changed, and what you would do differently. Interviewers here spend most of the technical conversation there. In a month you can also fix a real bug in an open-source robotics library and get it merged.

What if you have never written code that touches a motor?

Start with a motor and a loop this week, because the gap between reading about control and running a loop is the entire gap. Buy a hobby servo or a small geared motor with an encoder, connect it to a microcontroller or a single-board computer, and write a program that moves it to a commanded position and holds it there against your hand. That is a control loop, and the moment you feel it push back you understand something no course conveys. Then break it deliberately: make the loop run irregularly and watch the motion turn rough, add a delay in the sensing path and watch the machine oscillate, command something past the actuator's limit and see what happens when reality clips your intentions. This takes a couple of weekends and converts the vocabulary in job listings into things you have seen. Only then does picking a framework make sense, because a framework organises loops you now understand rather than substituting for them.

What does a strong-looking application look like when it quietly fails?

It looks like a candidate with impressive coursework, a simulation video, and no answer to the question of what went wrong. The application clears every filter: right languages, right framework named, a project with a robot in it. Then the engineer on the call asks how the robot handled a case the candidate did not design for, and the answer is that the situation never came up. It never came up because the project ran in a scene with no disturbance, or because the video is the one attempt in twenty that worked and the other nineteen were never diagnosed. Interviewers detect this quickly, not because they are suspicious, but because a person who has debugged a machine talks differently about it — they mention the thing that took a week, the measurement that turned out to be lying, the moment they realised two parts of the system disagreed about time. A polished application with no scar tissue reads as untested, and untested is what a small team cannot afford.

What do candidates try first, and why does it stop working?

Most candidates start by collecting frameworks and tutorials, and it stops working the moment an interviewer asks a question that has no tutorial. The pattern is understandable: listings name technologies, so acquiring technologies feels rational, and every one comes with a course that ends in something moving on screen. What that produces is breadth with no incident history. Six tutorials leaves you able to reproduce six known-good outcomes and unable to diagnose one novel failure, which is the actual job. The second common approach is to go straight at the hardest topic — dynamics, contact modelling, reinforcement learning for locomotion — and stall three weeks in because the maths assumes background you were going to acquire later. What works is unglamorous: one modest machine, carried past the point where it works in the demo and into the region where it works while you are actively disturbing it. That takes longer than a tutorial and produces the only material an interview can be built from.

What do you give up by specialising in low-level control?

You give up mobility between companies and a good deal of optionality outside robotics. Being the person who owns the control cycle is valuable and scarce, and scarcity is the point — but it comes with costs few people name. Your skill becomes tied to a smaller number of employers, and humanoid companies are a young sector where funding, direction, and headcount all move quickly. The work is also physically located: you cannot bring up a leg from a laptop in another country, so remote options shrink. And the deeper you go into timing, actuators, and safety limits, the less of your experience translates back into ordinary software work if you ever want to leave. The alternative specialisations — simulation infrastructure, data tooling, perception, teleoperation interfaces — carry more of their value outside the sector and are easier to move with. That is a trade, not a warning. Make it deliberately rather than drifting into it because the control roles sound the most like robotics.

When is ROS 2 the better choice?

ROS 2 is the better choice for most people trying to get hired, and pretending otherwise would cost you interviews. It is what humanoid listings name, what university courses teach, and what most candidates and interviewers share as a vocabulary. If your goal is to be legible to a hiring pipeline in the next six months, learn ROS 2, build in ROS 2, and say ROS 2 on your CV. It is also the right technical answer for large parts of humanoid work: navigation, coordinate frames, visualisation, mapping, and an enormous body of existing drivers, none of which a smaller project matches. HORUS is not the answer for a candidate whose main constraint is being found by recruiters, nor for a project that needs that existing ecosystem. The systems track only becomes the right bet once you are aiming at a specific team's specific pain — usually a Python program and a compiled control loop competing for one onboard computer. For a general job hunt, the wide door is the right door.

Do you need to have worked on a humanoid before a humanoid company will hire you?

No, and here is why: almost nobody currently employed at these companies had worked on a humanoid before arriving, because there were not enough humanoids to go around. The field grew faster than its own talent pool, which is why these teams hire from adjacent domains. They screen for the class of problem rather than the form factor. A drone taught you control under timing pressure with no option to pause. A robot arm taught you kinematics, contact, and safety limits. A quadruped taught you legged locomotion and recovery. What does not translate is experience that assumes stopping is safe: industrial automation on a fixed line, or software that only ever ran in simulation with no disturbance. If that is your background, the gap is small and closable, and closing it means one project where the machine stays upright while you interfere with it. See also why humanoid robots are hard on the software side.

Is a machine learning background what these companies want most?

Partly, but not the way you think. Learned policies matter at humanoid companies and the roles around them are real and well paid — but the ratio of machine learning roles to everything else is far lower than the public conversation implies, because a demonstration is mostly about the model and a product is mostly about everything holding the model up. For every engineer training a policy there are several making sure images reach the policy on time, that commands reach the joints, that the machine does something defined when the policy produces nonsense, and that failures are recorded and reproducible. There is also a trap in the pure machine learning route: without hardware exposure you end up excellent at improving a number in an evaluation harness and unable to say why the improvement disappeared on the real machine. The strongest candidates here have felt that disappointment and gone looking for the cause. On what these models can and cannot do once embodied, see what a robot foundation model is.

How do you decide what to work on next?

Decide by what you already have, not by which track sounds the most like robotics. Take an honest inventory: your strongest skill, the hardware within your budget, how long before you need income, and whether maths energises or drains you. Then pick the track where your existing skill is an advantage rather than an irrelevance, because you are competing against people who started earlier and the only way to arrive with a lead is to bring something from before. Test the choice cheaply: spend two weekends on the smallest project in that track and notice whether you keep going past the point where it stops being fun. That signal beats any amount of planning, because every one of these tracks is hard enough that interest is what carries you through. Then commit to one project long enough to break it, fix it, and describe both.

Decide by situation rather than by ambition:

• If you are applying within weeks -> finish and document the project you already have, because presentation is the cheapest value on the table.
• If you come from backend or distributed systems -> build a small machine that degrades instead of stopping, because that is the instinct these teams check for.
• If you already train models -> learn the loop underneath them, because the gap between a good evaluation score and a working machine is where these teams hurt.
• If your budget is small -> build a balancing robot, because balancing is the humanoid problem in miniature and it fails where people can see it.
• If listings are your bottleneck -> build in ROS 2, because being legible in seconds beats being unusual.

When two projects stay close, weigh the tools you would build them on against the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target, and licence. Take the one that loses on the fewest — five honest questions about your situation rather than scores about the software. If your next project puts perception in Python and a control loop in a compiled language on one small onboard computer, star HORUS on GitHub so it is in your list when you start building.