“You want to leave Amazon???” my wife asked, shocked, “but you love Amazon!” Yes, yes I did. I had come to Amazon 11 years ago, and I had grown up with the company, watching it go from 3k developers to 50k developers (and its stock from $40 to $3500!). I was productive. I was happy. This was home. Yet after much soul searching, I was about to leave everything and jump into the unknown. During a world-wide pandemic that was shutting down the world. Was I crazy? And as a Principal Engineer, which brings its own set of complications.

There’s lots of “Cracking the FAANG interview!” blogs so I am not going to be duplicating those. Instead, I wanted to focus my story on the parts that were unique about doing this at my level. Job searching as a Senior Staff or Principal Engineer is a somewhat different experience from doing it as a more junior engineer.

The short version of why I decided to leave Amazon is that it was a great place to supercharge my career and work with extremely driven and smart engineers, but after 11 years, I wanted to defy my own inertia and complacency. I wanted to put myself in an entirely different culture, with entirely different tooling and development practices. And, sure, let’s not be coy about this, there was a compensation aspect too. Companies are most motivated to compensate you well in your initial handshake (particularly if there’s competing offers), but the longer you stay, the more your comp will stray from the market (unless you are getting promoted regularly).

I had not interviewed externally in a decade, so I figured if I’m going to do it, I’m going all out. I spent 300 hours practicing coding and systems design questions (3 hours every night for three months). I then passed phone screens and lined up interviews at Google, Facebook, Microsoft, Uber, Apple, Twitter, and Salesforce. I wanted to really understand the world outside my Amazon bubble, gather data, and make an informed, fact-driven choice for my career. It was an exhausting but rewarding journey of self-discovery and introspection and pushing myself to the limit.

First, some context setting: what is a Staff or Principal Engineer?In tech companies, you can grow as an Individual Contributor (“IC”) or you can grow as a Manager.

For ICs, companies like Microsoft, Amazon, Google, and I’m sure others as well, follow a pretty similar distribution of levels. You’ve got about a third of the population in the entry-level engineer bucket (Amazon SDE-I, Google SWE-L3, Microsoft 59-60). These are generally engineers in the first few years of their career. The second bucket is the standard engineer (Amazon SDE-II, Google SWE-L4, Microsoft 61–62), and it’s about half the population. This is where most engineers spend a significant part of their career (I did as well), and write the most code. Then it starts getting thinner. Most teams will have one or two senior engineers leading technical decisionsso that’s about 10% of the population (Amazon SDE-III, Google SWE-L5, Microsoft 63–64).

The technical IC levels beyond that (Staff, Senior Staff, Principal, …) have a sparse population (5-9% of the engineers). Most are not expected to reach these levels in their careers. You’re the exception rather than the norm. You’re still coding, but you’re coding a lot less. You’re leading, but you’re generally leading leaders instead of leading individuals. You’re accomplishing things indirectly thru others, and you have to figure out how to influence without authority. Your timeframes are longer, you’re investing in things that will pay off years from now. You’re often glue between organizations, or glue between engineers and senior leaders, translating technical decisions to business decisions back and forth. You advice Directors and VPs and sit in their extended staff meetings. “Staff Engineer: Leadership beyond the management” is a great book about it.

From levels.fyi (red line is my best educated guess on where I am)

The very first thing I had to do in my job search is take a best educated guess as to what level I mapped to in other companies, and often educate my recruiter on this. Amazon Principal (L7) is a wide level. It can map to Google’s Staff or Senior Staff. It can map to Microsoft’s 66, 67 or 68. Facebook’s E6 or E7. Apple’s ITC5 or ITC6. Tricky eh? I had been a Principal for more than five years, so I felt pretty comfortable in my skin. And I was pursuing L8 (not in a particular hurry, but I had given it a fair bit of thought and often chatted about it with my manager). So I estimated I was in the upper band of Amazon Principal. I did a fair bit of research on levels.fyi, and chatted with friends I had in all these companies to validate it. Ultimately, the offers I received corroborated where I was with real-world data points.

