Women in Tech: Moving up as a Software Engineer with Hannah Voelker

Hannah Voelker has worked at GRAIL as a senior software engineer and is currently a software engineering manager. She has experience moving up the positions and with undergraduate research at Broad Institute of MIT and Harvard. This interview will take you through her career journey and include advice for women in STEM and students who want to go down this career path. Edited for clarity.

Could you provide a general overview of your professional journey?

I knew I liked math and biology. I started out as a biomedical engineering major, which involves mechanical engineering, physics, and chemistry. However, many of the applications, such as working in a lab, weren't what I wanted to do long-term.

I learned how to code in one of my classes and enjoyed it. I could see where that would take me, so I picked up another major in computer science. That got me into bioinformatics and doing software engineering for biotech, which led me to a research lab at Tufts University in Boston.

I learned about scientists' different computational needs at that research lab and decided to pursue that further. I did a software engineering internship at Illumina, where I learned what it would be like to be a backend software engineer, which I enjoyed.

I ended up at GRAIL, which was really small when I started there. It was an excellent opportunity to grow my career along with the company. I started not knowing many things and eventually worked my way up to being my team's technical lead.

The technical lead makes many design decisions on how the software is written. I was recently made a manager, so not only do I still make those technical decisions, but a couple of people report to me now. It's been quite a long journey, but I've enjoyed it.

You mentioned you did research at Tufts. Do you prefer doing research in a lab or working in the industry?

One cool thing about research was how open-ended our projects were. At my lab, we got to pick a project in the domain of genetic sequencing and do the work to learn what research is like. It's that end-to-end process of designing an experiment, running different tests, and then being able to analyze the data and come to a conclusion.

However, one thing I found a bit challenging about it and probably why I like working in the industry a little more is that those open-ended problems mean that you can put in a lot of effort and never get to a solution. Sometimes the experiment shows there's nothing there.

I ended up liking the industry because I was a little bit more empowered to build things in the field that I'm in. But, there is a lot of cool research out there, and I think you can find a good balance.

One place I worked at in college was a nonprofit doing genomics research. It was sort of like an industry job, but you were also working on research. It was a nice place to be because you had that balance of being able to pursue your projects. But also, there was some structure to those projects in that you knew what you were getting into before you started.

In research, does not coming to a conclusion happen often?

I was analyzing the microbial composition of different probiotic foods at Tufts, which is learning what different bacteria were in the probiotic foods. Sequencing the genetics of other foods and seeing what kind of bacteria showed up was hard because extracting bacterial DNA from regular foods was hard.

I think that experience made it a bit frustrating because the project was not getting the level of data that I had expected. It was tough to have an analysis that felt fulfilling. However, with computer science, what you can build is more tangible. You're not restricted by as many things.

How do you think your field has changed since when you started?

One of the big things I've noticed is that people nowadays learn how to code early on. Software and technology are everywhere in your life. I think that has made a lot of the development of professional software move so much faster than it did at the beginning because people are joining the field every day who have been working with these types of tools since childhood.

That's a huge leg up. I didn't start until I was 18, so it's cool to see all of the different innovations people have come up with in the last couple of years.

Another thing is that people are looking outside traditional tech companies and trying to solve problems with code outside those spaces, which is essential. When I was in college, many people wanted to work at Facebook or Google, or any of those big tech companies. But now, you see a lot of different companies that hire software engineers.

What programming language do you mostly use?

I mostly write code in Go, which I really enjoy. I also like to code in C++ because it's hard, but it's very hands-on, and you have much more control over what's happening. Um, you know, it's a very low-level language, and I think that that's interesting for me.

Python is also one of the programming languages I recommend to people who are starting because you can take that pseudocode you write when you're trying to work out how to build something and write actual code quickly. It's a great language for creating something quickly.

What's your favorite part of the job?

My favorite part of the job is the people I work with. Everyone's excited and passionate about working in biotech, working to solve cancer, and detecting it early. That makes it especially interesting because everyone's motivated to solve that problem and build things that help do that.

What's your daily work routine like?

I spend about half of my day writing code, mainly in the morning. I'll open up my laptop and usually have a meeting or two to go over the tasks that need to be done for the day.

Sometimes I need to assign certain things to some of my teammates to ensure they have something to do. We spend that middle part of the day writing some code, testing it, and then sending it out for review. In the back half of the day, I spend that mostly in meetings with other team members, trying to figure out how to design a new feature or plan ahead about what we need to build in the next couple of weeks.

If I don't have any meetings, I would do code reviews where if my teammates are submitting code, I will go and look at GitHub or GitLab, depending on where the code is submitted, and review and see if anything is interesting about their changes, or try to understand what they built and what it does.

With all the coding, do you get eye strain?

That's actually a great question. I wear blue light-blocking glasses when I'm writing a lot of code. When I have to look at the screen for a really long time, I usually will wear them because it helps me a lot.

Some of my coworkers don't complain as much about their eyes, but they get a lot of wrist pain. Having a mechanical keyboard or something with a wrist rest is a massive deal for many software engineers.

Are there extra challenges in being a woman in STEM?

I'd say imposter syndrome's the big one. It's a commonly known one, but I think another thing is that once you start doing your job, sometimes your coworkers might expect you to do work that is not part of it.

For example, taking notes during meetings or being the person to organize the parties for your social gatherings would be things you'd be expected to do. Although that work is very important, it shouldn't be expected for a woman to do that, and you see that a lot in software.

I think that one thing that I try to push a lot of my coworkers and friends to think about is whether we're making sure that everyone has a fair chance to do all the work that is a part of their job. Or, are we burdening certain people with the job of doing background tasks that don't always go noticed?

Another thing that I like to do, at least with meetings, is that we always take turns being the note taker, the party planner, or whatever those types of jobs are.

In short:

• Research in academia can be very challenging and unstructured because you don't know if you'll get any valuable data or conclusions, while in the industry, you'll have more concrete goals in mind.

• So many resources are available today for young people and students to learn to code, speeding up technological innovation.

• Women in the workforce are often expected to do the background tasks such as taking meeting notes and planning social events, which is unfair and rarely acknowledged. We should combat this by making it a point that everyone takes turns doing these tasks.