How to Get Robotics Experience Without a Robotics Job

You get robotics experience by finishing one machine that runs unattended and merging fixes into projects other people use, not by taking more courses. Both produce something a stranger can check, which is the only credential that transfers when nobody has paid you. Whether you build on ROS 2 or HORUS matters less than whether the machine survives an hour unattended, unless one specific employer is your target. The rest of this post is for people who can already code, want into robotics, and have no robotics job to get the experience from.

Every listing asks for two to five years of experience with robots, and you have none, because nobody will give you any until you have some. You have read that paragraph in a dozen job adverts and it has stopped feeling like a hiring requirement and started feeling like a locked door.

Meanwhile you can code. You have shipped things. You have debugged systems under pressure at a job that has nothing to do with machines, and you suspect, correctly, that a fair amount of that transfers. What you cannot tell is which part, or how to prove it to somebody skimming a CV for eight seconds.

So you have been collecting courses. There is one you finished, two you did not, and a certificate that has never once come up in conversation. There is a folder of tutorials. There is a growing sense that this is not converging on anything, and that another course will not change that.

The question underneath all of it is simple and rarely answered directly: what actually counts, and what merely feels like progress?

Can you get real robotics experience without a robotics job?

You can, and a sizeable fraction of working roboticists did exactly that, because the field cares more about demonstrated ability than about where the hours were logged. Robotics has an unusual property that works in your favour here: the hard parts are visible. Anyone can watch a machine either work or fail, and no job title changes what the video shows. That makes it one of the few technical fields where an outsider can produce evidence indistinguishable from an insider's. The catch is that the evidence has to be genuine. Reading about control loops is not experience. Finishing a course is not experience. Getting a machine to run for an hour without you touching it, discovering it drifts after twenty minutes, and finding out why, is experience, and it is the same experience an employed engineer would have had. So the route is not a shortcut around the work. It is the work, done on your own time, in public. What you are missing without a job is not skill, it is scale, deadlines, and other people's opinions of your code.

What do people mean when they ask for robotics experience?

When a listing asks for robotics experience, it is asking whether you have handled the three problems that make machines different from software: time, physical failure, and uncertain sensing. Everything else in a robotics job is ordinary engineering. Those three are the ones that catch newcomers, and they are what an interviewer probes for. Time means your code has to finish before the next cycle needs it, so the arm keeps holding position rather than sagging. Physical failure means a cable comes loose, a motor overheats, a battery sags under load, and your program must notice rather than carry on confidently. Uncertain sensing means the readings are noisy, occasionally absent, sometimes stale, and always a little wrong. Nobody expects you to have solved these at industrial scale. They expect you to have met them at least once, in any form, and to have opinions about what you did. A candidate who has fought a machine that behaved differently every run has the experience being asked for, regardless of who paid for the parts.

What are the actual routes into robotics experience?

You have about eight routes, and they differ mainly in what they cost you: money, evenings, or the willingness to be visible while you are still learning. You can build a small robot at home. You can build entirely in simulation. You can contribute fixes to open-source projects other people run. You can write and maintain a tool or driver others come to depend on. You can move sideways at your current employer toward anything with motors in it. You can volunteer in a university lab or a competition team. You can take small paid automation work. And you can build a project deliberately around how robot programs talk to each other, which is where framework choice matters: ROS 2 is the vocabulary the field shares and carries the largest collection of existing robotics code anywhere, while HORUS is an open-source real-time robotics middleware for Rust, Python and C++ where all three languages share the same shared-memory ring buffers, so messages between processes on one machine are never serialised. Read the table as descriptions rather than a ranking.

What should you do if you already have a software job?

Look inside your current employer first, because the cheapest robotics experience available to most working developers is a sideways move nobody else wanted. Hardware hides in ordinary companies. Warehouses have conveyors and scanners. Labs have instruments with serial ports. Facilities teams have sensors reporting temperatures nobody reads. Manufacturing has machines with control software written a decade ago by someone who left. Every one of those is a system with timing, physical failure and uncertain sensing in it, which is the experience being asked for, and volunteering for it usually costs a conversation rather than a career change. When there is genuinely no hardware anywhere, use the other advantage a job gives you: money and stability. Buy the parts, protect two evenings a week, and treat the build as ongoing rather than heroic. Your existing habits are worth more than you think here, because a great deal of robotics code is written by people who never had to hand a system to a stranger, and the route from software into robotics rewards exactly those habits.

