What is QA software engineering?

QA is a very dynamic field. Different companies and products have different needs when it comes to quality assurance, which also requires different skill sets. Lately, I’ve seen a rise in titles like “software engineer in test” or “quality assurance automation engineer.” These terms often get lumped together because, in many companies, QA focuses more on writing automation and validating quality through code. In others, QA is still largely manual testing, where someone literally clicks around a site and tries to break things.

The approach depends on the product, how it is used, and how it needs to be tested. If a product is not widely or frequently used, it’s often faster and more cost-effective to test it manually rather than hire someone who can write automation code and architect complex systems. That’s why the role can vary so much. Personally, I tend to stay closer to the software engineering side of QA.

I graduated from school with degrees in computer science and anthropology. During an internship, I worked as a QA intern, and just working through the field I found myself collaborating more closely with developers. The products I supported required automation rather than manual testing. Companies often use terms like “Greenfield” or “Incubator” to describe teams building new products from scratch rather than maintaining existing ones. These are the environments where automation is easiest to introduce.

That experience evolved into my full-time role, and it’s still the path I follow today. I stay very close to the software engineering side of QA.

What made you pursue computer science and anthropology?

Growing up, I was always interested in computers, and like many kids, I loved video games. When I started university, I thought I wanted to learn how to make them. That’s actually a common story in computer science until many of us realize that video game development is not what we imagined as kids.

I found that I was not a very creative or artistic person, and there’s a large section of game development that’s art, storytelling, and design. The other side of it is programming — getting the computer to do what you want, which is often very math-heavy. Computer science in general can lean heavily on math, and I discovered that kind of programming was not what I enjoyed.

What I did enjoy was programming itself. From there, I opened myself up to any industry that involved programming. I was not focused on a specific field; I just wanted to work in a programming role. What really drew me in was the chance to work with people and solve problems collaboratively. I didn’t care as much about the specific problem being solved. That is essentially how my role evolved and how I found my way into the field.

As for the anthropology side, it’s mostly unrelated to what I work on now. While I was at university, they were starting a program called the CS plus X program. I think it is fairly large now, but at the time it was just getting off the ground. I worked with some of the faculty to figure out different majors. Initially they offered computer science and math, computer science and astronomy, computer science and chemistry, and a few others. Computer science and anthropology was one of the options.

Since I didn’t really care as much about the specific problems I would be working on, I chose computer science and anthropology after reading a bit about it. I wasn’t particularly looking for a direct application of that degree, but I feel it was very beneficial to have that side of my studies because it opened my horizons and gave me experience outside of computer science or a strict engineering focus. It was very beneficial for me to get a wider breadth of knowledge.

On the anthropology side, I focused on virtual communities. My capstone paper was on the video game streaming site Twitch.tv, where I explored why people go to a space like that and why they choose to watch. I drew heavily from sociologist Ray Oldenburg, who wrote The Great Good Place and coined the terms of first place, second place, and third place. The first place is home and the people you interact with there. The second place is work and your interactions there. The third place is a setting that’s distinctly neither home nor work where you go to socialize—such as bars, coffee shops, or similar spaces where you interact with people outside your usual circles.

I argued that Twitch.tv functioned as a kind of virtual third place. That argument probably has even more impact today, after the pandemic, when remote and virtual social interactions became much more common. At the time, though, I kept the focus on the anthropology side of the degree while also touching on the technical aspects of how computers enable that kind of interaction, which allowed me to marry the two areas of study together.

Can you tell me more about the companies you’ve worked for, and how your role fits in?

My last company was a ratings and reviews company. When you shop online and read reviews, this company was often the service behind it, aggregating reviews across multiple customers. Instead of each retailer like Target or Walmart trying to solve the problem of how to store reviews and build the schema for it, they outsource that work to this company. The company handles the infrastructure and makes the reviews consistent and cohesive across different platforms.

In my role at that company, I was writing automation to validate the system on the backend. I worked mostly on backend testing, though I did some frontend testing and validation as well. The goal was to make sure those systems were functioning as expected.

