“Any idiot can build a bridge, but it takes an engineer to build a bridge that barely stands.”
That chestnut — that good engineers make things that work, but don't see a need to over-engineer them — relates specifically to structural engineering, but it’s also a great fit for software engineering. Like its built-environment cousin, software engineering requires stripping away all unnecessary clutter to create the smoothest-running, most intuitive digital solution possible.
That encompasses a ton: the webpage you’re reading right now, the web browser you launched to do so, the operating system that allowed it, 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, programming (more on that later). In a word, engineering.
Given its scope and high technical bar, software engineering remains highly lucrative stuff, and also highly competitive. We spoke with two Bay Area-based software engineers, both of whom has experience at some of the biggest firms in tech, about how they sharpened their skills and advanced in the fast-changing industry.
We spoke with Victor Ionescu, a Facebook and Google veteran, who is now doing data infrastructure and core services for Airbnb; and Max Heinritz, a Flexport software engineer who previously worked on Google Earth Engine, owns an enviable San Francisco loft and moonlights in lamp design.
How did you first get into software engineering?
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.
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, and I lived in the Denver suburbs away from tech. 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.
How worthwhile are programming certifications? If your code posted on GitHub demonstrates a particular skill, is that generally evidence enough for a potential employer?
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’ll answer assuming the goal is getting a job. 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. Practice, practice, practice. 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.
What soft skills does a software engineer need to master?
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.
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. So if I had to pick one, it would be written. 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.
How worthwhile are bootcamps?
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. Let me give an example. 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 have a friend who actually went through bootcamp and ended up doing a good number of web apps. So some people can definitely get it. 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.
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.
What’s the best way to stay on top of the changes going on in software engineering, either as a newcomer or a veteran?
Ionescu: A really good resource in general is reading blogs that explain how things work at scale. A lot of [major tech] companies write blog posts, and, particularly for senior engineers, looking into the newest ways people have figured out distributed architecture helps open your mind to how to design something at scale. Uber posts them, Facebook, Google — a lot of these companies. They’re a really good resource for systems architecture.
In terms of learning these skills, it really depends. If it’s front end, there’s nice new blogs around on how to do specific things with React, new JavaScript things like Flux or Redux. If you’re looking for infrastructure, there are blogs around elastic search. If you’re trying to learn a programming language, there’s a lot of resources for that, there’s Unity Courses, there’s books. There are a lot of ways to stay in touch with what’s going on.
Heinritz: Different people learn in different ways. I can share my own experience. I learn best from building things, so I try to make time for side projects both inside and outside the office. A side project for me starts with a vague idea of the end goal: “I think it would be cool if our Ruby code was auto-formatted like our JavaScript code.” Or, “I want to hang a backlit map of a city with a nice warm glow on that wall over there.” As I start making progress, the goal becomes more clear and my motivation to achieve it grows. Learning happens naturally as I overcome obstacles along the way.
At work, I dedicate some time to projects that are interesting to me even if they’re not related to my main job function. Last year I got into a fun feedback loop formatting our Ruby code letter, and it ended up leading to open source contributions and the blog post Approximating “Prettier for Ruby” with RuboCop.
Outside of work, every so often I work on personal side projects. There’s a balance here; enjoying life is important. Working all the time isn’t healthy or sustainable. But I always have one or two ideas kicking around in my head. Right now I’m working on Map Lamps with my brother and have learned a ton about OpenStreetMap, Mapbox, the latest cloud and map-rendering tech. Personal side projects have the advantage of being greenfield, and it’s nice to use the latest tech out of the box.
How do you define the difference between a software engineer and a software developer or programmer?
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.
Salaries for software engineering can be very competitive. How do you make sure you’re getting paid your value?
Ionescu: If you ask a hundred people in the Bay Area if they’re being paid appropriately, 90 of them would say, no, I’m underpaid. I don't think I'm underpaid. I think it’s a psychological thing, right? It’s a matter of whether you feel like you get recognition and feel like you’re given opportunity. I don’t really have a strategy for it. But I’ve been working for four or five years and have never had an issue with reaching a plateau.
I’m assuming based on charts that I see shared by people across the industry — [assuming] those [are] good data points — and referencing those, I can tell that my compensation is pretty good relative to the market. Correlating that with how much I feel I contribute to the company, I think that’s a pretty good way to look at it. Now, it’s always an industry thing. For example, in finance, if you make a billion dollars for the company, you might get a $10 million bonus, right? Which doesn’t happen in tech. So in that sense, a lot of people might feel like, oh, I do so much for his company, but I don't get compensated enough.
But the way I think about it is, if you can find the work that you’re really good at, the compensation will follow. And I feel like that’s happened for me across my career, which is still pretty short.
Heinritz: I highly recommend Patrick McKenzie’s post Salary Negotiation: Make More Money, Be More Valued. There are few things I dislike more than these kinds of conversations, and I suspect many programmers feel similarly. Patrick’s post is the best advice I’ve read.
What question(s) would you ask a prospective employer in an interview?
Ionescu: I’m generally very entrepreneurial; it runs in the family. 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.
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, 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.
With the rise of website- and app-building templates and machine learning, is software engineering going to shrink?
Ionescu: I personally love [template tools]. If you’re trying to build a product that, for example, sells cars, and the main piece of your product is trying to figure out how to determine the price, then you don’t really want to focus on anything else. So everything else [can] be templated. While these things are almost never used long term, they almost always make it easier for you to focus on what you actually should focus on. Like, if I try to build something that has a very complicated component that’s solving one particular problem, but the rest is just boilerplate, I should never have to write the boilerplate.
So I don’t think they’re impacting the software engineering roles as much. I think we’ll always need really good software engineers to create long-term solutions.
Heinritz: I did worry about this sort of thing early in my career, through the lens of, “I’m so insanely lucky. Something must be wrong.” I now subscribe to the “software will eat the world” mindset. We’re just getting started.
