Software companies have lots of jobs. When you're new to tech, it's hard to parse the flowery language of job descriptions to understand a) what different roles do at a high-level and b) what role is the best fit for you. In this post, I'm going to share some of my learnings from working as a software engineer.
First, I'll describe the roles in EPD (engineering, product, and design) that you'll work with most often as a new-hire. Then, I'll dive into a software engineer role overview and what different types of engineers do at a high-level. Finally, I'll talk about how I decided to become a full-stack software engineer.
The most common roles for new-hires are:
For user-facing features, software engineers, PMs, and designers work closely together. You'll likely also have a manager. Here are some ways I interact with other roles:
I notice that PMs and managers have more meetings than software engineers. When choosing roles and career paths, think about how much you like facetime discussions vs. individual focus time.
As a software engineer, how do I spend my time at work? At a high-level, I write code, write words, and communicate with the team.
I write code. At a company, the development process involves steps that you don't often find in personal projects.
I write words.
I communicate with the team.
There are many types of software engineers. Depending on your field, you may need to consider the software vs. hardware dimension of different roles. This is not my area of expertise, so I only talk about software.
I'm a full-stack engineer. To understand what that means and what different types of engineers do, you need to understand what a tech stack is. A tech stack is the different layers of frameworks, languages, and software products that support the software. Each layer involves a choice in technology. For instance, in one layer, you could choose to use one programming language or another.
Why is the tech stack set up in layers? Software engineering is built off the idea of abstraction. That is, you can assume parts of a system are a black box: you provide certain input and get a certain output. This helps break down the problem and reduce the scope of different software tasks.
For example, I've built a site for song chords, MusicParsed (website link, source code). The tech stack for this project is:
As applications get bigger, one person can't manage everything, so people take roles at the different layers. Here's an overview of some types of roles you'll see:
Many other roles are also colloquially called back-end. However, this type of back-end development is not necessarily included in the scope of a full-stack role. It requires going deeper down the tech stack or deeper into how some technologies work. These roles are often more senior, but you can get into them by starting with back-end development.
When reading job descriptions and applying, take the list of formal requirements with a grain of salt. You don't need to meet 100% of them to apply. Even if you meet 0% of them, the worst thing that could happen is that you get a rejection letter (and you'll get plenty of those regardless). However, you can look for roles that are suitable for your general skill-level (e.g. internships or new grad roles).
There are a few sub-decisions behind why I chose full-stack software engineering.
If you're in school or taking computer science classes, classes are useful for deciding what you like or don't like.
1) Why computer science?
My decision here was pragmatic. I liked math back in high-school and knew computer science was related. My mom was a software engineer, so I thought that software engineering was a sensible career choice.
2) Why software (vs. hardware)?
My college had a combined electrical engineering and computer science field, so I took courses that worked with hardware.
I don't like dealing with faults in physical objects. Once I had a circuit assignment that didn't work. I struggled for an hour or two before a TA tried the same circuit on a different circuit board and it worked. I wish the first circuit board could have printed an error message instead of failing silently. With software, if there's a bug in code, it's usually your fault and not the computer's.
3) Why applied (vs. theoretical) computer science?
The computer science curriculum in college included both applied and theoretical computer science. Theoretical computer science includes algorithms, which are applied math. The applied classes involved more hands-on coding.
Though many concepts from theoretical computer science have important practical applications (e.g. algorithms for encryption or consensus), I didn't see a strong real-world connection for a lot of theoretical work. I wanted to build products that people could use, so I chose to focus on applied work and software engineering.
4) Why full-stack?
I started out wanting to be a front-end engineer. I took a class on user experience, and I liked thinking about products through a user's perspective. I also liked the immediate and obvious feedback loop in front-end development. You can make a change and see it reflected on a webpage.
However, in order to build more complex products, you need to learn back-end technologies. For instance, if you're building a login page, there's more to do than setting up the form fields. You need to know how to make the page available on a website, how to handle passwords securely, and how to interact with a database. This is how I built the login page for MusicParsed.
I write about my decision-making process with the clearness of hindsight, and my decisions were not half so clear when I first made them. A career is long, and it's okay to take your time thinking through different options. If you like software, I hope that this helped you think about how to find a specialty in software engineering.