Mary Lo has experience working as a senior software engineer at GRAIL and an engineer at Genentech. As an undergrad, she studied biomedical engineering but later switched to computer science and software as she believed it could unlock the potential to solve more problems. In this interview, she explains how she found her interests and how to combat an unhealthy work or school environment. Edited for clarity.
Could you provide a general overview of your professional journey?
My professional journey is a bit different because I studied biomedical engineering as an undergrad and did a lot of stem cell and synthetic biology research. After graduating, I worked as an automation engineer at Genentech for a few years. We worked with scientists to create a cluster of different robots that process the lab chemistry automatically so that the people would be doing experiment design.
At GRAIL, I continued to do lab automation engineering, which was more on the hardware side. A few years into that, I finished my master's degree. I started my master's in computer science with Johns Hopkins remotely and then transitioned to the lab software team. Instead of on the hardware side, I was now on the software side for a couple of years. I'm currently doing a full-stack software engineering job with web app development.
Why did you switch to software rather than continue with hardware?
Many of the problems we faced in the lab while I was working on lab automation could have been solved using better software. It felt like a natural transition for me because I wanted to be working on a solution to these problems. I wanted to be part of the solution.
Also, on a more personal note, I wanted to move away from working in the lab and work more with a team. Lab automation is a fairly small field, and only recently would you see a lot of teams. If you were doing lab automation in the early 2010s, you could be the only engineer in the whole department!
I didn't like working alone, and at GRAIL, when you work for software, it's a teamwork-based environment. GRAIL's users are all internal, meaning you're building software for people at the company to use, so you can get direct feedback from your end users. There is a lot of communication and collaboration between very different functional groups. For example, you would have engineers working with scientists, working with clinical lab managers.
What kind of programming languages did you work with?
I don't have a favorite, but I mostly worked with Go and Python. Go isn't super low-level; it's more like a hybrid between Java and Python. It's similar to Java but flexible like Python is. More and more companies are now using Go, but not nearly as much as Java or Python. It's sort of in the space between the two.
What's your favorite part of the job?
My favorite part of my current job is that we're a small company and a small team. There's a lot of communication and collaboration, and things move quickly.
In a startup environment, it's fun to see yourself making a huge amount of progress in the code base or the application. A lot of the rewards are very tangible. Bigger companies are different in that you'll work on something for months, but you may not see the impact or the benefit it has to your end users.
The best part is that you get to move very quickly together with a smaller group of people, and you get to see results immediately.
Are there any downsides to working in a startup? For example, would a larger company have more resources to work with?
The biggest downside to working in a startup is stability. Because you're currently building a product, you don't have your huge user base yet. You don't have a super steady revenue yet.
If you're comparing a startup and a large corporation, another downside of working at a startup is that things move so quickly. As much as you can see improvement, you can also see things break. For example, there could be some regression or bugs introduced in the code, and you don't know what's happening. A couple of people would need to get together to figure out the root cause of the problem.
As much as we want to say that we write perfect code, as humans, we all make mistakes. Having a friendly environment that understands and doesn't put blame on having mistakes made is key.
In a big company, you would find fewer system-wide failures or things that break the system, mostly because there's a lot more time and people to put safety checks in place.
What's your daily work routine like?
The way that my team organizes our work is that we run in sprints. For two weeks, we'll be focusing on something, and every few weeks, it changes. My day-to-day work depends on what I'm doing that sprint. Normally in the morning, how I like to get started depends on my level of motivation.
I might review some code or catch up on what the team has been doing. I'll start my work, and we make it an important point that people have heads-down time during the week, meaning you have unblocked time where you don't have meetings scheduled.
This way, you have time to think about the code and have time to concentrate. Oftentimes, this falls in the afternoon. In addition, some weeks are more planning and figuring out the design of the architecture. It always varies; it ebbs and flows.
Are there additional challenges to being a woman in STEM that most people don't think about?
Imposter syndrome is a big one. It comes from a culture of people thinking they need to know all the answers without asking questions.
It might even be instilled in the company culture. If the communication style between the team is that they don't ask questions in public or they feel that they already need to know certain things, it could contribute to the issue.
That's when imposter syndrome gets really, really bad because you're scared to ask questions and learn. However, if you're in an environment where you're praised for asking questions, even if they're silly, it helps a lot.
For example, you have people coming into the field of biotech and others who have like no idea what biotech is like, so you need to cultivate a welcoming culture. It becomes a lot easier to kind of push through that barrier.
As a minority in the STEM field, it's really easy to think that you're alone, especially when you have only one other woman in the team or maybe there's one woman in the whole department. It's really good to have an encouraging environment where you can ask questions and get help.
Do you have any specific advice for students?
It often feels like there's some competition with your classmates to see who scores highest or who gets a better grade, things like that.
However, the most important thing is to learn how to help each other and how to work together with other people. You see all sorts of different personalities, and once you start working, you'll notice people who are hard to work with and who think they're always right.
It becomes problematic for company culture and also teen culture. So, if you start embracing the culture of helping each other, you lift everybody up. Learning that at an early age and ingraining that into how you view your work will not only define you as an engineer or individual, but also to the companies that you may join and set a new standard.
When you go interview for jobs in the future, and you see that there's a problem with the culture there, you should consider whether that environment would be healthy for you.
In short:
Working in a startup is different from working in a big company because there's more teamwork and visible progress. One person is a more significant part of a startup than a large corporation.
Being in a more encouraging environment helps ease impostor syndrome. If you're in a class or team setting, you can try asking more questions to show others that it's okay not to know everything.
Comments