I've never properly introduced myself and told you all my story.
In the next two issues will give you view into how I got to where I am today. Please enjoy!
From Liberal Arts Major To Amazon Principal Engineer
I was a Principal Engineer (L7) at Amazon before I quit in March of 2024. The last team I was on was the Prime Video Sports organization, which was a critical part of a streaming business that serviced hundreds of millions of customers worldwide with low-latency, high-quality live events. I was the most senior engineer for well over 400 people, the vast majority of which were software developers, located in half a dozen countries spread over three continents. I’ve launched several lines of business for Amazon, conducted over 850 technical interviews, and I have been awarded 13 software patents.
You might think that I have a Computer Science degree from a prestigious school, but I don’t. In fact, I have an English degree from the University of Washington (Go Huskies!). If you’re wondering how I achieved all that given my background, you’re in the right place.
After reflecting on my journey, the lesson that you can take with you is that it makes sense to go all-out and put more hours in when the time is right. Doing so all of the time will lead to burnout. Never putting in extra effort will delay your career progression. Hopefully, you can learn from my experience how to better identify when these opportunities arise in your own career so you can be selective when the time is right for you.
I will share my journey going from a new graduate → contractor → support engineer → software development engineer (SDE1, SDE2, and SDE3) and eventual principal engineer. I’ll focus on the bits that were critical to get to the next level and not as much time on exactly what I was working on, or specific technologies that I leveraged. This journey can be divided into the following chapters:
- Liberal Arts Major to Amazon Support Engineer: Going from zero to one
- Support Engineer to Software Development Engineer: The big jump to writing software professionally
- Software Development Engineer II to Software Development Engineer III (senior): Taking on more responsibility and starting to be a technical leader
- Software Development Engineer III to Principal Engineer: The jump to leading a technical organization with hundreds of engineers
Liberal Arts Major to Amazon Support Engineer (2005-2007)
Near the end of my studies I remember asking my writing professor what sort of jobs I should be targeting after graduation. He put his hand on my shoulder, and said “Steve, you can’t apply to the job called writer. There is a job called waiter, though. You need to find a way to make some money to survive while you ply your craft.”
This sent me into a panic because I had no interest in waiting tables or working retail. After I calmed down, I applied a skill that has served me well over my career, which is to set an aggressive target and work backward from it. To identify a target I created a Venn diagram of what skills I had, what skills were in demand, and what paid well. After this exercise, I set my target on becoming a software developer at a big tech company.
I have been programming since the late eighties because both of my parents are electrical engineers and I’ve always had a computer in the house. I learned BASIC programming in early grade school, got my first C compiler when I was around 10 years old, and took the AP computer science tests my sophomore and junior years of high school, which were in Pascal and C++, respectively. I took a couple of computer science courses in college, and I minored in math and applied math.
I realized after I looked into it that I had the raw ingredients to pass a tech interview for an entry-level developer. I spent months preparing for interviews and sending my resume to every possible employer, but eventually understood that without any experience, interviews were unlikely. It was the classic chicken and egg problem. How do you get the experience to land a job without a job?
I was complaining about this to an old friend over beers when he told me that they were looking for support engineers at Amazon. This position usually required some amount of technical experience, but since he could vouch for me, he could at least land me an interview. I jumped on the opportunity, despite the fact that it wasn’t a true software developer role. Because I didn’t have a degree or experience they hired me as a temporary contractor, and if it worked out I could be hired full time. Support engineers were responsible for a lot of work adjacent to software engineers, such as builds, deployment, and operations, so I would get a lot of exposure.
I saw this as my big opportunity so I went all in, even though it wasn’t a software development engineer role. The wonderful thing about most companies is that there is a treasure trove of information that is publicly available internally. Instead of just doing the work that was assigned to me, which came in the form of managing and closing out trouble tickets, I spent extra cycles learning about the inner workings of production systems, how they break and how to drive towards fixing root causes.
I became an expert in metrics and monitoring, and learned how to insert important work into the software development lifecycle, even though I wasn’t allowed to do any coding other than basic scripts. Since I had access to the source code I could understand how the system worked and create backlog items to improve the software that removed the need for in-depth investigation, which increased the chances that the work would get picked up. This allowed me to easily describe my contributions to some big launches that Amazon had, such as the Kindle and Unbox Video, the precursor to Prime Video, as well as some big systems used by many millions of people everyday, like Search Inside the Book. Because I went all-in with this opportunity, instead of just doing the work that was assigned to me, I was converted to full-time permanent support engineer role in 2007.
Takeaways:
- Set aggressive targets and work backward from them. To identify targets, find the intersection between what you’re good at, where there’s high demand, and what pays well.
- Always leverage your existing network for opportunities. People can’t help if they don’t know what you’re looking for.
- Opportunities adjacent to your targets are useful and represent progress towards your goals.
Support Engineer to Software Development Engineer (2007-2008)
A little under a year after I was made a full-time employee I felt that I had outgrown my role as a support engineer. My share of oncall duties was increasing because as team members left, and nobody was backfilled to replace them. The combination of putting in extra effort and increased oncall shifts was starting to burn me out. This, coupled with my deferred goal of being a software engineer, drove me to get structured and disciplined about preparing for a role change.
Back then it was incredibly difficult to prepare for software engineering interviews because there were no high-quality resources on how to prepare for interviews. There were no books on the tech interviews, there were no YouTube videos, and there definitely wasn’t LeetCode.
So I decided that I would become a collector of coding interview questions. I scoured internal wikis, the internet, and asked everybody I knew for what they asked during interviews. I got every SDE I knew well to give me mock interviews. I insisted that they do the interviews in character so that I could get used to performing while feeling anxious and uncomfortable. Over time, I became very comfortable coding in front of a white board.
Once I felt ready, I contacted three teams internally to schedule interviews for SDE. I did this to add some redundancy, but also to give myself choices if I were to get multiple offers. Batching interviews meant that I could take a break from preparation after the batch was over, which was definitely needed because I was pushing myself hard doing my job while preparing. That amount of effort would be unsustainable over a prolonged amount of time. I got myself through it by telling myself that there was an end-date to all of this work. I circled the day after my last interviews and scheduled a long vacation afterwards. No matter what, I was going to be in Hawaii, having a tropical drink by the pool, whether I was offered a software engineering job or not. Having a specific end date helped me get through this difficult time.
My preparation paid off as I passed all three interviews. I reverse-interviewed each of the teams and made sure that I spoke with engineers from each team to get a sense of whether they enjoyed their work, what the work-life balance was like, how much time they spent coding and most importantly, how they got along with their manager. I dodged a bullet because the team I was initially planning on joining had a terrible oncall load, and hadn’t delivered any new code in over a year. Another team had a manager that I didn’t click with, so I joined the Payments organization, on a team that was developing a new product, so I was guaranteed to be writing a lot of code. I finally realized my goal of becoming a software development engineer!
Takeaways:
- It pays off to be structured and disciplined in your preparation for interviews, especially if you are working.
- Batch interviews if you can to create redundancy and to give you a natural break-point after the batch is over. Imagine if I only targeted one interview, I would have either not received an offer and prolonged the grueling process, or been forced to accept an offer in a vacuum.
- Interviewing is a two-way street. Make sure to interview prospective team members as well as your new manager to ensure there is a good team fit before you accept an offer. Look for managers with long-tenures on their current team, and happy team members that have nice things to say about their manager.
Stay tuned for next week for Part II.