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 gettingrejected 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 toyour 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 thatI learned in the process. Your mileage may vary...

Lesson #1: Big Tech Companies Are Not Monoliths

What do I mean by this?? Well... just becauseone job opening at the megacorp doesn't work out for you doesn't necessarily mean there aren'tmany 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 amillion employees onhundreds of teams. So just becausethis opportunity is for onsite-only work (or, anyother restrictive condition...) doesn't mean thatall 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 mycurrent 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 simplydid 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 thiscurrent 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 completelybomb your interview process, you can always apply again at some point in the future. (FWIW, Ibelieve 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 bythe next Amazon hiring manager,the next time that you apply. But re-applying to amassive 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 youlast year are still in-placethis year. But companies like Amazon are so frigginmassive that a completely different teamnext year may love you, even if the team you interviewed withthis year found you to be unqualified.

Lesson #2: Take Notes

Amazon's interview process isloooooong. And that may sound rather daunting. But there's a silver lining toall those interviews. Specifically, you may find that something told to you in anearlier interview will help you do better in alater 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 upall 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 spentweeks 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 YouDon't Know

How did I disguise this faux pas on my part?? I didn't. I just told her, straight-up, that Idid 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 beforethis 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 uptalking 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, Icompleted the task. But if I'm being honest, I was thrown for alittle bit of a loop as I first thought about how to code the solution because, for the last 6+ years, I've been writingsoooooo 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 actuallyknow that I couldn't have coded my solutionsin 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'trunning 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 wasone aspect of their tool that threw me for a bit of a loop: You can'trun your JavaScript in their online interviewing/coding portal. Here's why that was a small "problem" for me:

JustRun 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 veryclose, 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 thathe was right. It was clear to me that I had to makesome 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 throughthousands of lines of code, it's typically impractical to expect anyone to run the code entirelyin their mind. Granted, I can often spot problems simply byreading code (my code, or anyone else's), but when I'm pretty certain that a problem exists, I pull the code upon my localhost, and then I proceed to play with it until the problem's fixed.

Run The Code Wherever You Can

Typically, this takesvery little time. Once I canrun the problematic code, I can usually narrow the problem down quite efficiently. That's because, rather than just trying tostare at the code andthink about why it's not correct, I simplyrun the code. When I'mrunning the code, I just start dropping breakpoints, orconsole.log()'s, into the code. And then, once I'mrunning 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 simplycopied-n-pasted the problematic code into another window (where I couldrun it), inspected a few of the variables, made any necessary tweaks, and thencopied-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 besaved. In other words, all of theother interviewers will be able to see anything that you coded while talking tothis interviewer. Presumably, they will takeall 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 tore-code stuff that I've long-ago "solved" in my other apps. I did this because I justassumed that I had totype 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 Iusually 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 theother 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 werenumerous coding tasks for which I could've provided a moreholistic 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-pastingduring 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 along interview process. And they'll probably schedule it at their leisure.

All-told, I hadseven(!!!) 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 remainingfive 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'lldefinitely 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 totalk through your solutions. They didn't require that I do this. But I know from a ton of experience (both inhiring and inapplying) 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 codein your mind.

Use YourWords 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 yousay can be just as vital to demonstrating your knowledge as what youtype.

Talking through your solutions can have an additional benefit as well. When youtalk through the problem, and perhaps eventalk through the code that you're writing onscreen, you may be surprised at just how much the interviewer activelynudges 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 youtalk through the solution, the interviewer can (hopefully) recognize that you pretty muchknow how to solve the problem, and any continuing delay is just caused by you futzing over anexact 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 theexact lines of code that are required to complete the exercise.

I was also surprised at just how much of each interview was occupied merely bytalking. 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 totalk through many technical concepts, you definitely shouldn't get dragged intoarguing about any of them. (And obviously, that little bit of sage wisdom probably applies toany interview, withany 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 wasabsolutely 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 thoseexact 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: NoGotcha! Questions

OK, maybe this isn't a "lesson" that applies to all Big Tech interviews. It may not even apply to allAmazon 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 aGotcha! question.

Google's famous for their "thought experiment" questions. I was already given a heads-up about some of theGotcha! 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 abasic 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 evensenior 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 talkedvery 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 ofArray.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 basicallyself-eliminated myself several times in the last few years. To be perfectly frank, the process felt onerous and I really didn'twant to go through it. But now that I'vebeen 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 thatyour experience will, in any way, mirrormine. There are interviewers out there - at nearly every company - who will try to sabotage you with litmus tests andGotcha! questions. Every large company has at leastsome Grade-A buttholes who think it's clever to ask you about arcane quirks in a given programming language. Maybe Amazonis 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 fitfor 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! 😆