Runtime Systems Engineer
Location: Dresden, Germany
Type: Full‑time (on‑site preferred, hybrid possible within the EU)
We build software that gives robotics engineers clarity in complex robotic systems. Our tool makes (ROS‑based) robotic systems observable, understandable, and actionable, so developers can build safer, more capable robots with confidence.
We are SMAROBIX. A team of 5 founders with complementary skill sets and different cultural backgrounds and a TU Dresden start-up. This role is part of the core team shaping the product’s foundations.
The Role
You’ll work on understanding robotic systems as they run under real conditions. ROS‑based systems are dynamic and opaque at runtime: components appear and disappear, communication crosses process boundaries, and timing and reliability guarantees must hold under load. Capturing what actually happens, at the right level of detail and with minimal overhead, is a hard systems problem without an established solution in this domain. This is a hands‑on, design‑and‑build role. The challenge is not adding instrumentation in the abstract, but deciding what is important, how to understand it, and how to represent it so the rest of the product has reliable ground truth to reason from. The software runs directly on production robots, where correctness and low overhead are not negotiable. There is no template to follow; progress depends on understanding the constraints deeply and designing within them rather than hoping they don’t matter.
What We’re Looking For
You’re comfortable working close to the metal, where OS behaviour, memory, concurrency, and timing are explicit design concerns rather than hidden details. Reasoning clearly about what happens inside a running system is where you excel due to having programmed and debugged at the lowest level.
You understand robotic middleware not as a black box but as part of the system to be understood in detail. You’re familiar with how nodes communicate, how data moves across process boundaries, and what QoS settings mean in practice beneath the surface. You’ve worked with observability or instrumentation where overhead is a real cost, and you reason carefully about the trade‑offs between visibility, precision, and impact. You can zoom out from low‑level implementation details and make architectural decisions that hold up over time. You approach tools pragmatically, choosing methods that fit the constraints rather than forcing familiar patterns onto novel problems. In a small team, you communicate clearly, take responsibility for reliability in user environments, and work beyond role boundaries when it helps. We expect honesty about what you don’t know and the drive to find out.
Prior work with kernel modules, deterministic networking, real-time OS, observability tooling, or embedded/hardware acceleration experience helps, but genuine depth and drive to ship matter more. You think in concepts first; tools are secondary to understand the underlying principles well enough to apply them in any context; whether you come from academia, industry, or an unexpected path.
Why This Role
You won’t maintain an existing runtime tracing system or implement a predefined spec. It is up to you to build a system up and find the right solutions under unusual constraints. The foundation exists, but the critical decisions about what constitutes trustworthy enough is still open. That means being critical about scope, timeline, and priorities, not just about the technical solution. What and how you capture becomes the ground truth everything else in the product depends on.
You’ll work closely with the co‑founder responsible for runtime architecture, with real ownership and room to challenge assumptions. This is a role for engineers who want their system‑level judgment to shape a product from the inside. As the team grows, this work naturally develops into technical leadership through clarity and influence rather than formal hierarchy.
How to Apply
Send your CV and a short cover letter to jobs@smarobix.com. In your cover letter, tell us about a hard technical problem you worked on and the moment you realized your first approach was wrong: what did you do?