Being in the statistical top 5% of the engineering population at a big company like Google, Amazon or Microsoft is a mixed blessing when it comes to job search. Your job market is extremely narrow (unless you want to pivot, such as go to a startup or unicorn or try something entirely different).

Earlier in my career, I was fungible with any other engineer. But L7 engineers aren’t necessarily interchangeable. We’ve often reached the level we have by specializing and becoming experts in one domain, which means we bring disproportionate value to employers that need or want expertise and high judgement in that specific domain.

Say you have a Porsche and a 4x4 SUV. If you need to drive on the snow, you should use out your 4x4. Can you use your Porsche? Sure, it’s an awesome car, it has 4 wheels and it moves forward, but it may not be the optimal car for the job. But when it’s sunny and warm and you’ve got a curvy country road ahead, then yeah, you want that Porsche top down instead of the SUV, right? (I’m not sure if I’m the Porsche or the SUV!)

In my case: I’ve spent 24 years focusing on engineering productivity in large software companies. I am good at identifying little bits of inefficiency in the software development experience that aggregate to millions of dollars of waste at scale, and bootstrapping ways to address it with tooling. But that also means that there’s plenty of other domains where I don’t bring a unique value. Only a few companies out there (FAANG, or FAANGMULA or FAANGULTAD, or whatever funky acronym we have these days…) have the need for very seasoned engineers to focus on optimizing the software developer toolchain their engineers use. Amazon, Microsoft, Google, etc, have customized proprietary developer tools to do just about everything, highly optimized for their internal ecosystem, so they were a natural home for me.

I had a fork in the road. At this point of my life, do I [1] double-down on my strengths, at the risk of painting myself in a corner by being extremely valuable but only to a small subset of companies, or [2] do I use this as an opportunity to become more fungible?If this was earlier in my career, I would say hands down #2. I chose #1: after 24 years in the industry, maximizing my income while doing something I loved and was good at was more important. This doesn’t mean I didn’t want to learn: you must constantly be learning and evolving in the software industry, whether you stay in a team/company/domain or move to a different one. But I didn’t want to reset my career. I encourage you to deliberately reconsider this fork in your road on a regular basis. #1 definitely comes with risks. I understood and accepted those risks.

Once I figured this out for myself after a lot of soul searching and introspection, I also had to teach my recruiters who I was, where I brought value and where I didn’t. No point wasting my time and their time on an ill-fitted role. Recruiters bounced me around until the right person knew what to do with me. A few of the companies created a custom role for me once I chatted with a hiring manager and explained my value. I knew my skills were needed, but finding the person in the company that needed them was a challenge.

Even with the possibility to work remotely, having an office in the Seattle metropolitan area was important for me. If this isn’t a large office, are you ok as a senior leader not being in the center of gravity? It is harder to influence at L7 when you’re not physically in the room and everybody else is. Ironically, the covid19 lockdown that was coming our way turned out to be an equalizer where every person was a similarly-sized square on Zoom, Google Meet, Microsoft Teams or Amazon Chime, but when I was interviewing in Jan/Feb of 2020, I was blissfully unaware of how much the entire world was going to change. I had always worked in the “mothership” both at Amazon and Microsoft, and witnessed the frustration of the smaller satellite offices that sometimes felt like a step-child. As a senior leader that becomes even more difficult. You may even be the only L7 in an office. On the plus side, it gives you a unique opportunity to be extremely influential in seeding the culture, and grow with the remote office.

