What Robotics Employers Actually Look For in a GitHub Portfolio

Robotics employers look for one project a stranger can run end to end, not a shelf of tutorial forks or unfinished coursework. A hiring manager opens two repositories and reads the README, so the interview comes from evidence your robot worked unattended, not from the length of the list. That flips when a team publishes its stack: matching it, whether ROS 2 or HORUS, then outranks depth. The rest of this post is for people early in robotics who are deciding what to build next and what to write down about it.

Your GitHub page is not doing anything for you, and you already suspect that. There is the repository from the course, carrying the same package name as everyone else who took that course. There is a fork you made to fix a typo. There is something called robot-test with one commit and a file named main dot py in it. There is the good one, the project you actually cared about, which has no README because you knew what it did.

You have applied to a dozen places and heard nothing back, and the rejections say nothing at all, so you cannot tell whether the problem is the projects, the CV, the degree you do not have, or whether anybody reached your GitHub page in the first place.

Meanwhile the advice conflicts. Someone tells you to learn ROS 2 because every listing asks for it. Someone else says nobody cares and you should learn C++ properly. A third person says build a robot arm from scratch, hardware and all. Every one of those costs months, and you cannot do all three.

Does your GitHub portfolio actually decide whether you get an interview?

Your portfolio rarely wins the interview on its own, but it is what turns a maybe into a yes, and it is almost always the last thing read before somebody decides to talk to you. Understand the sequence and the advice stops conflicting. A listing collects far too many applications, so the first pass is a filter on words: the framework, the languages, a degree or its absence, a location. No portfolio survives a filter it does not match, which is why the strongest project in the world can go unopened. Past the filter, an engineer skims for a few minutes, and now the portfolio is the whole conversation. That engineer is not grading you. That engineer is asking one question, over and over: has this person made a machine work, or only read about making one work. Then, if you reach an interview, your project becomes the material. Half the technical conversation will be somebody asking why you did something the way you did. A project you cannot explain in detail is worse than no project.

What is a robotics portfolio, in plain terms?

A robotics portfolio is the small set of artefacts you can point at as evidence that you have made a machine do something, which in practice means two or three repositories, a video, and a written account of what went wrong. It is not everything you have ever pushed. Nobody browses a profile page top to bottom, and an unpinned graveyard of abandoned attempts actively works against you. Robotics has one wrinkle that software portfolios elsewhere do not. A reviewer of a web project can run your code in a minute and see it work. A reviewer of your robot project has neither your arm, your camera, nor your motor driver, so the code alone proves very little. The evidence has to arrive some other way: a video of the machine moving, a simulation somebody can launch without buying anything, a README that says exactly what hardware is required, and a description of the failure that took you a week to find. That last piece is what separates a portfolio from a gallery.

What are your actual options for a portfolio project?

You have eight realistic kinds of portfolio project, and they trade off differently between how quickly you can finish and how much they distinguish you. You can follow a course and publish the result. You can build a simulated robot that navigates or manipulates something. You can build a small physical robot, however modest. You can contribute fixes to an open-source robotics project other people depend on. You can write one focused library or hardware driver and maintain it properly. You can reproduce a paper in simulation. You can write up work from a competition team. And you can build a project deliberately around the multi-language reality of robot software: ROS 2 is what most listings name and brings the largest body of existing robotics code anywhere, 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. Read the table as descriptions of candidates rather than a ranking.

What should you build if you are switching from web or app development?

Build the project that proves you can handle hardware and time, and lean hard on the engineering habits robotics teams are usually missing. Career changers make a predictable mistake: they build another dashboard, because dashboards are what they are good at, and the reviewer sees a web developer who bought a Raspberry Pi. What actually converts is the opposite emphasis. Show a machine that runs unattended and recovers when something is unplugged. Show that you know what happens when a sensor stops answering. Then bring the things you already do well, because they are genuinely scarce in this field: tests that run in continuous integration, a README somebody can follow, a versioned release, a clean commit history with messages that explain why. Plenty of robotics code is written by people who never had to hand a system to a stranger, and a candidate who has done that stands out immediately. Your advantage is not the robot. Your advantage is that you can make the robot legible to other engineers, and the broader route into robotics from software rewards exactly that.

What hardware do you need to build something worth showing?