Because this was a software-as-a-service company, the validation had to be ongoing. It’s not like you can write one test, confirm it works, and assume it will be good in perpetuity. That’s not how software works in general, and especially not with SaaS, where the service is constantly running with data coming in and going out. You have to validate that the system is up, that it’s running properly, and that all the expected inputs and outputs look the way they should. That was a big part of what I tested at that company.

It’s pretty much the same at my current company as well. Instead of ratings and reviews, it was e-commerce, but the systems and testing were very similar. The work was about validating the health of a service that runs in the background and is constantly being used by businesses.

In general, the goal was to capture metrics that could then be aggregated for things like advertising or making business decisions about what to change. You want to gather all this data about people, and my job was to write software that tested the systems responsible for grabbing, aggregating, and storing that data.

What software engineering languages do you work with?

I started off working primarily in Java, which is a massive language utilized in the web space. It’s very common, beginner-friendly, and easy to write in, which is why most college courses tend to use Java or something similar. That being said, a lot of what I learned at university wasn’t about learning one language but about learning how to use and write a language. You pick up whatever language is best suited for the problem you’re working on.

At my last company, most people used Java across the frontend and throughout the stack. But I often worked with a team that used Scala, a language based on Java that runs on the Java virtual machine. So essentially, if you can run a Java program, you can usually run a Scala program as well. Scala is considered a functional programming language, which is a different paradigm from the object-oriented approach Java was originally built on. Because of my experience interfacing with Scala and learning to think about problem-solving in that functional style, it’s influenced much of the work I’ve done since then.

When I moved to the next company, most of the work there was in PHP, which is an older but still very ubiquitous language, like Java. But the team I joined didn’t just use PHP. They worked with a language called Clojure, which is a purely functional language. I was brought onto that team largely because I already had interfaced with functional programming, so it was natural for me to join that team.

You’re going to see different languages pop up in companies all the time. In general, when a new programming language is created, it’s written to solve a particular problem. I can’t speak to the history of all languages, but functional programming is particularly well-suited for streams of data that are constantly coming in and going out. You focus on the function as the main unit of work, which made sense for that industry and the problems being solved.

In other areas, especially hobby programming, you’ll often find languages like Python, which is much easier to read but not as performant. With programming languages, you choose the language based on what you need the language to do, and you solve the problem from there.

A lot of the syntax you see across languages is very similar because all programming is ultimately based on math. That foundation of math and logic is consistent throughout. You choose your language based on the problem you’re trying to solve and whether that language is the right tool for the job.

What is the learning curve like when it comes to picking up new programming languages?

There are a crazy number of variables when it comes to how learning languages looks for different people, depending on the kind of problem they are trying to solve and why they’re trying to learn something. We’re seeing more of this with the explosion of tools like Raspberry Pi, which has brought in a lot more hobby programmers. They often start with a language that is easy to pick up.

One of the main reasons Python is so popular is that it was written to be human-readable. You can look at the code on a screen and quickly understand what the program is doing. That can happen across many languages if you understand how they function, but some are much harder to read because of the weirdness in the syntax.

For example, Clojure is a Lisp language, which means there are parentheses everywhere, and everything is encased inside them. The way operations are applied within those parentheses is very particular, so it’s not easy to read at a glance unless you already know how the language functions.

That being said, we are seeing a lot more people becoming interested in programming and how it works, and it’s much easier to approach now because of languages like Python. Python has been around for a long time—so this isn’t something that happened within my lifetime—but the interest has grown at a much higher rate in recent years. With the explosion of tools like Raspberry Pi, it’s become much easier for people to set up a system at home and start learning.

On top of that, we are seeing a lot of introductory languages being created. Companies like Brilliant and others build tools that teach the logic behind programming languages. For me, that logic was what really clicked. If you’re interested, you can dig into the math of how a language functions.

At university, I took a class all about writing languages. We used a language called Racket to write a subset of another language called Scheme. The point of the exercise was to understand the discrete math and logic that underlies how a programming language functions. That in itself is an entire field, and some people become very interested in that aspect.

