The title “software engineer” might seem packed with assumptions and expectations, but in reality software engineering requires stripping away all unnecessary clutter to create the smoothest-running, most intuitive digital solution possible.
Software engineers helped create the webpage you’re reading right now, the web browser you launched to do so, the operating system that allowed it and the content management system that hosts it. Each one of those software applications — and the entirety of the broader digital environment, really — has undergone design, testing, maintenance, installation, configuration and programming. In a word, engineering.
How to Become a Software Engineer
- Plan your career path.
- Pursue a technical degree or software engineering courses.
- Practice your coding skills.
- Get certified.
- Build a portfolio that showcases samples of your skills.
- Apply to jobs.
Given its scope and high technical bar, software engineering is a highly lucrative field — the average salary for a software engineer in the United States in 2022 is around $120k — and also highly competitive.
In 2021, we spoke with Cassidy Williams of CodePen; Victor Ionescu, a Facebook and Google veteran, who did data infrastructure and core services for Airbnb; Max Heinritz, a Flexport software engineer who previously worked on Google Earth Engine; and Samara Trilling, a software engineer for Sidewalk Labs, the ultra-ambitious smart-city development wing of Google parent company Alphabet.
How Do You Get Into Software Engineering?
Senior Software Engineer at CodePen
Software Engineer at Airbnb
I started coding when I was 12, for a computer science class. As soon as I got into it, I was selected by my teacher to compete in algorithmics. So I competed for a few years through middle and high school. It was just something I was good at, so naturally I did computer science in college. It wasn’t meant to be a high paying job or anything fancy. I just started because I was good at it, and everything follows from there.
Software Engineer at Flexport
My first time coding was on a TI-83 Plus calculator in seventh grade math class. I built a few games for fun and tools for homework to answer questions like, “A ball is thrown one meter-per-second at a 60-degree angle. Does it clear a two-meter-tall fence 50 meters away?” Then I took some programming classes in high school, and my interest kept evolving from there. No one in my family programmed or used Linux or anything like that. So I just picked up bits and pieces along the way when I could. I sometimes wish I were a middle schooler or high schooler now — programming seems way more accessible than it was 15 years ago. But perhaps each generation feels that way.
Software Engineer at Sidewalk Labs
I’m from the Bay Area and grew up around a lot of people from tech, but I never thought of myself as going into tech. I was much more excited about politics. I went to school at Columbia [University, in New York] and took my first computer science class kind of on a whim my freshman year. I had never thought of myself as a math person or any kind of numerical genius. That was totally not how I identified. I thought, “That’s for people who really love spending most of their time thinking about math equations.” But my first CS class ended up being much easier than expected.
It definitely does not require genius. It was all about logic, not equations. It was a lot of collaboration with people that I really liked. So I kind of found my people in the computer science department in college. I knew I wanted to gather as many skills as I could in order to do something positive in the world. Now we’ve seen that computer science is indeed an incredibly powerful tool that can be used in many different ways, for good and not-so-good ends. Now is a really important time for everybody in tech to consider what they want to do with this skill they’ve honed.
I got my first internship when I was a sophomore. A friend really encouraged me to apply to some opportunities at Google. I went back to intern there, then started full time after graduation, working on Google Fiber — specifically on how we could give better Internet service to people who previously hadn’t had it.
Are Programming Certifications Worth It?
Williams: It depends on the company you’re speaking to. Some companies are like, “Oh, well, they did this cool project on GitHub and that’s all I need to see,” or, “They have a bunch of cool Pens on CodePen and that’s all I need to see.” But some companies that want to know more about your academic background or how you learn, they actually care about a degree or some kind of good certificate — though I do think that the industry is trending towards not caring about that as much.
A lot of what I do today are things I taught myself. For example, with web development, a lot of more theoretical computer science concepts are moving more and more into the front-end development world. It’s really nice to see, because I can actually use my degree and understand, “Oh, GraphQL — that’s using a graph. I studied graphs,” and then go deeper into how you actually use that. So it’s nice that I can use my traditional background brain, but I don't think it’s necessary to be successful in the field.
Ionescu: It’s a culture thing. I personally don’t do a lot of open source. I just don’t have the time for it. And when I have a project, I keep it private. I can tell you that in the industry, if someone has a lot of open source projects, that can serve as validation, because if a lot of people are using your code, then it must be working, right? And if you actually wrote it, then you probably are a pretty decent programmer. But if you don't have that, I definitely don't think that's a drawback.
Because a lot of people working on complicated things — like, for example, infrastructure people working on databases, or people working at Google or another company that doesn’t really have a huge open source culture — just go in and upload your code. But yes, if you have it and it’s used, in the programming community it does say something. There's a sample of your work. That’s good in every industry.
Heinritz: I don’t think I’ve ever given consideration to a candidate’s programming certification during the hiring process. GitHub repos might be useful in three ways: getting past the initial recruiter screen to get a phone screen, having some interesting projects to talk about during your interviews or nudging your application through hiring committee borderline cases.
The number one thing people underinvest in is practicing the coding interview. Do it every day for weeks if you’ve never done a technical interview before. I highly recommend the book Cracking the Coding Interview and the sites that help you do practice problems. It’s a trainable skill.
Trilling: Within the job interview process context, most companies still do face-to-face programming interviews or online coding challenges. For programming certifications, I think it’s just not something that has really caught on.
I do think there’s a lot of value in contributing to open-source work and code online in general. It helps build confidence and it gives you a place to track your own learning. But employers want to have in-person experience [demonstration] as well. We actually do something at Sidewalk Labs in the interview where there’s a question that you sort of work through with another engineer in the room. And the idea is that you’re the main engineer on the project and that you have to hand it over to the other engineer at the end of the interview.
Those more experiential interviews tend to do well in seeing how somebody collaborates, how they explain their vision, which I think is more important than whether or not they know a particular [programming] language. Because a lot of people can pick up languages pretty quickly. It’s really much more about your ability to build the right thing, work with other people and be collaborative.
What Soft Skills Does a Software Engineer Need to Have?
Williams: I think it’s less about soft skills and more about core skills. If you’re able to communicate, able to write — honestly, communication is what it all boils down to. That’s so key for being successful in the industry. You need to be able to write good documentation. You need to be able to voice your opinions in meetings. You need to be able to communicate to the team, so that if you leave for whatever reason or need to pass off your code, people can take it and run with it and not be entirely dependent on tribal knowledge. That is the top skill to have, and it’s a core skill that everyone needs. Because if you aren’t able to talk out something, you’re just going to end up being a code monkey that won’t really work well with the team.
Ionescu: It’s really hard to get stuff done by yourself. And I’ve noticed particularly in companies that are slightly younger, it’s best to have some program management skills: getting people organized, trying to make them keep you up to date. Everything that requires group effort in terms of execution could benefit from synergy, right? You have to create synergy with coworkers so that everyone knows what each other’s working on, and how far along they are. One thing that happens quite often is that people get distracted, and sometimes you can actually lose track of what you’re trying to accomplish. So you can’t be pragmatic in terms of delivering something. I think that’s one of the most important things. And, of course, being a people person who can easily communicate with others and maintain work relationships.
Top Soft Skills Every Software Engineer Should Have
- Written and verbal communication
- Ability to be a team player
- Ability to meet deadlines
Heinritz: Written communication is the single most important non-coding skill in my experience. Verbal communication is important, too, but written communication scales more broadly. Writing design docs, blog posts, onboarding guides — these artifacts massively increase your leverage. I recommend Edmond Lau’s book The Effective Engineer for more on the topic. His framework about leverage — the value produced per unit of time invested — helped me appreciate the importance of soft skills in general and written communication in particular.
“If you aren’t able to talk out something, you’re just going to end up being a code monkey that won't really work well with the team.”
Trilling: Soft skills are engineering skills. I don’t know any engineer who’s successful without being a good communicator. And I don’t know an engineer who wouldn’t be a better engineer if they weren’t a better communicator. So learning how to explain and teach well — not just to make yourself feel smarter, but to really give the other person the chance to learn and ask questions. That’s the way really great engineering organizations grow. At Google, I felt really encouraged to ask questions. And as an engineer, if you’re mentoring somebody who is newer to your team or newer to the language you’re working on, the best way to increase the velocity of everybody’s productivity is by being a great teacher.
Are Coding Bootcamps Worth It?
Williams: Bootcamps are a viable option for sure. I don’t know if I would say on top of an existing technical degree, because so often they’ll be teaching things you might already know or be capable of learning a lot faster. But for someone making a career change. I will say that in doing a bootcamp, you learn a lot in a short period of time, and it’s very specific information. If you go that route, you should pay attention in class and do all the projects. But also be ready to learn more beyond the bootcamp, go a little bit deeper. Because there’s a lot to learn not only about how to do something but why something works. That’s key to being a successful bootcamp developer and an eventual employee at a company.
Ionescu: I think bootcamps are good for people who have what it takes, but they might not be a great indicator for people who could have what it takes but need more time. When I first started coding, I didn’t quite understand anything that was going on in the class. We had all these theory classes like, you can program things to perform certain actions depending on what you want. And to me that sounded too abstract. But the moment I was facing the computer I was like, “Oh, that’s just code. That’s how it works. Cool. I got this.” Day one, I can code. I think because I had it embedded in my brain that I could actually take that thing and use it in a particular way.
Now you don’t need to have that embedded in your brain in order to be a good programmer. If you have it, then I think bootcamps are great. I do think that some of the bootcamp programs are very intense. The risk is that if you get lost at some point, then it’s really hard to recover. Like, if you don’t get it at a particular point in time, you might just get left behind and think you’re a bad programmer. But in reality you just needed more time to develop the concepts in your head. So they’re good and bad. Are they worth the money? Sure, if you want to get a job out of it, I think that’s a good place to start. If you have a bit more time, I would recommend taking it easy and maybe getting a computer science degree. Or try to work on something in your free time without having expectations of income from it.
Programming Languages Software Engineers Need to Know
Heinritz: I can only provide anecdotes. One of my college friends studied economics, worked at a tech-based consulting company, went through a bootcamp two years after graduating and ended up working as an engineer at Google. So for him, it was definitely worthwhile. My dad also went through a bootcamp. He studied fine art painting in college and became a craftsman carpenter. He’s been semi-retired for a few years, and we thought programming might be a fun next step for him. The craft of programming is often compared to the craft of woodworking. But he found the content hard to digest, and it didn’t end up going anywhere. So it wasn’t worthwhile for him.
Trilling: Just like a lot of other educational programs, a great bootcamp is fantastic and a not-as-great bootcamp is not so useful. There’s a great company in New York City, Cityblock Health, that has done really well hiring many people from bootcamps, and that’s worked out incredibly well for them, in addition to a lot of people with various backgrounds in computer science.
But even in my career, maybe only half the people I’ve worked with have computer science degrees. A lot of people studied a different part of engineering or philosophy or got a minor in history. And I think that actually makes people much better engineers overall, when you don’t have such a myopic view of the field and you understand why you’re learning these skills. So I do think bootcamps can be really valuable, especially if you’re somebody who likes to learn socially, to make sure you have a cohort of people who are learning alongside you. Even at Google, I think they’re working harder at recognizing that there’s all this tech talent out there that doesn’t look like somebody who went to MIT and got a computer science degree.
The development world and all those roles are going to be expanding so much in the future that I think that it’s really important not to be weird and elitist about the way [people] learn.
When I taught at Make School in San Francisco, which is now an accredited program, we liked to teach and learn by making stuff. And it tends to be pretty self-driven, but there’s also a lot of community and ROS development in their summer academy. There are more options now than there ever have been for alternative learning experiences. And just like anything else, you don’t want to invest a lot of money in something you don’t think is going to pay off. So be sure to know your learning style. There are some well-known bootcamps, like General Assembly, that have good track records and do a good job of being transparent about their success metrics. That’s an area you want to check up on pretty carefully before you choose one.
What’s the Difference Between a Software Engineer and a Developer or Programmer?
Williams: A lot of times those terms are very interchangeable. If there is a difference, I tend to think of an engineer as doing a lot of the architecture side of things and not just coding. Coding is a big part of each role. The real differentiation, if you were to make one, is that the software engineers actually plot out the requirements and architecture of a system, like how pages and data are organized overall, and visualizing with designers and other stakeholders how the software will fit in the narrative they’re building. The engineer does a lot of the architecting and theoretical work before actually writing any code.
Ionescu: I don’t think there’s any difference. I think a lot of these are just titles. Experience dictates the grade of accuracy and quality your work has. So you can be a software developer, internet programmer — call it whatever you want. Depending on your job, you might be coding different things. Sure, a web developer is just going to be a web developer, but a programmer could program anything from robots to webpages. Particularly in the Bay Area, where everything is web- and infrastructure-oriented, what makes the difference is approach and experience and quality of work.
Heinritz: I think the distinction is mostly in career branding and marketing. See Patrick McKenzie’s excellent post “Don’t Call Yourself A Programmer, And Other Career Advice.” In my experience, “programmer” generally connotes hobbyist, whereas “software engineer” connotes professional. But non-technical folks care much more about this sort of thing than people coding.
What Questions Would You Ask a Prospective Employer in an Interview?
Williams: One thing I always ask employers in interviews is, “What’s more important: the employees, the product or the customers?” There’s no real wrong answer, but it’s a really good indicator of the company’s priorities. For example, when I was at Amazon, [it was] customers first; when I interned at Intuit, it was employees first. It varies from company to company. But the difference is, when you’re onsite and asking multiple people, for example, like one round after another, and they all have different answers, then I know that there might be some sort of communication issue or it might be different across teams. Then you need to figure out what kind of team you want to be on. And then I use that question a lot as a metric for figuring out, is this the kind of team that I want to join?
Ionescu: What I try to do every time is gain knowledge in something different. So of course I want to work for a nice company and not an evil company. That’s the standard, right? And you need to believe in the product you’re building so you actually feel motivated. But at the end of the day, as an engineer, if I were to switch jobs right now, I [would] want to work on something that really teaches me stuff. So I wouldn’t want to be too comfortable in my job. I’d ask about opportunities in terms of growth, because the best way to learn, particularly as a senior engineer, is to get into areas that are not particularly known.
So I ask about opportunities for growth and open problems that the company has. And Airbnb had a lot of open problems when I joined. It felt like a really good place to develop as a software engineer, and I was right. I definitely learned more in my first year at Airbnb than I learned in my two years at Facebook. So that was a good choice. But at the end of the day, I think what’s going to differentiate a really great software engineer in the Bay Area today — because software engineers pretty much grow on trees here — is the extent to which they have knowledge of different platforms.
SOFTWARE ENGINEER SALARY & JOB OUTLOOK 2022
Heinritz: I would first identify what I’m optimizing for in my job search, and then ask questions that would help me evaluate whether this company could help me get there. In my most recent search, I was optimizing for: growth, real-world impact, day-to-day flow, full-stack roles and open source frameworks. So I asked questions like: “I like to work on maps. What are you doing with maps?” “Why are you excited about Flexport’s future?” “How much time did you spend coding yesterday?” “What tools have you used this week?” More specific is better.
Then there are some questions that will give insights no matter what you’re optimizing for. I came up with the following list by reflecting on questions that interviewees have asked me that were fun for me to answer and revealed something I otherwise hadn’t shared. “If you could wave a magic wand and change one thing about your job today, what would it be?” “Why did you decide to work here?” “What’s your favorite thing about working here?” “What are the biggest challenges facing your team today?” “How does working here compare to working at company X?”
The number one thing is: always have questions to ask. It's a bad sign when a candidate isn’t curious about anything.
Trilling: One important question is, “If your company were really, really successful, who would that benefit and who would that not benefit?” It’s a question that maybe we wouldn’t have necessarily asked five years ago that now definitely feels of the utmost importance. And the question of, if someone were to take your test model to the extreme, what would be the consequences in the world for that model? Is the way you’re creating value fundamentally extractive or fundamentally generative?
I also try to figure out how humble people at the company can be about what technology can accomplish. And if your goal is to solve a problem, then are you willing to explore potentially less technically cutting edge solutions if they’re better to actually solve the problem? Because I think it's really easy to get caught up in, “We’re going to use machine learning in order to solve this problem.” But what if the problem doesn’t require machine learning? Do you still want to solve the problem, or just work on machine learning?
Figuring out how collaborative the working environment is important, too, because I think that’s often a proxy for how much you can actually get done. “Do you prefer programming? How do you communicate dividing up work, and working together? Is that valued?” If everybody is working on their own tiny part of something, in reality you often don’t have somebody whose job it is to stitch it all together, and that’s where the real work gets done. Those tend to be the places where great stuff happens.