How I Got Hired at Amazon
Tags: hiring, career, webdev, programming
Published: 2022-03-21 08:38:32

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...
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gf8cxgr5ukc9zmsfiwu3.jpg)
## 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.
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vd6azf6cc3x25wgpcdd3.jpg)
## 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.
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k5lak04oyvtt9gso46ma.jpg)
## 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.

1. 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.
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yi0onolfpwc52yqgyfii.jpg)
## 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.
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e8t27xw4ycib8cjiflcz.jpg)
## 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.
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y6k8gh3sh5ryhvxj3zdw.jpg)
## 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
1. 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
1. A backend (Node/API) engineer
1. A senior frontend engineer
1. The dev manager for the team doing the hiring
1. A BA/PM-type
1. 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.
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ktg0a3bxb7wvvinc47sx.jpg)
## 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.
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hiqkuaxfncg3qrppb886.png)
## 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()`.
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1vbm23t8xj45abmspe6z.jpg)
## 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! 😆