It’s somewhat rare to have a L7 candidate. Amazon has entirely different executive recruiters, interview process and even specially trained interviewers for L7+ positions. Most companies have special lanes for L7+. In this aspect, Facebook won the red carpet award, hands down. Their executive recruiters were top notch in every way (and amazing human beings). They invited me to internal events. My wife and I went wine-tasting with their Seattle leadership. They showered me with cool swag. It was little details, but they certainly made an impression. I know objectively that the recruiting experience may be entirely different from the engineering experience, but subjectively, a little bit of pampering does influence you. My experience with Uber was also outstanding; I was sitting on a very attractive offer from them and they mailed me a thoughtful birthday present! The Google recruiters had programmed the TV in each conference room where I was interviewing to say something cute and positive about my day — it was a lovely gesture that made a big impact. On the other side of the spectrum, interviewing with Microsoft I felt a bit like cattle. I applied to five places within the company (may sound like a lot but it is a big place with >100k engineers). I had a solid resume, but some hiring managers didn’t even bother to respond for months (they did eventually, months after I was done!).

During my time at Amazon, I conducted over 800 interviews, most of them as a Bar Raiser (“BR”). A BR is a special interviewer that, among other things, makes the final hire/no-hire call. To be certified as a BR you go thru extensive training where experienced BRs shadow you and provide feedback on your interviewing style, time management and the data that you extract. Being a Bar Raiser is an absolute curse when you’re on the other side of the table. I often found myself in situations where my interviewer had wasted 5, 10 minutes on something that was providing a low-quality signal, or even flat-out asking me a pointless question that was not providing valuable data.

Top Bar Raiser Q1 2020 for AWS!

Entry-level interviews focus almost exclusively on coding. But interviews for L7s are different. All companies followed a similar blend: out of ~six interviews in a loop, 1–2 coding, 2 systems design, 1–2 leadership-focused. Some loops were over-indexed in coding and under-indexed in leadership, which is silly because L7 engineers code less and lead more (I wrote 100k lines of Java as L6, but probably a fraction of that as L7). Facebook’s loop had one interesting additional interview, where I had to describe one of my personal technical designs, and my interviewer did a deep dive and asked me lots of questions about it. I enjoyed this as it ended up being just a fun and natural back-and-forth discussion between two engineers and a whiteboard. Apple’s loop was a bit incongruous: half the people, the ones in Seattle, were ex-amzn and focused on “tell-me-about-a-time-you-did-x” (behavioral); the other half, the Cupertino folks, had weird theoretical “what-would-you-do-if-x-happened” questions (situational). These are banned at Amazon. I can learn so much more about you by diving deep into something you actually did, and I can ask enough probing questions to ensure you’re not making up your answer.

I assumed I wouldn’t do particularly well my first batch of real-world interviews because of rustiness, and I would improve gradually as I became more comfortable and confident. So being a nerdy engineer, I optimized the solution: I sorted the loops by order of “how sad I would be if I didn’t get an offer there.” What I learned though was that humans are unpredictable. There were some loops where I did great and some loops where I did not. Even within a loop, in some specific interviews I did great and in some I did not. It wasn’t the questions. Sometimes it was chemistry with the interviewer. Sometimes it was the energy in the room where I was interviewing. Sometimes it was just the migraine I had that day. Sometimes it was the strength of my morning coffee or how much sleep I had gotten the night before. There’s an element of human randomness in interviews. If you interview somewhere, and you don’t get the job, that doesn’t mean you don’t have the chops to work there! Just try again.

All in all, the Great Interviewing Spree of 2020 was one of the best things I ever did for myself. Between talking to recruiters, introspecting on who I was and how to tell my stories, prepping for technical interviews, and time spent on actual loops, I probably dedicated more than 400 hours of my life. I wanted to learn more about the world outside my bubble, learn more about myself and prove to myself I could rise up to challenges, and boy did I do that. You’ll learn more about yourself by putting yourself out there than you ever thought possible. And whatever you do, don’t let inertia and complacency keep you from pushing yourself a little bit every day.

I ended up taking a Senior Staff position at Google, where I’ve happily been since June 2020. I love lots of things about Google and miss lots of things about Amazon. But that’s a different blog! :)