Because programming is such a wide field, you are going to have many different people solving many different problems, and the learning curve depends on the problem and the tools required. C++ is notorious for being difficult to learn because it’s close to the hardware, very math-heavy, and abstract. You run into advanced computer science concepts much faster in C++, which makes it a tough language for beginners. By contrast, languages like Python—and even now Java—tend to have a much gentler learning curve.

In the end, it really comes down to whether you enjoy solving the problem in front of you. I don’t know that I could give a single piece of advice to someone wanting to learn a programming language, other than to figure out what problem you want to solve and then find the best tool to solve it.

Are there any differences between the work in your last role and the work in your current role?

Yes and no—it all depends. When I moved roles, I moved alongside many of my peers from the previous company, so I still work with a lot of the same people on very similar problems. In that sense, the work feels the same. That being said, you don’t carry software from one company to another, since that’s protected under IP laws. So even if the problems look alike, they’re never exactly the same. In our case, the problems were slightly different, but the advantage was being able to use all the experience we had gained—what worked, what didn’t, and how we could do it better. Sometimes that meant realizing we had chosen the wrong tools, the wrong process, or thought about the problem in the wrong way.

Some of the differences also came from the move itself. I went from a company that used Java to one that used PHP, so the problem space shifted because the base technology was different. Beyond that, the industry itself evolves. As technologies mature, it becomes easier to make the case for using them to solve new problems, especially once you’ve had some exposure through things like hackathons. Companies run hackathons differently, but usually they’re a chance to explore problems you don’t have time to tackle in day-to-day work. Sometimes those experiments become real services or products, and sometimes they don’t, but the knowledge is what matters.

When many of us moved to the new company, we brought that learning with us. And because this company is much larger, the environment is different too. At my old company, most of the knowledge lived in one office. Now there are offices all over the world, and we often work with systems built by people we don’t interact with directly. Instead of building everything from scratch, a lot of the time the question becomes: has this problem already been solved? If so, how can we adapt that solution to fit our use case? The problem-solving shifts from “how do I build this from the ground up” to “how do I make something that already exists work for what I need.” That’s a different way of approaching the work, and another big difference I’ve seen

What might a typical week look like in the role?

In my experience, software work is never the same week to week, let alone year to year. There are positions where you might be maintaining a legacy system, working on the same piece of software every day. In those cases, you may not even be writing new code—you might just be updating versions or fielding support requests when something breaks. That can become very patterned work, where you are doing the same thing day in and day out. But that is not always the norm.

Even at my current company, I’m not working on the same product I started with. Many engineers change products or teams on purpose. I remember a study on burnout in programming that found engineers don’t usually burn out because of long hours or being overworked. Instead, it often happens when they have been working on the same thing for too long. They crave a new problem to solve, and when they don’t get that, they burn out. That is one reason some engineers leave companies—not because of workload, unfair compensation, or hours, but just to find a new problem.

Some companies try to combat that by hosting hackathons, where people can break out of their usual work and explore new problems, products, or services. It helps break up the routine. That has been my experience as well.

I enjoy having regularity for a while, but eventually it does get monotonous and you start to crave something new. I’ve had stretches where the work was very straightforward: a feature needed to be delivered, so I spent weeks just writing the code for the feature or writing tests for it.

Then there were other stretches where things shifted completely. For example, when a very large client was onboarding onto a product, it created major challenges. They carried a lot of weight in terms of support demands, and they also put heavy pressure on the system itself. During that time, most of my work was focused on solving their specific problems within our software. It involved a lot of support, logging directly into machines, and essentially acting as a detective—figuring out what was breaking, why it was happening, and how to fix it.

I’ve also had long periods where we didn’t write any code at all or even really interface with the code. It was entirely about design—thinking through the best approach and the kind of work we needed to do to solve a problem. Often in those situations, you aren’t actually writing code but discussing it: what’s the best technology to use, how quickly can we get it done using this technology, and how will it interface with other products? You might literally have days or weeks that are spent almost entirely in meeting rooms, talking through those questions rather than coding.

I’ve never been able to predict when one of those situations will start or end—they just happen. I’m okay with that in my workstyle. I’m a naturally anxious person and change stresses me out, but like most people, I also get bored if nothing ever changes. It’s really just a balance of working through both.