What hardware do you need before the experience counts?

Less than a decent phone, and possibly nothing. The floor for physical work is a microcontroller, a couple of hobby servos, a webcam and something to bolt them to, which is enough to build a machine that senses, decides and moves on a rhythm. A small wheeled base with wheel encoders covers similar ground. Neither requires an arm priced like a used car. If money is the binding constraint, simulation is a legitimate route rather than a lesser one, and you can learn a framework without owning a robot well enough to be useful on day one of a job. The trap in simulated work is a world where nothing is uncertain: perfect readings, perfect timing, no surprises. Add noise, add a delay in the perception path, put something where the plan did not expect it, then handle the recovery. What earns you credit is not the hardware bill. It is having met an unreliable world, whichever way you arranged for it to be unreliable.

How long does this take before anyone treats it as experience?

About three to six months of steady evenings, which is faster than a degree and slower than people hope. The shape matters more than the total. Six focused hours a week, held consistently, beats an ambitious plan abandoned in week three, because robotics debugging depends heavily on remembering what you changed since last time. A useful rhythm looks like this: the first month gets a machine moving badly, the second month gets it moving reliably, the third month is spent on everything that happens when something goes wrong, and the fourth is documentation, video and writing about the hard parts. That last month feels like the least productive and produces most of the visible value. Somewhere around the fifth month you will have your first real conversation about it with a stranger, and that conversation is the actual milestone. Do not wait for the project to be finished before talking about it publicly. Work in the open from the start and the timeline effectively shortens, because people find you mid-build rather than afterwards.

What if you cannot write C++ or Rust yet?

Start in Python and stay there until something forces you out, because the language is not what is stopping you. Nearly everything worth learning first — how a control loop is structured, what a coordinate frame is, why your readings arrive late, how to recover from a failed grasp — is language-independent, and Python lets you learn it without also fighting a compiler. Plenty of real robot software has Python in the perception and scripting layers. What will eventually push you toward a compiled language is a specific symptom rather than a preference: a loop that occasionally takes too long and makes the machine twitch, or a pause you cannot account for. When that happens, move only that part, keep the rest, and you will have learned exactly why the boundary exists. That story is worth more in an interview than having started in C++ out of duty. The sequence that fails is the opposite one: months spent on a language before ever making anything move, which produces fluency with nothing to point at.

What does fake robotics experience look like on a CV?

It looks like a list of technologies with no artefacts underneath them. A skills section naming a framework, two simulators and three libraries, none of which appears anywhere else on the page. A course certificate with a completion date and no output. A project title with no link, no video, and no description of what the machine did. A phrase like "familiar with real-time systems" attached to nothing that ever had to run on time. None of this is dishonest, and that is why people write it — the courses were genuinely taken, the tutorials genuinely followed. The problem is that a reviewer cannot distinguish it from someone who watched videos, so it is treated as noise and skipped. The fix is not more items, it is fewer with evidence attached: one project, one link, one sentence about what it does, one sentence about what went wrong. A short CV where every claim can be checked outperforms a long one where none of them can, and which projects are worth building at all narrows the list further.

What do you give up by taking the unpaid route?

You give up scale, review and deadlines, and each of those gaps shows up in interviews if you are not honest about them. Your home robot has one of everything and runs for an hour. A production machine has a fleet behind it, a support burden, and a customer who does not care why it stopped. Nobody has rejected your architecture in a code review, so bad habits went unchallenged for months. Nobody imposed a date, so you optimised the parts you enjoyed and skipped the tedious ones, which are frequently the parts a job is mostly made of: logging, updates, dealing with the unit that behaves differently from the other four. You also give up the compounding effect of working alongside people who already know things. These gaps are real, and the mitigations are cheap. Contribute to a project where a maintainer will criticise your code. Set yourself an external date by promising a demonstration to somebody. Deliberately do one boring part properly, then talk about it, because interviewers notice when a candidate has voluntarily done the unglamorous work.

When is ROS 2 the better choice?

