Senior Python Engineer, Platform Libraries (m​/f​/d

The role

We’re looking for a Senior Python Engineer, Platform Libraries (m/f/d) to join our team and play a key role in developing software that connects and translates lab equipment hardware interfaces, automates machines, and powers our next-generation automation platform. As a core team member, you will be working on cutting-edge technology, building software that bridges the gap between software and hardware, enabling seamless integration across various vendors.

Connectors are how we do it. Every instrument we bring online gets one, and every connector is built on our shared Python libraries:
Bus, our Connector Development Kit, and the stack underneath them.

Our mission is to empower researchers and engineers by bridging the gap between lab equipment and cloud-based automation. Our customers are solving critical challenges like curing diseases, developing sustainable materials, and addressing global food security. We provide them with the tools to connect their devices, automate workflows, and unlock new possibilities in R&D.

Your mandate has two halves. Own the libraries as a product with real users, our own engineers today and external contributors later. And stay close enough to customer connector work that what you build is grounded in problems that actually exist.

Your users are engineers. Your success lets other people ship connectors faster. That's a different craft from shipping features, and it's the one we're hiring for.

Real hardware, real failure modes. Instruments time out, return garbage, and arrive with documentation that's wrong. You'll debug against physical devices in our Munich workshop.

Open source on purpose. Our CDK and our standardization work (SiLA
2) are public. What you build gets used and criticized by people outside the company.

Senior scope, small team. You'll be the person who decides how connector engineering works here. No layer between you and that decision.

• Own Bus, the CDK, and the core stack. Features, tests, CI, releases, and deprecations across the connectors already running in production.

• Extract abstractions from real work. When the same pattern shows up in the third connector, it becomes a library feature. You're the one who notices, and the one who does it.

• Make the docs good enough to remove yourself. An outside contributor should be able to build a connector on our libraries without a call.

• Set the quality standard. You define what "tested" means before a connector reaches a customer, and you make it stick.

• Ship production connectors end to end. Spec sheet, physical device, protocol, proof of connectivity, tested connector, live customer. Independently.

• Reverse-engineer what isn't documented. Roughly half the instruments we touch have incomplete or wrong docs. Packet captures, trial and error, vendor calls.

• Work with the workshop. Our Connector Factory team gets instruments development-ready. You take it from there.

• Talk to the people who use it. Automation engineers and scientists at biotech and pharma customers. Their constraints shape what the libraries need next.

• Deep Python: 5+ years of writing production Python other people depend on. Async, typing, packaging, testing. You've designed APIs that other engineers built on, not just glue code.

• You've debugged a real protocol against real hardware: gRPC, serial, TCP, OPC UA, CAN, USB. Which one matters less than having sat with a packet capture and a device that won't respond.

• You ship without a spec: When the documentation is wrong, you reverse-engineer, instead of filing a vendor ticket and waiting.

• You build for other developers: An SDK, a library, an internal platform. Something where your job was making other engineers faster.

• Located in Munich: The instruments are physically here at WERK
  1.

• SiLA 2, or another device abstraction and interoperability standard

• Lab automation, scientific instruments, or a life science background

• Open source maintainership with actual external contributors

• C, C++, .NET, or Rust, for the vendor DLLs and drivers we end up wrapping

• Docker, Kubernetes, edge deployment

• German, for vendor conversations

Better to say this now than in week 6.

• Your Python is all APIs and databases and you've never debugged a physical device.

• You'd want two quarters to redesign the library architecture before shipping a connector.

• You like shipping integrations but have no appetite for going back afterwards to generalise, test, and document.

• You want the library work without the customer deadlines. Both are in the job.

Unite Labs is on the mission to accelerate scientific progress by automating lab processes with scalable infrastructure.

We’re a startup based in Munich, Germany, pioneering an industry-first integration platform for lab automation, bridging hardware and software across vendor barriers to revolutionize life science R&D. By…