What kind of skills and qualities should a person have to be able to thrive in this role?

When I was growing up, computer science had the reputation that if you worked with computers, you didn’t really work with people. In my experience, that has never been the case. Communication is the primary skill you need in this field. Unless you are entirely your own boss, you are always going to be working for or with someone to solve problems collaboratively.

That means if you’re writing solutions, you need to communicate effectively about why and how. You have to be able to explain why your idea is good, or why you think someone else’s idea might not be as strong. You also need to coordinate with peers while solving problems. For example, in a production outage when services are down and alarms are going off, most of the time it’s not one person logging in and fixing it alone. It requires multiple people diagnosing the issue together and figuring out how to get things back up and running.

Even outside of those urgent moments, communication plays a role. In disaster recovery, or even just in day-to-day work, you are often communicating with the future—sometimes your future self. You need to be able to write effective documentation such that you could go back and understand it. Other times, you may be writing documentation for people who aren’t even on the team yet. Because this field can change quickly, you need to write so that any arbitrary person coming in later can read it and understand.

You also can’t rely on knowing what someone’s competency in writing software will be when you’re writing something for the future. That’s never a given. This is why communication is so important—the ability to simplify what you’re trying to get across. And generally, you need to do it quickly.

A quote I really enjoy, which has been attributed to many people, is: “If I had more time, I would have written a shorter letter.” That idea shows up everywhere in computer science. It’s about taking something complex and simplifying it as much as possible. Sometimes that means shrinking your code, concepts, or language into smaller, easier-to-consume pieces. Other times, it might mean breaking down a large onboarding process into clear, digestible steps such that you don’t need to physically sit next to someone walking them through it.

I’d say that communication is probably the primary skill I’ve relied on. Picking up a language or tool usually happens by talking with peers, especially when you’re new to the industry. You don’t graduate from college and immediately start designing and architecting systems. Most of the time, you begin by working on something that already exists or is in the process of being built. That means communicating with the people who built it or are building it, to figure out how to solve whatever problem you’re given. You’ll pick up the language and technology along the way, but it happens much faster and more effectively if you can communicate effectively with the people around you.

What do you enjoy the most about your role?

It really varies day to day, depending on what’s interesting to me at the time. The way I tend to work, I usually find a mentor for whatever I’m focusing on—often the team lead or the person with the most knowledge. What I enjoy most is learning how to solve a problem.

I get frustrated if I don’t feel productive, and I’m very self-critical about that. I almost always feel like I have terrible imposter syndrome, like I have no idea what’s going on. That happens a lot when you’re writing software. You might stare at the code for three days, convinced you don’t understand anything, only to discover you just skipped over something small.

There’s a long-running joke in software: you’re looking at a software problem, you start questioning your career, then your life, you start questioning—oh wait no, it was just a typo, you fix it, it’s no problem. It wasn’t even that the solution was grand, or that you had a shining moment of intelligence or creativity to solve the problem. It was just a typo.

The actual code being written is less interesting to me than understanding how other people in the industry think about solving problems. I like figuring out how they work and seeing if I can integrate that into my own approach. I try to learn from people I consider successful, whose methods and perspectives I agree with, and apply what I can from them.

Programming is full of opinions about how things can, should, or will be done, and naturally there are differences of opinion. I enjoy finding people with strong views who can convey them, and deciding whether I agree. I also enjoy talking with people I disagree with, to understand why our thoughts differ. What I find most interesting is working with others who have more knowledge than I ever will in particular areas and learning from them.

How do you seek out mentors or peers whose knowledge you want to learn from?

That can vary widely depending on the company and its culture. The way I’ve found people is usually by looking to the team lead I work with. Software teams aren’t huge—ten people is considered large. My current team has seven. So it’s not hard to find the individual who has the most knowledge and can communicate it clearly. I tend to stick with the people I directly interface with anyway.