ROS 2 is the better choice for most people building experience from scratch, and pretending otherwise would waste your evenings. The tutorials exist, the questions have been answered somewhere, the drivers for the sensor you bought are probably already written, and every one of those saves you a week you do not have. ROS 2 is also what the listings name, so the vocabulary you pick up transfers directly into interviews without translation. If your goal includes being employable in the next year, ROS 2 is the default and a sensible one. It wins on substance too for whole categories of work: mapping, navigation, motion planning, and anything where an existing package already solves the problem you would otherwise spend a season on. HORUS is not the answer when familiarity and hiring keywords are what you need. Build the recognisable thing first, and whether learning ROS 2 pays off for a job has a plainer answer than the arguments online suggest.

Do you need to own a robot before the experience is real?

No, and here is why: what makes robotics hard is the timing and the uncertainty, and both exist in simulation the moment you stop making the world convenient. A simulated machine can drop readings, receive them late, fail a grasp, be shoved by something unexpected, and start in a position nobody planned for. Handling that is the same engineering as handling it on a bench, and the code is often literally the same code. What simulation genuinely cannot teach you is the physical layer: connectors that work loose, a battery that sags under load, a motor that gets hot, the wire you routed through a joint. Those matter, and they are worth one cheap physical project eventually. But the sequencing people assume is backwards. Simulation first, hardware second, is usually the faster and cheaper path, and it produces work anybody can run without owning your parts. The builders who stall are not the ones without robots. They are the ones waiting to buy one before starting.

Does a certificate or a course count as experience?

Partly, but not the way you think. Courses are genuinely useful, and the people dismissing them entirely are wrong: a good course gives you vocabulary, a mental map of the field, and a reason to keep going in the weeks when nothing works. What a certificate does not do is function as evidence, because the reviewer has no idea what you actually did to earn it, and thousands of identical ones exist. Treat a course as scaffolding rather than as output. The correct use is to take one, then immediately build something the course did not cover, using what it taught. That second thing is the artefact. It also converts the course from a passive claim into a story you can tell, which is what an interview runs on. The failure mode is course collecting, where each new one postpones the uncomfortable moment of building something without instructions. That moment is where the experience actually starts, and no certificate moves you closer to it.

What changes once you want somebody to pay you for it?

The bar shifts from "did it work" to "would you trust it when nobody is watching", and that is a different kind of engineering. Personal projects are allowed to need a restart every so often, because you are standing there. Paid work is not. So the skills that begin to matter are the ones hobby projects skip: what happens when the machine is switched off mid-motion, how you update software on a unit already deployed, how you find out what went wrong from a log rather than from having watched it. Robots also stop being one program at this point. Perception, control and decision-making end up as separate pieces, possibly in different languages, all needing to agree on time. That is when the framework underneath stops being cosmetic, because keeping a control rhythm steady while a heavy program runs alongside is precisely the problem middleware exists to solve. If you want your unpaid work to convert into paid work, aim it here early: build the version that survives being left alone, not the version that demonstrates well.

How do you decide where to start this month?

Pick the route matching your scarcest resource, because time, money and access are what actually differ between people, not talent or ambition. Run through it honestly. If money is scarce and time is not, build in simulation, because the tooling is free and the work is runnable by anyone. If time is scarce and money is not, buy a small kit and protect two evenings a week, because the parts remove hours of sourcing. If you have neither in quantity but you have a job with hardware in it, take the sideways move, since that is paid experience nobody else applied for. If you have access to a campus, trade hours for supervision, because feedback from someone experienced is the hardest thing to obtain alone. Then, whichever you pick, add one merged contribution to a project other people run, because outside validation is what a personal build cannot supply, and telling a healthy open-source project from a dead one is worth ten minutes before you spend a weekend on it.

Decide by situation rather than by ambition:

• If money is tight and evenings are free -> a simulated build with noise and failures in it, because a stranger can run it and the disturbance shows judgement.
• If your employer has anything with motors -> volunteer for it, because paid hours near hardware beat unpaid hours away from it.
• If you have a year and want a job at the end -> ROS 2 plus one merged contribution, because vocabulary and validation are what interviews test.
• If you have a machine already working -> spend a month on failure handling and a video, because that month carries the whole project.
• If your robot has outgrown one program -> a multi-language build on one board, because Python and compiled code cooperating is a story with decisions in it.

When two routes look level, weigh the tools each would put you on against the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target, and licence. Take the one losing on the fewest. If your next project puts perception in Python and a control loop in a compiled language on one small board, star HORUS on GitHub so it is in your list when you start building.