Join us: we're recruiting four positions to build BioJupyter at BIDS

August 13, 2026

A team of open source research software engineers powering AI-enabled innovation in the biomedical sciences

We are recruiting for four new positions at the Berkeley Institute for Data Science (BIDS) to work on BioJupyter, a component of the recently announced Bakar Computational Biomedicine Initiative (BCBI).

Built on the open architecture and ethos of Project Jupyter, BioJupyter will be a modular, open platform for biomedical discovery — one that makes fluid, reproducible collaboration across institutions a natural part of the research environment, with shared data, integrated AI, and full respect for data privacy and security policies. We describe the project, our approach, and why all of this work is fully open, like the rest of Jupyter, in our companion post announcing BioJupyter — worth reading first if any of the roles below interest you, since the commitments described there shape all four of them.

Broadly speaking, we are looking for developers who love to create and innovate, to solve problems in a highly collaborative setting with interdisciplinary expertise beyond their own, to work with and help others, who are good at communicating, and who thrive in a rapidly changing and exploratory environment.  You'll be working alongside some of the world's leading scientists, building tools to advance the frontier of biomedical research by helping them collaborate with each other and with AI.  This is a challenging project that goes well beyond implementation, as we are imagining the future of open source research infrastructure alongside the scientists themselves!

Four open source research software engineering positions with distinct focus areas

Open Source Research Software Engineers (OS-RSEs) bring software engineering expertise and open source development practices to interdisciplinary projects. They play the role of an "expert collaborator" who solves problems at the intersection of research, software, and modern computing infrastructure. Working closely with senior researchers, industry partners, and stakeholders, they regularly investigate -- and propose solutions to -- open-ended, unstructured challenges at the cutting edge of data science and AI applications.

These are not software development roles where you're asigned a ticket with pre-defined completion criteria! We expect OS-RSEs to have a deep understanding of how scientific research is conducted, how open science practices can improve the reliability, reusability, and reproducibility of research outputs, and enjoy deep, collaborative co-creation with experts across the biomedical sciences.

When applying for any of these roles, please include links to up to 3 publicly available GitHub repositories that highlight engagement in issues, pull requests, community discussions (or equivalent conversations on alternative git forge platforms) and a description of a previous role (paid or volunteer) where you have identified and delivered outcomes in the presence of uncertainty.

We understand that some excellent applicants may not be permitted by their employers to share their work publicly, and others may not have the time and resources to contribute to open source communities in their evenings and weekends. If you are not able to include links to public work, please still apply!

Working as a team, with other staff members at BIDS and researchers at the BCBI, each OS-RSE will bring a speciality on top of these shared skills in community-governed, open source software development.

  1. Open Source Research Software Engineer — Computational Infrastructure — deployment and scaling of the Jupyter stack, from laptops to HPC to the cloud.
  2. Open Source Research Software Engineer — User Interfaces — understanding and enhancing the user experience, including Jupyter Lab and other client-side interfaces.
  3. Open Source Research Software Engineer — Agentic AI — how AI workflows can support scientific innovation without displacing the researcher.
  4. Open Source Research Software Engineer — Product — our spin on a scientific product manager: the bridge between what biomedical researchers need and what we build.

Open Source Research Software Engineer — Computational Infrastructure

This role focuses on computational infrastructure development. We are looking for someone close to the kinds of deployments made with JupyterHub and Jupyter Server, across the full spectrum:

  • Local deployments on individually managed computers and small clusters
  • HPC and shared infrastructure provided by universities and research centers
  • Cloud deployments built on open standards such as Kubernetes

This is a role for someone deeply interested in how the Jupyter tools can be deployed in scalable environments while retaining this kind of flexibility — the same platform meeting researchers wherever their computation actually lives. We seek to support the real-world needs of current researchers: the labs we are working with already span all three, and a graduate student prototyping on a workstation, a lab running jobs on campus HPC, and a multi-site project bursting into the cloud should all be able to work together on their science without having to become infrastructure engineers themselves.

In biomedical research, these requirements are particularly meaningful, due to ethical, legal and cultural constraints. Collaboration across two institutions means authentication, authorization, and access to shared resources are first-order design problems rather than deployment details — and data that cannot simply be copied around makes where computation happens a scientific constraint. We are looking for developers who both understand the importance of these constraints, and can envision meeting them with open and modular systems.

Much of this work will land directly in JupyterHub and the surrounding deployment ecosystem, so this is a role with a large and immediate open source footprint: what you build for Berkeley and UCSF will also be co-created with partners at other institutions, and you will work on engaging with a broader community beyond our boundaries.

When applying for this role, please include links to up to 3 examples of code you have written to orchestrate computational infrastructure.

Open Source Research Software Engineer — User Interfaces

This role sits closer to the user experience in Jupyter. We are looking for someone intimately familiar with client-side issues and with user experience and user interface development — ideally someone who has already participated in the development of JupyterLab-related tools and plugins.

We are looking for familiarity with the architecture of JupyterLab, which goes well beyond notebooks. JupyterLab is a very modular and flexible set of components that exposes Jupyter's architecture as a collection of TypeScript pieces which can be used to talk to kernels, put data on the page, open panes, control the user interface, and even be retooled entirely for new use cases (see for example our sister work on GeoJupyter and JupyterGIS developed at Berkeley's Eric and Wendy Schmidt Center for Data Science & Environment (DSE), Quantstack and beyond).

That extensibility is at the heart of what we want to build. Biomedical work brings its own objects and its own ways of looking at them, and the interfaces scientists need are not always a linear sequence of cells in a Jupyter Notebook. We want someone who can think about what the right interface is for a given kind of scientific work, and then build it as composable pieces the rest of the ecosystem can reuse — rather than as a one-off tool that only serves one lab.