That said, there are plenty of opportunities if you find you’re not learning much from your immediate group. Different companies have different ways of sharing knowledge across the organization. No company wants a single point of failure where one person leaves and all the knowledge disappears. So knowledge-sharing is built in. Often you need to demo your work, which lets you see how others solve problems and compare it to your own approach. Many companies also host lunch-and-learns, where someone presents a project or an interesting solution over a brown-bag lunch, and those are good chances to connect.

Even outside of work, there are ways to find people. Some cities host startup crawls, where tech companies organize meetups across different bars or restaurants. If you go to those, you can bump elbows with people from other companies and talk shop.

When I was younger, I thought everyone in computer science—or engineering in general—wasn’t especially sociable. Not because they didn’t want to be, but because social skills aren’t what people usually associate with engineering. What I’ve found, though, is that if you can get past that in yourself, it becomes much easier to find opportunities to connect with others who know something valuable. So much of this field is about communication—whether it’s with your future self through documentation, with an unknown person who comes after you, or with colleagues inside your company. If you need to find someone, think of them as your target audience—or become theirs—and use that connection to learn, grow, and get better at your role.

What are your ideal next steps?

I’m very stable and happy in my current role and the work I’m doing. I don’t have big plans for where I want to take my career right now. I’m enjoying what I do.

That being said, if someone does want to plan ahead, I think the best approach is to find someone who has already taken the step you’re interested in and ask them how they got there. Some people want to come into computer science and move up the ranks—engineer, lead, architect. The key is finding people who do those jobs well and testing yourself against that path to see if it’s right for you.

For me, I just enjoy finding interesting problems and interesting people to work with, and I’m content with that. Because of the dynamic nature of my work and what I’ve experienced so far, it’s not easy to stick to a rigid plan about which technologies I’ll be working with or what I’ll learn next. Instead, it’s about creating opportunities for myself and making the case for why I should get them.

What advice can you give to others?

It’s all about communication. You need to share what you’re working on and what you’re working with. If you’re in the industry and can’t share proprietary code, find ways to abstract it and still share the knowledge. That could be through a blog, with friends, or with coworkers. You can also start personal projects and explain them to someone.

For progressing in your career, like I mentioned, you need to share your work with others. Personal projects can help with that. Many programmers don’t code outside of work, but if you can find something to build and share, it will help you grow. You’ll be exposed to different ways of solving problems and meet people who might later become teammates or leaders as you move up. The key is being able to communicate effectively about what you’re doing and how you’re doing it.

In my experience, the best way to grow in your role is to teach what you know to someone else. You truly understand something if you can explain it clearly. That kind of understanding not only proves it to yourself but also shows others your capability, and that’s how you grow in the role.

If you’re looking to get into computer science, it really depends on your hows and whys. You don’t need a computer science degree to program. One of my mentors started as a material science engineer—he literally worked with his hands in his professional role. But as part of that role, he had to do more programming. He taught himself, and now he’s a full-time programmer. That’s one way into the industry. You don’t necessarily need school for it.

For some people, though, academia is valuable because it exposes you to many different kinds of problems you might solve with programming. Either path works. But the advice is the same whether you’re just starting or already in the industry: teach what you learn to someone else. Show your friends, your coworkers—anyone—what you’re working on. If you share in good faith with someone who knows more, they’ll point out where you might be wrong or suggest better approaches, which naturally creates opportunities for growth. And if you’re teaching someone who knows less, it at least proves to you that you actually understand what you’re working on.

Who might not be a good fit for this role?

It’s a difficult question to answer because you have to make assumptions about people. I think anyone can learn how to program—it’s really a matter of whether or not they want to. It will be difficult, and the level of difficulty will vary depending on how someone learns, where they can learn, and who they have to talk to. I’m a firm believer that if you have the desire to do something, you can eventually get there. The question is just how much work is going to be required of you.

In school, things came easily to me at first, but when I got to university, I quickly realized I knew nothing. I was not a great student. I had been a big fish in a small town, and suddenly I wasn’t. What it taught me, especially after shifting into the CS+X program and taking on anthropology, was that computer science could be incredibly difficult. Getting into discrete mathematics was especially challenging. I had always been strong in math in high school, but at university, math became far more complicated. Even now, I still run into problems at work that make me question my own knowledge.