Far less than you think, and quite possibly none at all. The cheapest credible physical project is a microcontroller, two hobby servos, a webcam and something to mount them on, and that is enough to demonstrate a sensing-to-motion loop that reacts to the world. A small wheeled base with an encoder on each motor covers most of the same ground. Neither requires an arm that costs as much as a car. If your budget is zero, simulation is a legitimate answer rather than a consolation prize, and there are ways to learn without buying a robot that produce genuinely reviewable work. What kills a simulated project is a world where nothing is uncertain: perfect sensing, perfect timing, nothing ever unexpected. Add noise to the sensor readings, add a delay in the perception path, put an obstacle where the plan did not expect one, and write the recovery. A reviewer who sees a simulated robot handle a disturbance learns more about you than one who watches a real robot execute a scripted motion flawlessly.

What if you are applying next month?

Do not start a new robot. Finish and document the best thing you have already built, because presentation is where nearly all the untapped value sits. This is the highest-return work available to you and it takes two weekends rather than two months. Pick your strongest existing project, even if it embarrasses you. Record a video of it running, uncut, from a cold start. Write a README that opens with one sentence saying what the machine does, then the video, then what hardware or simulator is needed, then the literal commands to run it, then a section about what does not work yet. Pin it on your profile. Remove or unpin the abandoned repositories. Then spend the remaining time writing a short post about the hardest bug you hit and how you found it, and link that from the README. A finished, explained, modest project beats an ambitious unfinished one every single time, and the gap is not close.

What if you have never written a line of robot code?

Start with one sensor, one actuator and a loop between them, and get that running before you go anywhere near a framework. The smallest complete robotics project reads a value, decides something, moves something, and repeats on a rhythm, and it teaches more in a weekend than a month of tutorials. A distance sensor and a motor that stops the machine before it hits the wall is a complete system in miniature. Once that works, add the parts that make it real: what happens when the sensor returns nothing, what happens when you unplug it mid-run, what happens when you start it in an odd position. Those questions are the actual job. Only then reach for a framework, and reach for it because you have two programs that must exchange data rather than because a listing mentioned it. Learning a framework before you have felt the problem it solves produces a candidate who can recite commands and cannot explain a single choice, which interviewers detect within minutes.

What does a portfolio look like when it quietly fails to help you?

It looks busy. That is the whole tell, and it is remarkably consistent. Nineteen repositories, most of them forks, several named after a tutorial, half with a default README and half with none at all. Nothing pinned, so the reviewer sees whatever was pushed most recently, which is usually a config file. No videos anywhere, so nothing proves any of it ever moved. Commit histories where everything arrived in a single push, which reads as a copied result rather than work. No mention of hardware, so a reviewer cannot tell whether the code has run on anything. And nowhere on the page a sentence saying what any of it is for. The reviewer is not hostile, the reviewer is fast, and every one of those gaps costs a few seconds of goodwill until the tab gets closed. The cruel part is that the underlying work is often good. A candidate with one strong project and no way to see it loses to a candidate with a weaker project and a video.

What do beginners build first, and why does it stop helping?

Almost everyone builds the line-following robot, the tutorial simulation, or the course package, and those stop helping the moment you start applying, because every other applicant has the same three. This is not a criticism of building them. They are how you learn, and skipping them is worse. The trouble is what they demonstrate: that you can follow instructions accurately. That is a real skill and it is not the one being hired for. What a reviewer wants is evidence of decisions, which only appear when you leave the guided path. The upgrade is smaller than starting over. Take the line follower and make it handle a gap in the line. Take the tutorial simulation and put an obstacle where the tutorial did not, then write the recovery. Take the course package and add the sensor the course never covered, including the driver work. Each of those turns a follow-along into a project with choices in it, and choices are the only thing you can meaningfully discuss in an interview.

What do you give up by building one deep project instead of five small ones?

