Embedded Linux and Fleet Engineer
Build the Linux image, the on-device supervisor, and the update path that keeps a fleet healthy long after installation.
Volt IoT is our own device platform. It's a Yocto-based Linux device OS with a Node supervisor, A/B over-the-air updates with automatic rollback, several onboarding paths, and a multi-tenant control plane. We built it, and we run it for the clients whose devices ship on it.
This role owns the device end of that. Once units are installed the work becomes identity, telemetry, and updates that can't brick anything, and the difference between a good and a bad update system gets measured in site visits.
What You Would Work On
- Build and maintain custom Yocto images for Raspberry Pi and other single-board computers, including the layers, the recipes, and the automation that produces a release image.
- Work on the on-device supervisor, a Node service that reports telemetry, accepts commands, and drives the update lifecycle.
- A/B updates with RAUC and automatic rollback, so a bad release costs a reboot instead of a site visit.
- Device onboarding. We ship several paths already, from pre-issued credentials and config dropped onto the boot media through to zero-touch claim codes and discovery for hardware we didn't build.
- Kiosk software on Linux and the peripheral integration around it, including USB HID devices, card readers, and displays.
- Fleet operations tooling. OS image releases, staged rollouts, device health, and working out why one unit in a warehouse stopped reporting last Tuesday.
- Hardware-in-the-loop rigs that run a candidate release against real devices before anyone ships it.
- The device-facing half of the control plane, where device identity, command queues, and telemetry ingest meet the API.
What We Look For
- You've built a custom Linux image with Yocto, Buildroot, or something comparable, and maintained it past its first release.
- You understand the boot path in detail, including bootloader, partitions, root filesystem, and init, and what happens when one of them is half written.
- You've run an update system on devices in the field and know what makes one safe to roll back.
- You're comfortable writing the on-device service in whatever the job needs, Node and Python in our case, and fluent enough in shell to script a provisioning flow.
- You've debugged a device you couldn't physically reach, using only what it was willing to tell you.
Nice to Have
- RAUC, Mender, swupdate, or another A/B update framework.
- Secure boot, device identity, and provisioning at manufacturing time.
- MQTT and the message shapes that survive a flaky link.
- Container runtimes on constrained hardware.
- Ansible or another configuration management tool.
- Experience with fleets in the thousands, on links ranging from cellular to wired.
Nobody has all of these. If you have most of the section above and two or three of these, we'd like to hear from you.
How Hiring Works
You send a resume and a note. If it looks like a fit we'll have a call about the work you've done, then a longer technical conversation with the people you'd be working beside. We don't ask for unpaid take-home projects.
Before you write
The most useful thing you can send is a specific account of something you built and what was hard about it. Our own work is described on these pages if you want a sense of what we mean.
Apply for Embedded Linux and Fleet Engineer
Attach a resume and tell us about work you've done that's close to this. A few paragraphs is plenty.