But the theme throughout my experience has been that it’s possible. You just need to find the right people and persist. Anyone who wants to can get into this industry—it’s just a matter of how much time and effort it will take for you personally, and whether or not you’re willing to put that in.

What did you learn on the job?

Everything I’ve learned, I’ve learned on the job. There were really only two classes from university that I’d call formative for my programming knowledge. One was a crash course in four programming languages. The point of the class wasn’t to master those languages or even to solve the specific problems. It was about learning how to pick something back up. We’d write something in one language, switch to another with a brand-new problem, move to a third, and then come back to the first. The exercise was about adapting quickly and relearning how to work with old code.

The other formative class was the one I mentioned earlier, where we wrote our own programming language. Both classes were really about self-documentation and building an understanding of how you approach problems. Because in reality, very few courses cover the exact work you’ll be doing in the industry. Programming spans such a huge problem space that you could never learn everything in school.

Almost all of my real programming knowledge came from working on the job with technologies I never touched at university. In school, we started with C++ and then Java. While the company I worked at later primarily used Java, I did almost all my work there in Scala. I was also using frameworks you’d never see in a student setting. That’s why I tell people who want to get into computer science: you’ll learn so much more by doing, and that usually happens on the job or through personal projects rather than in a classroom.

From my experience, professors understood this too. Even when you take online courses or watch tutorials, they rarely teach you how to solve the exact problem you’re facing. More often, you end up Googling, digging through Stack Overflow, and piecing together bits of information. It’s almost never a neat, prescriptive process of “do this, then that.” Computer science may be about telling a computer to do something and watching it happen, but in the larger, more complex problem spaces, the only way to really learn is by doing.

That’s why I emphasize communication. If you don’t know how to do something, you probably won’t find an online tutorial that tells you exactly how—unless it’s a very narrow problem. If the problem shifts even a little, you need to experiment and try it yourself. Looking back, one mistake I made in university was not applying myself more outside the classroom. If I had taken internships earlier, or stuck with personal projects longer, I would have understood programming more deeply before entering the industry.

It wasn’t until I had my first internship and real work experience—working with people, solving real problems—that I really connected with programming. The classes were useful, but the real learning happened when I started applying it in the real world.

Would you consider switching industries?

I don’t feel any need to switch industries for financial reasons or job function. I enjoy the work I do, and I expect I’ll continue to enjoy it. But one thing I think is worth calling out for any role is the importance of finding skills and interests outside your main area. During the pandemic, I picked up a lot of hobbies just because I had the time. Exploring those hobbies and learning new things showed me that solving problems outside of your normal headspace can often help in ways you don’t expect.

One example that stuck with me came from a talk I heard at a programming convention. The speaker spent the first half of his hour-long talk on woodworking. He was a woodworker before he was a programmer, and he used that hobby to explain his perspective. In woodworking, you can rely on shop tools—planers, jointers, and so on—that solve specific problems. But every tool has limits, and eventually you’ll run into a project that falls outside those bounds. Hand tools, on the other hand, remove those limits. They require more work, more effort, and more time, but by understanding how to use them, you free yourself from the constraints of specialized tools. His talk, called Programming with Hand Tools, applied this to software development: instead of always relying on an integrated development environment with everything pre-set, sometimes you should try solving the problem manually. Even if the problem is already “solved,” the act of working through it can reveal boundaries you didn’t realize were there. And sometimes the better tool isn’t the best solution. Sometimes it’s better to “downgrade” your tools and work through the fundamentals.

That kind of juxtaposition of knowledge is valuable in any career. Having hobbies or interests outside your industry gives you new perspectives that lead to those revelations.

The thing about blind spots is that you can’t see them—they’re your blind spots. By approaching different problems in different ways, you give yourself a new angle. That’s why I think it’s so beneficial not to focus too narrowly on one thing. Learning something new, even in a completely different field, can expose blind spots you didn’t even know you had. Simply asking yourself “what are my blind spots” won’t reveal them—but learning from other perspectives just might.