Note: I’m not representing Amazon in any way with this post. It’s just my personal experience and opinion.
I’ve blogged about being a self-taught engineer before and also about some of the accompanying struggles I’ve had trying to fit the mold expected to land a job in tech, especially at so-called FAANG companies. About a year after making that post I found myself applying, yet again, to a few big tech companies and eventually landed a job at Amazon. I am now a Sr. Front-End Engineer on the Seller Listings team. Here’s my story, maybe it will help you as well.
Finding the Perfect Role (ha!)
Shortly before I left PayPal I became very big on promoting the JAMStack internally and externally. I started my job search by searching for jobs with JAMstack in the description. For a lot of companies, the best way to find out where they’re hiring is their own job pages and the only big tech company I found hiring for someone with that experience was Amazon. They had a role titled “Software Development Engineer — Harmony” which wanted someone with 8 years of node.js experience who wanted to build out a JAMStack implementation inside of Amazon. It was a perfect match to my experience and background, so I applied. Incredibly, a recruiter got back to me in just a few days. I’m guessing it’s because I was such a good match on paper. Little did I know, I was not prepared at all for the interview process that was about to occur.
Most large tech companies these days have “front-end” positions and “back-end” positions. In my experience at least at the FAANG companies the back-end roles are generally Java based and the interview for these roles is more likely to be heavy into algorithms and leet-code type exercises, whereas the front-end roles are more commonly using something like React and the interviews are more practical. So I found this perfect job description, but I hadn’t understood the consequence of the job title, “Software Development Engineer” (SDE). I was on the wrong track and I was about to find out.
For the entire month prior to the interview I’d been spending 1–2 hours a day on leetcode, in their paid-subscription-only Amazon Interview Questions section. I was trying to get comfortable with answering annoying questions in a short period of time. I don’t know that I’d ever spent so much effort prepping for an interview before that, but I really wanted this job.
The first step for an SDE interview at Amazon is the choice between a phone screen or an online assessment. The online assessment is nearly identical to the leetcode exercises I had been busting my way through, so I chose that. With all of these questions there’s sort of getting it done, and doing it in an optimized way. For my interview I think I had an hour to solve 2 questions. I completed both of them, but only had time to optimize one of them. It was something really stupid like binary trees or whatever, but I turned it in and it was fine. The recruiter was impressed actually with how quickly I finished it. I know now that no one really looks at that stuff too hard later as long as you’ve solved the problem.
My on-site interview was a whirlwind affair. None of the interviewers wanted to talk about JAMStack or had anything to do with the position I had applied for. I couldn’t sell them on my perfect-ness for the position, because they weren’t necessarily familiar with the position at all. One of them, looking at my resume mentioned that I might be a better fit for a front-end role. I laughed, nervously, wasn’t that was this was? (Narrator voice: it was not).
One thing that’s not super well known outside of Amazon is their commitment to a set of leadership principles. Unlike most of other tech companies, these leadership principles account for a large part of interview in terms of both time and their weight. These are questions like “Tell me about a time you disagreed with a colleague about technical decision.“ Luckily, I had prepped a long list of examples from my career I was ready to talk about them at length. This was a life saver. Obviously, having done a lot of public speaking and blogging meant I also had stories already queued up in my mind to talk about if needed.
There were 4 interviews total, and I think the idea was that 1 was focused on system design, another on algorithms and data structures, and then two interviews were more generally about coding. I think I did fine on the coding side, but more or less bombed the other two. Again, even after months of preparation and practice, I still didn’t have the muscle memory needed to traverse a binary tree on a white board. It was a grueling day and I hadn’t really known know what to expect. I left feeling … ok 🤷.
A few days later the recruiter called to let me know they really liked my leadership principles, but not so much my tech skills, but they would like me to re-interview, this time as a front-end engineer. Apparently, one of my interviewers mentioned to her boss that I had worked a lot with React in the past, so I was given the chance to interview for a role on her team or another front-end role. Honestly, I wasn’t even mad. It was frustrating to be asked to interview again, but I was grateful that my experience was taken into account enough to afford me a second chance, and I took it.
Interview Loop #2
Somehow I knew right from the beginning when they asked me to code up a button and add some event delegation and a few other things that I was going to be just fine this time around. For the system design question I went into detail about how I might build a newspaper website using the JAMStack. For the algorithms and data-structures question I had to solve a word search by traversing through the DOM and checking to see if that word appeared. It was fun and not too stressful! A complete 180 from the serious “software engineering” interview I had previously completed and mostly failed. I left feeling confident that I was getting the job. And I did.
I didn’t really know what to expect. I had applied for a completely different job than the one I got, but it’s been great. I love the team culture. When I started I was the only front-end engineer on our team and so I’ve done everything I can to ensure I’m giving solid advice and making good choices when it comes to our code base. I’ve attended a ReactJSTraining workshop and took the EpicReact course (which completely blew my mind) and spent a lot of time pouring over the Redux Style Guide to glean its secrets. All of that has given me the tools to give useful feedback and help shape our codebase for the better. It’s been a good year and I’m looking forward to a couple more.