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.