Job Summary

Join the EIT as a Scientific Software Engineer, building the software that runs our autonomous laboratories. You will be part of the AI and Robotics Institute, working within a multidisciplinary team of software, mechanical, electrical, robotics, and AI research engineers, alongside the plant scientists who are our users. We are looking for people familiar with working in a scientific environment, e.g., lab automation, computational biologist/chemist, bioinformatics, cheminformatics, materials science or similar background.

The hardest part of automating a laboratory is rarely the code. It is that a protocol which works reliably in a scientist's hands is full of judgement that was never written down, and much of it matters. Timing that is flexible in one step and critical in the next, a wash that exists because of what happened three steps earlier, a visual check nobody thought to record. Software that executes the written protocol faithfully and still produces nothing viable is the characteristic failure of this field, and avoiding it takes someone who understands what the biology needs.

Your work is to move that knowledge out of people's hands and into software. Some of it is protocol structure and can be written down directly. Much of it is tacit, the feel a trained pair of hands has for when a culture looks wrong or a transfer has not gone cleanly, and getting that into a form a machine can act on is the interesting part of the job. Alongside that you will decide what has to be measured or verified for a result to be trusted, design the data models that keep results traceable back to the sample and protocol version that produced them, and validate automated runs against what the manual process actually achieves. You will spend real time in the lab, watching protocols run and understanding why they are the way they are before you commit them to code.

You will also be the person the rest of the software team relies on to know whether a design makes sense scientifically. That is a substantial part of the value here, and it works in both directions, since you will be explaining engineering constraints back to the scientists just as often.

Key Responsibilities

• Capture the scientific knowledge behind manual protocols and encode it into automated workflows, working with the scientists who developed them to surface the undocumented decisions, tolerances, and judgement calls that determine whether a run succeeds.
• Define what needs to be sensed, measured, or checked for an automated run to be trusted, and build the verification and quality control steps that catch a failed run early rather than at the end.
• Design data models and pipelines for experimental data, sample tracking, and provenance, so that results are traceable from raw instrument output back to the protocol version and physical sample that produced them.
• Build interfaces for scientists, ranging from protocol definition formats and CLI tooling to web UIs and dashboards, chosen to fit how people actually work rather than what is quickest to ship.
• Validate automated protocols against manual baselines, designing the comparisons and controls that establish whether the automated version is genuinely equivalent.
• Develop and maintain integrations with laboratory hardware, covering liquid handlers, incubators, imagers, and plate readers, working from vendor SDKs and occasionally sparse documentation.
• Contribute to the orchestration and execution layer that schedules and runs work across the platform, with support from the wider team on the parts of that stack you have not built before.
• Act as the scientific voice within the engineering team, reviewing designs for whether they respect the constraints of the biology, and explaining engineering limitations back to the scientists in terms they can work with.
• Build and extend internal Python libraries and services, with attention to clear interfaces, testability, and the ability to simulate hardware so that logic can be developed without occupying the lab.
• Support commissioning and debugging in the lab, since a meaningful share of problems in this domain only appear when the hardware is moving and the biology is live.
• Contribute to engineering practice across the team, covering code review, CI, testing, and documentation.