Just as importantly, we will meet scientists where they work today, integrating with existing systems in a way that adds minimal cognitive burden: connecting the tools they already rely on (ideally open source ones) into a JupyterHub or JupyterLab deployment, so they gain new capabilities without losing workflows and muscle memory.

Two further threads run through this role. The first is collaboration: much of what makes shared research work happen is felt at the interface, in how several people see, annotate, and hand off the same living document. The JupyterLab architecture already supports real-time collaborative editing of multiple kinds of entities out of the box — the same foundation that makes real-time collaboration possible on geospatial data in JupyterGIS, or on 3-d models in JupyterCAD. This is a challenging and complex problem of key importance, and one where we expect to make important contributions that will benefit all Jupyter users.

The second is AI, which is arriving in scientific interfaces quickly and mostly driven by the market capture vision of industry (though teams such as Lightcone Research explore precisely this question with a fully open source approach). This role and the agentic AI role below will work closely together on how to design open source systems that help researchers collaborate amongst themselves and with AI systems, to produce trustworthy science in a meaningful and joyful workflow.

When applying for this role, please include links to up to 3 examples of code you have written to develop user interface software.

Open Source Research Software Engineer — Agentic AI

This space is evolving rapidly, so an exploratory and open mindset is key to support the needs of scientists. We are looking for engineers who want to imagine new workflows where AI can support biomedical research, with emphasis on two things at once: the scientific rigor and quality of the research these systems support, and the human experience of the research process.

We are not looking to automate scientists away; instead we aim to explore how AI systems can facilitate research, improve its quality, and support scientists as humans who own the context, the decisions, and the questions in their science — but who are interested in using these new tools effectively.

As stated above, Jupyter is about much more than notebooks: its protocols, APIs and architecture are a modular and composable toolkit that can connect computation and data to the human experience, dating back to its origins in IPython as an "enhanced Interactive Python". Our tools provide the context for interaction with programming languages (via kernels), and we want to develop new and better experiences when AI systems are also in the loop.

Importantly, Jupyter is a flexible system that does not require users to work only with Jupyter-based tools. Often JupyterHub is a gateway into other systems: users may open RStudio, VS Code, or other dedicated tools, all the way to desktop applications served remotely; that flexibility is part of the project's ethos, to serve users' needs without imposing artificial constraints. But that "doorway" provided by Jupyter is typically where scientists authenticate, where they access shared resources, and where they collaborate — and we want to enhance that experience for today's settings where AI is a routine element in the work.

When applying for this role, please include one concrete, creative example of how you've used agentic AI in your area of expertise (whether in research, software engineering, or elsewhere) including a link (repository, notebook, demonstration etc) if one is available.

Open Source Research Software Engineer — Product

This role wraps all of these ideas in a product mindset. BioJupyter's focus is biomedical research — from basic biology through to health care and clinical deployments at UCSF, initially, with a goal of universal adoption — and so we are looking for a candidate with hands-on experience in computational biomedical research, broadly construed. Ideally this is someone with a scientific background who has had their hands in the building and the use of biomedical data and of modern open source tools for biological and medical research, but who is interested in seeing these questions through the lens of product design: what should we design to facilitate sharing, collaboration, and modern research in an open ecosystem?

We are looking for someone genuinely passionate about building really good products for science, who knows what it looks like to actually do science, and who wants to do this work in a completely open environment — with the Jupyter community and with the communities behind the biological and biomedical open source tools these researchers use, many of which are entirely independent of Jupyter.

This person will be the bridge between the needs of scientists (in our own labs and beyond), our engineers, and other developers in the open source community. Their job will be to turn, through hands-on, collaborative engagements, those needs into concrete product constraints we can iterate on, refine, and build something genuinely exciting from.

When applying for this role, please include a link to a research output (a research paper, analysis code, educational resources, etc) showcasing your expertise in the biomedical field.

Come build this with us, in a rich and collaborative environment

If you join us, you will not only be working with other colleagues in the BioJupyter project, but also as part of a broader and thriving community committed to advancing science through open approaches. BIDS is housed at the new Barbara and Gerson Bakar Gateway, home to our College of Computing, Data Science and Society, and we share this incredible new building with our Statistics and EECS departments, the Center for Computational Biology (home for our new BCBI faculty) and the joint Berkeley-UCSF Computational Precision Health department; across our courtyard sits the Eric and Wendy Schmidt Data Science & Environment Center (DSE), with like minded experts in earth and the environment.

BIDS is also home to Lightcone Research, with whom we recently hosted an AAI4Science Developer Summit, the broad JupyterHealth collaboration, and leaders of the Scientific Python project. The BioJupyter team will find colleagues and intellectual partners in these and other Berkeley, LBNL and nearby research centers.

Apply through Berkeley Jobs portal

If this vision seems compelling to you, we would love to hear from you. Don't be shy about applying even if you don't seem to tick every single box! Conversely, if you're interested in multiple positions please apply to each of them separately. Remember to adapt your cover letter to meet the specific prompt for each role.

The job postings for all four positions can be found in the Berkeley Jobs portal. Please search for "Open Source Research Software Engineer" or follow these links for the computational infrastructure, user interfaces, agentic AI, and product roles. There, you will find logistical information regarding UC employment, application process and contacts for HR-related clarifications.

For questions about Jupyter, our biomedical vision, and the work our teams do in the Jupyter ecosystem, don't hesitate to ask on Jupyter's Zulip chatroom, or email us directly.

The front view of the Barbara & Gerson Bakar Gateway building.

BIDS is housed in the The Barbara and Gerson Bakar Gateway.