How I Got Hired at Amazon

So I got hired at Amazon...

I wanted to write this post because 1) my previous posts may have given the impression that I have some kinda axe to grind with Big Tech, and 2) I know that many people genuinely wonder, "How do I get into one of those big companies?". So this is my story. (By the way, if you wanna hear about my previous experience getting rejected by Facebook, you can read about that here: https://dev.to/bytebodger/rejected-by-facebook-1o3j)

Buyer Beware

First, I wanna make it clear that this is not a "How To" article. I didn't write this to simply list out, "Here's what I was asked and here are the correct answers." My process may not map to your process when/if you apply. But I did learn a few things that may be helpful to you if you're trying to get onboard with a FAANG company.

Second, this article is not some kinda "humble brag". You're not a "better" dev because you work for Big Tech. Some of the best devs I've ever met have never worked for a FAANG company. That being said, Big Tech typically pays Big Money. And even if money were no issue, a lotta devs would love to have that chit on their resume that says they worked for a FAANG company. So I'm just gonna share the lessons that I learned in the process. Your mileage may vary...

Lesson #1: Big Tech Companies Are Not Monoliths

What do I mean by this?? Well... just because one job opening at the megacorp doesn't work out for you doesn't necessarily mean there aren't many more-suitable openings for you at the exact same company.

I've been pinged by Amazon recruiters, on-and-off, for the last coupla years. During a few of those interactions, it was clear that the potential role was either onsite at an Amazon location, or would only be remote until COVID blew over. For all of those "opportunities", I politely declined.

Many Different Opportunities

But a company like Amazon has more than a million employees on hundreds of teams. So just because this opportunity is for onsite-only work (or, any other restrictive condition...) doesn't mean that all of their opportunities have the same restrictions.

Also, the hiring process is not identical for every role or every team. Sure, an established company like Amazon will have certain "HR guidelines" that they probably need to follow for every interview, but that doesn't mean that the process required to be hired as a database engineer for a team based out of Seattle will be identical to the process required to be hired as a frontend dev for a team based out of Phoenix.

Assessments

Specifically, during my first several interactions with Amazon recruiters, I was sent instructions to first complete an online assessment. And while I'm not necessarily opposed to the idea of doing an online assessment, I've written extensively about what is (as I perceive it to be) the myriad of BS hurdles that are presented by these assessments. (In fact, the very first article I ever wrote for Dev.to was about the folly of coding tests. You can read it here: https://dev.to/bytebodger/your-coding-tests-are-probably-eliminating-some-of-your-best-candidates-de7)

During previous interactions, I was simply too bogged down with my current job to consider taking these assessments. I went to the assessment site and even took some of the sample tests. But I quickly realized that they were gonna ask me about a ton of... esoteric concepts that I simply couldn't be bothered to study up on before I took the tests. So I simply did not take the tests - and I allowed those "opportunities" to fall by the wayside.

This go-around was a little different, from my perspective. First, I was basically "between gigs", so I was more open to idea that I might have to trudge through their assessements. But second, I also found (much to my delight), that this current opportunity did not require me to do an upfront, online assessment at all.

If At First You Don't Succeed...

You should also keep in mind that, even if you completely bomb your interview process, you can always apply again at some point in the future. (FWIW, I believe the policy at Amazon allows you to re-apply every six months.) Granted, I'm sure that your past results will still be recorded somewhere in their system. And you probably don't want to apply willy-nilly if your skills aren't up to snuff, because you won't want those abject failures to be sitting in your "permanent record", to be perused by the next Amazon hiring manager, the next time that you apply. But re-applying to a massive company like Amazon is not the same as re-applying to some small dev shop in your local town.

Once you've been eliminated by a small, local company, there's a reasonable argument to be made that maybe you needn't bother applying to them again anytime soon - especially if the hiring managers who rejected you last year are still in-place this year. But companies like Amazon are so friggin massive that a completely different team next year may love you, even if the team you interviewed with this year found you to be unqualified.

Lesson #2: Take Notes

Amazon's interview process is loooooong. And that may sound rather daunting. But there's a silver lining to all those interviews. Specifically, you may find that something told to you in an earlier interview will help you do better in a later interview.

Pay Attention

For example, I was told in only my second interview that, in a later interview, they'd probably ask me about the "Amazon Leadership Principles" and that I should be prepared to answer such a question. So what did I do?? I acted like a complete idiot.

You see, it took them quite a while (3+ weeks) to set up all the interviews. Initially, I read through Amazon's "Leadership Principles" and I was prepared to talk about them. But by the time they got my later interviews scheduled, I had spent weeks boning up on all sortsa technical details and I completely forgot to re-acquaint myself with the "Leadership Principles".

So in one of my last interviews, the interviewer asked me, "Which of Amazon's Leadership Principles is most important to you, and why?" Of course, as soon as she dropped this question on me, I thought, "Awww... crap."

Be Honest About What You Don't Know

How did I disguise this faux pas on my part?? I didn't. I just told her, straight-up, that I did read the principles several weeks earlier, and I even had an answer to that question a while ago, but that I'd forgotten to re-read them before this interview, did not have them in front of me, and could not recall them from memory.

Was this the smoothest course of action? Probably not. But I'm sure my dead-honest answer was better than trying to make up something on-the-fly. And thankfully it didn't keep them from extending me an offer.

Lesson #3: Focus On Core JavaScript

Obviously, this lesson is most applicable to those applying for frontend (or... Node-centric) roles. On the surface, this probably sounds obvious. After all, whether you're a wizard with jQuery, Angular, React, Vue, Svelte, Node, or any other popular framework, it's all just... JavaScript. So if you claim to know these things, you'd hopefully be extremely comfortable with plain ol' JavaScript, right???

But here are the reasons why I list this as a core "lesson":

1. I was actually mildly surprised at how many of the coding tasks focused on nothing more than plain ol' JavaScript, even though I was being interviewed for a role that would presumably be anchored in React. I did end up talking about React concepts during some of my interviews. But every coding task given to me was to be written in plain ol' JavaScript.

2. This created a small "problem" for me when, in one of the interviews (as it turns out, this interview was with my future manager), I was asked to code up some basic DOM-manipulation features. To be clear, I completed the task. But if I'm being honest, I was thrown for a little bit of a loop as I first thought about how to code the solution because, for the last 6+ years, I've been writing soooooo much React-specific code that I had to stop and think for a minute about the best way to solve the problem without using those same React-specific features (or features of any other common framework, for that matter).

One additional note here: I don't actually know that I couldn't have coded my solutions in React. Granted, the coding window presented to me was labeled as being simply "JavaScript". And the default expectation from the interviewers was certainly that I'd be writing solutions in plain ol' JavaScript. But we weren't running the code in their platform anyway (more about that in the next lesson...) And many of my interviewers were very familiar with React. So, in hindsight, I'm not actually certain whether it would've been a problem if I'd simply started cranking out code in React.

Lesson #4: Keep A Local Terminal (Or Browser) Open During Interviews

When you interview with Amazon, they will invite you to do coding solutions in their own, shared, in-house tool. This tool is not unlike many of the other online portals you've seen where you can write some test JavaScript in a browser window (e.g., StackBlitz or JSFiddle or CodeSandbox).

However, there was one aspect of their tool that threw me for a bit of a loop: You can't run your JavaScript in their online interviewing/coding portal. Here's why that was a small "problem" for me:

Just Run The Code

At one point, one of the interviewers asked me to code up a JavaScript function that would recursively build an object based on a period-delimited string. I proceeded to write my solution, even talking through each aspect as I typed it out. When I was finished, the interviewer pointed out to me that my solution was very close, but that it had a small flaw in it.

Here's the funny part: As soon as he pointed out my mistake, I could immediately see that he was right. It was clear to me that I had to make some kinda change to finish the task. But I was having a bit of a problem simply thinking, in my mind, about how I needed to tweak the code to solve the problem.

This stalled me for a minute because, in my previous jobs, while pouring through thousands of lines of code, it's typically impractical to expect anyone to run the code entirely in their mind. Granted, I can often spot problems simply by reading code (my code, or anyone else's), but when I'm pretty certain that a problem exists, I pull the code up on my localhost, and then I proceed to play with it until the problem's fixed.

Run The Code Wherever You Can

Typically, this takes very little time. Once I can run the problematic code, I can usually narrow the problem down quite efficiently. That's because, rather than just trying to stare at the code and think about why it's not correct, I simply run the code. When I'm running the code, I just start dropping breakpoints, or console.log()'s, into the code. And then, once I'm running the problematic code (and inspecting the variables in real-time), it's usually dead-obvious what needs to be tweaked to make it meet the spec.

In retrospect, it didn't have to be this way. To be clear, they never even hinted that I couldn't have other windows open during the interview process. In fact, in several of the interviews, I announced to them that I was simply gonna grab some of my pre-existing code to illustrate a given concept. And they never complained about this at all. So I now realize that there probably wouldn't have been any problem if I'd simply copied-n-pasted the problematic code into another window (where I could run it), inspected a few of the variables, made any necessary tweaks, and then copied-n-pasted the improved solution back into Amazon's code-sharing tool.

Lesson #5: Don't Be Afraid To Paste Anything "Important" Into Their Coding Tool

First, understand that anything you write in Amazon's coding/interviewing tool will be saved. In other words, all of the other interviewers will be able to see anything that you coded while talking to this interviewer. Presumably, they will take all of that into account as they make their recommendations.

This wasn't entirely clear to me until one of my last interviews. We were going through concepts of API/asynchronous calls and I spent copious amounts of time basically trying to re-code stuff that I've long-ago "solved" in my other apps. I did this because I just assumed that I had to type everything in the Amazon coding window, from scratch.

Put "Supporting Evidence" In The Coding Window

I completed the task, and my solution "worked", but it was definitely much more "bare" than anything I'd typically put in production. So I told the interviewer, "This is how I usually address this task." Then I proceeded to copy-n-paste my "standard" solution out of one of my GitHub repos and into the coding window.

When I did this, the interviewer made a point of adding comments, directly above my copied-n-pasted code, basically indicating to any of the other interviewers that this was my "more complete" solution, pasted from another of my apps, and that they should take the time to review it.

Quite frankly, there were numerous coding tasks for which I could've provided a more holistic solution, if I hadn't already burdened myself with the preconceived notion that I had to type out everything, from scratch, in their custom portal, as they watched. So if you already have some solid code that illustrates the concept they're asking you to write, don't be shy about doing some quick copying-n-pasting during the interview.

Lesson #6: Be Prepared To Spend A Lotta Time In The Process

This probably goes without saying, but Big Tech companies can afford to conduct a long interview process. And they'll probably schedule it at their leisure.

All-told, I had seven(!!!) interviews with Amazon. The first was the cursory screening call with their internal recruiter. The second was a technical call, but it was basically a screen to ensure that I was worthy of the "full" process. Once I passed the technical screening, they then proceeded to schedule the remaining five interviews.

They will try to schedule all five of those final interviews in the same day. But due to scheduling conflicts with the evaluators, my last five interviews ended up taking place over the course of two days. It also took them nearly three weeks to get all of those last-five interviews lined-up and confirmed.

Overall, my interviewers were in the following roles:

1. The internal Amazon recruiter
2. A technical screener who was pretty senior (and knowledgeable) in his own right, but doesn't really get a chance to "touch" the code much anymore
3. A backend (Node/API) engineer
4. A senior frontend engineer
5. The dev manager for the team doing the hiring
6. A BA/PM-type
7. A senior architect

I was expected to code during interviews #2, #3, #4, #5, and #7. After the initial recruiter screening, every other interview was scheduled for exactly one hour. And to their credit, they were very fastidious about keeping to that time constraint.

Lesson #7: Talk. And Code. But Don't Argue.

I was asked to do live coding in five of the seven interviews. So if you have any problems cranking out some code while someone's looking (virtually) over your shoulder, you'll definitely need to get over that. Quite frankly, I'm certain there's just no way around this. You're gonna have to code in a real-time environment, and you're gonna have to do it while an interviewer is watching you.

My best suggestion here is to talk through your solutions. They didn't require that I do this. But I know from a ton of experience (both in hiring and in applying) that even minor coding challenges can start to eat away at your psyche if you're just staring at the screen, in silence, as you try to formulate all of the code in your mind.

Use Your Words To Demonstrate Your Knowledge

For me at least, talking through the process not only helps me to organize my thoughts (and my code) as I'm completing the exercise, but it also illustrates to the interviewer that I'm not just mashing the keyboard in a desperate attempt to come up with a solution. In other words, what you say can be just as vital to demonstrating your knowledge as what you type.

Talking through your solutions can have an additional benefit as well. When you talk through the problem, and perhaps even talk through the code that you're writing onscreen, you may be surprised at just how much the interviewer actively nudges you along.

If you sit there in utter silence, slowly cranking out a few lines of code as you grasp for an answer, the interviewer will quickly get the feeling that you may be in over your head. But when you talk through the solution, the interviewer can (hopefully) recognize that you pretty much know how to solve the problem, and any continuing delay is just caused by you futzing over an exact solution. And once the interviewer feels confident that you actually understand the problem and that you legitimately know how to code the solution, they can often be much more helpful in guiding you to the exact lines of code that are required to complete the exercise.

I was also surprised at just how much of each interview was occupied merely by talking. In each of the five coding interviews, every single interviewer used almost half of the time to merely ask me coding questions. In fact, I think there was one where we didn't even open up the coding window until we had only 15 minutes left in the interview.

Discuss - But Don't Argue

My only caveat here is that, while you should be prepared to talk through many technical concepts, you definitely shouldn't get dragged into arguing about any of them. (And obviously, that little bit of sage wisdom probably applies to any interview, with any company.)

In my third technical interview, I was talking with a frontend engineer. And it became immediately apparent that he and I shared many coding "philosophies". Specifically, I alluded to fact that I'm not a big fan of TypeScript or Redux. He was chuckling and nodding along. As you can imagine, that interview went quite well.

In my last interview, I was talking with a senior architect. And he was absolutely a huge proponent of both TypeScript and Redux. Did that present any real problem for me?? No. In fact, we had a good discussion about both technologies and I believe I was very clear that I appreciate them both as "tools" that should essentially be used when they are the "right" tool for the job. Granted, I think he and I disagreed on what some of those exact purposes were, but I definitely don't believe that my contradictory opinions on TS/Redux were any impediment to my receiving an offer.

Lesson #8: No Gotcha! Questions

OK, maybe this isn't a "lesson" that applies to all Big Tech interviews. It may not even apply to all Amazon interviews. But when the whole process was finished, I was actually incredibly surprised to realize that I was never asked a single question that I would classify as a Gotcha! question.

Google's famous for their "thought experiment" questions. I was already given a heads-up about some of the Gotcha! questions I might be asked by Facebook. But through seven separate Amazon interviews, I was never asked a single question that I considered to be obtuse or esoteric.

Quite frankly, this shocked me.

In fact, I thought many of the questions/tasks were pretty... basic. To be clear, just because a question has a basic answer, doesn't mean that you can't use the opportunity to expound upon the response and demonstrate deeper knowledge. But I didn't get any of those kindsa questions that tend to piss off even senior devs. You know what I'm talking about. They blow the answer and then, after the interview, they hit up all their dev buddies and say, "Can you believe that they actually asked me about... [INSERT SELDOM-USED ESOTERIC CONCEPT HERE]???"

I was also surprised by how few of the conversations were bloated with talk of "academic" concepts. During my second interview - the tech screening - we talked very briefly about Big-O. But we never delved too deeply into it. And he didn't seem to care less that I couldn't recite, from memory, the Big-O complexity of a Shell Sort. No one asked me to code a binary tree search. No one expected me to have all the vagaries of Regex immediately available from memory. No one asked me for the default 5th parameter value of Array.prototype.reduceRight().

First Day At Amazon

I'm publishing this post on my first day of work at Amazon. (No, I won't be working on a fulfilment line. But I thought the above pic felt more like "Amazon employees" than just showing nerds like me sitting in front of a computer screen.)

Is it "easy" to get a coding job at Amazon (or any other Big Tech company)? No. I definitely don't think so. But if you re-read what I wrote under Lesson #1, you'll see that I basically self-eliminated myself several times in the last few years. To be perfectly frank, the process felt onerous and I really didn't want to go through it. But now that I've been through the process, it really doesn't feel anywhere-near as onerous as I'd imagined it to be.

Of course, I give you absolutely no guarantees that your experience will, in any way, mirror mine. There are interviewers out there - at nearly every company - who will try to sabotage you with litmus tests and Gotcha! questions. Every large company has at least some Grade-A buttholes who think it's clever to ask you about arcane quirks in a given programming language. Maybe Amazon is one of those companies, on the whole, and I just got lucky this time? Who knows???

In case it's not already obvious, I'm not claiming that a Big Tech job is the "right" path for anyone else out there. Working for a tech giant can have some... unique challenges, to be sure. Hell, I don't even know whether it will be a good fit for me. But I'm honestly pretty excited to explore this new Big Tech path for all it's worth. And if it all ends badly, I'll just turn it into new content here on Dev.to! 😆