Part 1: The Human Capital Perspective

How Biotechs could do a better job at hiring and retaining software developers

This article is part of a series highlighting the expertise of people making up Arrayo’s network.

Today we kick off a three-part article by Stephen Whelan, Senior Data Engineer in biotech. Stephen’s background combines bench-level biotech experience and tech world best practices.

Introduction

Given recent tech layoffs, many software engineers are currently looking for gainful employment. This presents an incredible opportunity for digitally oriented biotechs to attract high caliber engineers behind some of the most well-known brands in the world. How can biotech firms attract and retain these highly sought-after engineers?

I’ve worked in several biotech firms as a software developer, starting my career with a bench role in biotech. I then transitioned into business software after attending a tech-oriented coding bootcamp. With this in mind, here are my thoughts on the software hiring process in biotech and lessons to be learned from its tech counterparts.

In this article I will focus on analyzing software interview processes in biotech and offering ways in which they could improve. By doing so, I hope to increase how many talented developers from the tech community join this incredibly exciting domain.

The Interview

In my experience, interviewing for software roles in biotech is largely similar to interviewing for bench-level lab roles. Both typically involve the following: discussing how my previous industry experience fits the position, a few technical screen questions, and behavioral interviews.

Biotechs are missing an incredible opportunity to strengthen their software development teams by continuing to use this interview method.

Indeed, the best interviewees are only as good as what the interview is testing them for: storytelling, basic background knowledge, and personability — i.e., good but insufficient criteria by which to evaluate software engineers. I’ve seen how this method can cause managers to hire the wrong people: developers who seem like good hires because they can interview well but cannot necessarily build robust and scalable software.

When biotechs lack a thorough technical software interview process, they sometimes justify it by saying “We aren’t Google,” or “We aren’t a tech firm.” This refers to how tech companies have lengthy interview processes in which candidates must solve LeetCode and algorithm-style problems.

This isn’t completely true. Yes, biotechs have different priorities than Meta or Google. For example, a two-second delay is often a dealbreaker for end consumers in a tech-oriented product. In biotech, however, a scientist usually won’t mind waiting a few minutes or even hours for a complex, multi-step ML pipeline to kick off and process the data. However, data is at the heart of a biotech’s business and hard skills should not be overlooked.

Domain-specific coding challenges could thus improve the interview process. Coding challenges allow you to test skills that are in demand on your team. Also, they ensure that your interviewees meet a base standard of coding skill and quality. Online platforms such as CoderPad, CoderByte, HackerRank, and Codility are designed to test interviewees on domain-specific coding. Using an interview provider may free up current employees who cannot afford to sit for an hour to screen potential candidates. Reviewing submitted code for top candidates in bulk and moving them forward to behavioral interviews is a much quicker process.

By ensuring that new engineers meet basic performance qualifications, management can guarantee that the quality of their engineers is not the source of problematic software. Isn’t the onus on the company and management to ensure that their new engineer can code with demonstrable evidence?

In the absence of poor hires, developers can be hampered by other organizational issues that may be elucidated by the questions below.

TLDR: Raising the bar on hiring standards would help ensure that hiring processes and engineers are not at the root of the problematic software.

The Candidate’s Perspective

It’s no secret that top software developers have options when searching for a job. The question that biotech software managers should ask themselves is: why should a developer consider working for you?

Developers rely on years of experience in diverse working environments to inform their next career move. Likely, they have experienced the hardship of navigating codebases with no documentation, poor design, and the rest. Hopefully they have experienced the joy of working creatively with well-designed products.

In any case, software developer candidates will appreciate transparency when it comes to your software infrastructure and processes. Yes, you must determine whether they are technologically and culturally suited to the position. But you also need to tell them what to expect from working with you. Having honest answers to the following questions is a good place to start to attract top tech talent.

What is your technology stack?

Technology stacks vary from company to company. Developers can expect to learn something when taking on a new project; their technology stack from previous companies and projects won’t align perfectly with yours. For example, if someone can code in Java, it is reasonable to expect that they can quickly pick up the fundamentals of JavaScript.

However, technology stacks can be informative. A developer’s existing expertise may allow them to contribute straight away while they are coming up to speed with new tech. Tech stacks can also speak to the values that the team and company hold and prompt further discussion. Do you value working with the hottest new tool, or do you prefer to focus on consistency? Does the developer absolutely hate working with tool XYZ? If so, the role might not be the best fit.

Can you please describe your testing/QA process?

Much like technology stacks, testing philosophies and practices vary wildly. Ideally, a code base will have high quality code with high quality testing and coverage. However, we live in the real world where this is rarely the case.

This question will still provide some insight into the quality of code to be expected. Do requirements rapidly change and writing tests as an expression of the requirements simply isn’t feasible? This reveals whether a rapid iterative cycle with stakeholders is to be expected. Alternatively, did the designers prefer to rely on a strongly typed system to reduce bugs and place more of an emphasis on delivering features quickly?

Different developers thrive in different environments. Some teams or developers may care deeply about testing, others not so much. It’s important to discuss these processes upfront rather than find out later.

What does your Continuous Integration / Delivery (CI/CD) process look like?

In my experience, deployment and delivery of software is highly heterogenous between digital biotechs. Sometimes the process for provisioning infrastructure on AWS is a tap on the shoulder to the guy sitting next to you. In other cases, it is an email chain death spiral, spanning three continents and countless weeks — to no avail.

Strong CI/CD practices, i.e., a direct line of communication with the devops team and leadership presence to provision for infrastructure, allow an engineer’s software to have immediate impact on end users. Establishing these practices and communicating them during the interview can go a long way in attracting high quality engineers to your firm.

What does your code review process look like?

Software engineers love to learn, grow, and build impactful software. Code reviews allow a developer to learn the codebase, consider consequences of feature additions into legacy software, catch bugs early, reduce technical debt, and improve the overall quality of code. While the cadence and practice of code reviews might vary drastically between organizations, they provide an excellent opportunity to grow as an engineer and learn from others. Make sure you communicate how your company provides a great place to grow as an engineer during the interview by discussing your code review practices.

What are the documentation responsibilities for the role?

Up to date and accurate documentation allows developers to get up to speed with code bases, understand overall architecture and design, and provide clarity on the entire design process. Is a style guide present to ensure consistency across code bases and commits within the same codebase?

Also, knowing how documentation is handled within a company can provide incredible insight into how a company’s software team operates. Sometimes the code itself can be enough documentation for the project because of an auto documentation feature. Other times, it may not be present at all. Prompting a discussion of expectations can be another insight into the quality of code to be expected and how easy or difficult it may be to navigate code.

What are the 30, 60, 90, 180 day & 1 year expectations for the role?

It is paramount to set expectations for productivity. Companies vary wildly in terms of what they expect from developers.

Startups usually focus on rapid iteration and delivering a product to end users as quickly as possible because of funding constraints. The development cycle and feedback loop tend to be much quicker. It can be an exciting but stressful environment to work in. Typically, 30-, 60- and 90-day expectations are much higher for delivering a product and tooling.

Larger, well-established companies tend to have longer timelines and a greater focus on quality, scalability, and algorithm development.

Conclusion

This article covered two sides of the hiring process for software developers in biotech. First, by introducing a standard interview process, management can shift their focus to improving internal software development processes and guarantee a floor on the quality of incoming engineers. Second, interviews are the perfect time to offer transparency regarding software infrastructure and practices, as well as the direction in which the engineering team is headed.

At the end of the day, both interviewer and interviewee benefit from standard practices for software development hiring.

Written by Stephen Whelan, Senior Data Engineer in the biotech space. Edited by Olympe Scherer.