You give up breadth of keyword coverage, and that is a real cost rather than an imaginary one. One deep project on a mobile base says nothing about manipulation, so a manipulation team has less to grab onto. It concentrates your risk too: if the project stalls halfway, you have no fallback, whereas five small ones always leave something to show. And a deep project takes long enough that you cannot chase a listing you saw last week. Those costs are genuine, and they are still worth paying, because the alternative fails in a worse way. Five shallow projects all say the same thing, which is that you can complete a tutorial. Depth is what produces the stories that interviews run on: the week you spent finding out the readings were stale, the redesign after the first architecture stopped working, the decision to move a component into another language. The mitigation is not more projects. It is one deep project plus a few merged contributions elsewhere, which buys breadth without dividing your attention.

When is ROS 2 the better choice?

ROS 2 is the better choice for a job-seeking portfolio most of the time, and being honest about that matters more than being interesting. Job listings name ROS 2 constantly, interviewers ask about nodes, topics and transforms because that is the shared vocabulary, and a project built that way is legible to a reviewer in seconds without any explanation from you. If your goal is to get past filters and be understood quickly, build in ROS 2. It also wins on substance for whole categories of project: anything involving mapping, navigation, motion planning or a sensor whose only driver is a ROS 2 package is a ROS 2 project, because reproducing that work yourself is not a portfolio, it is a career. HORUS is not the answer when matching what employers list is the entire objective. The honest framing is a division of labour: build the project that speaks the industry's language first, and whether ROS 2 is worth learning for a job has a fairly blunt answer.

Do employers care which middleware your project uses?

No, and here is why: the engineer reading your repository cares whether a machine worked, while the filter above that engineer cares about words, and those are two different audiences with different needs. The filter is mechanical. A recruiter or a screening tool matches the listing's vocabulary against your CV and profile, and a project using an unfamiliar tool matches nothing. That is a keyword problem, solved on your CV and in your README by naming what you used and what it is comparable to, not by choosing your tools differently. The engineer is the audience that matters, and that person is looking for judgement. Did the candidate pick something appropriate for the problem? Can the candidate say why? A project that used an unusual tool and explains the reasoning clearly reads better than a ROS 2 project chosen because everyone else did. So the practical answer is layered: satisfy the filter with words, satisfy the engineer with reasoning, and never let an unusual choice sit on your page unexplained.

Does a long green commit history prove you can do the job?

Partly, but not the way you think. Contribution graphs do carry information, and reviewers do glance at them, but not for the reason people optimise for. A dense wall of daily commits tells a reader that you write code habitually, which is worth something, and it also tells them nothing about whether any of it worked. What a reviewer actually reads is shape. A project with commits spread across weeks, with messages describing problems rather than files, showing a refactor after something did not work out, reads as real engineering. A project that arrived in one enormous commit reads as a copy, fairly or not. Long gaps are fine and nobody holds them against you. Meanwhile the metric people chase hardest, the unbroken streak, is the least informative of all, because it is trivially produced by daily typo fixes. Optimise for evidence of iteration rather than volume of activity, and remember that a degree is not what most employers screen on either.

How do you decide what to build next?

Take the job listings you would genuinely accept, write down every skill they share, and build the one project that covers the largest number of them. The exercise takes an evening and replaces most of the advice you will be given. Collect a handful of real listings, not aspirational ones. Strike out the requirements that are boilerplate. What remains is usually short and surprisingly consistent: a language, a framework, one domain such as navigation or manipulation, and something about working near hardware. Now design a single project that touches all of them at once, because one project covering four skills beats four projects covering one each. Then apply the finishing test before you start: can you record a video of this, can a stranger run some part of it, and can you name the hard problem you expect to hit? If the answer to the third is no, the project is too easy to be worth the months. And keep the scope small enough that finishing is realistic, because an unfinished project has exactly the same portfolio value as no project at all.

Decide by situation rather than by ambition:

• If you are applying within weeks -> finish and document what you already built, because presentation is the cheapest value on the table.
• If you are switching from software and have time -> one small physical robot, because a machine you wired yourself answers the question interviewers keep asking.
• If your budget is zero -> a simulated project with noise and failures in it, because reviewers can run it and disturbance is what shows judgement.
• If you are targeting a lab or research group -> reproduce a paper, because that is the work those teams actually do.
• If your listings all name a framework -> build in ROS 2, because being legible in seconds beats being unusual.
• If you want one project unlike everyone else's -> a multi-language machine on one board, because Python and compiled code cooperating is a story with decisions in it.

When two project ideas 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 board, star HORUS on GitHub so it is in your list when you start building.