What It's Like To Code For Amazon
Tags: career, webdev, javascript, programming
Published: 2022-07-12 05:47:00


I haven't blogged in four months.  I've been really busy because... I started working for Amazon.  (You can read about my hiring process here: https://dev.to/bytebodger/how-i-got-hired-at-amazon-3ajl)  While this post won't contain any of my usual _this-is-what-I-hate-about-programming_ rants, or any useful how-to tips-n-tricks, I've been thinking that some of you might be interested to know just what it's _like_ to work for a tech behemoth like Amazon.  I know _I_ always wondered - and now I can share some of the (occasionally jaw-dropping) things I've experienced in my short time here.

For the record, I'm a self-taught dev with a quarter-century of experience.  I've kinda "done it all" during my long career, but I'm mostly focused now on frontend dev - and that's what I was hired to do for Amazon.  Specifically, I work on a team building the tools used by our marketers to send _billions_ of messages (usually: _email_) to our millions of customers around the world.

It may also be useful to remember that I work entirely remotely.  My team is based in Seattle.  But even they are almost all working from home.  And there are no plans to force us back into the office.
<br/><br/>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/scdjrees1b67xidge81o.jpg)
## Disclaimers
First, let's get a few things out of the way:

I've only been here for four months.  _Of course_ I don't know **everything** there is to know about working for Amazon.  In my short tenure (so far), I've had the chance to work on and interact heavily with _two_ separate teams.  But obviously, there are _millions_ of Amazon employees and _hundreds_ of teams.  Even if we "only" narrowed it down to _just_ the programming teams, there are still _So Many Teams_.  So nothing I write here is the end-all/be-all of what it's like to work for Amazon.

I've also discovered that Amazon is no monolith.  This means that, while there are certainly _some_ aspects of our culture that probably apply to many/all teams, it's also inevitable that _some_ teams operate in a manner that's entirely different from mine.  So some of the things written here may have no bearing on you, if you're working (or will eventually be working) for Amazon.  This is true even if you're a frontend software engineer, just like me.

That being said, I've definitely started to realize that some of the things I've experienced are absolutely driven by Amazon's _culture_.  So I'd imagine that other devs would at least be able to nod along to _some_ of the things I'm outlining here.

I'll also state, right up front, that I've been pretty darn happy in the early goings of my Amazon career.  So none of this should be taken as a "rant" or as me "bitching" about anything at Amazon.  There are some things that I'd define as, umm... _suboptimal_.  But overall, I'd take this job again in a heartbeat.

So let's dive into those... "quirks".
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/phagkz2xj3xmxanddjv3.png)
## (Lonely?) Autonomy
When I interviewed, one of my last interviews was with a senior architect type.  He's not in my current group.  But he was definitely well-versed with what I could expect if I were to be hired.  So I asked him, quite simply, "What is it _like_ to work at Amazon??"

I ask this question a lot, because I'm usually not too concerned with any particular tech stack.  And I don't often care much about the nitty-gritty details of the health benefits.  Instead, I wanna know - preferably, from someone who's done my job (or been on a team similar to mine) - what the day-to-day worklife is really _like_.  

At the time, his answer really struck me.  And it's only continued to resonate in my head as I've become integrated into Amazon's processes.  He said, 
<br/><br/>

> "Well... you have a lot of _autonomy_.  A **_ton_** of autonomy.  Almost "too much" autonomy.  It's the kind of autonomy that can actually get some people _in trouble_."


<br/><br/>Now that I'm "in the fold", I know _exactly_ what he was talking about.  This is not a place that will babysit you or hold your hand.  This is not a place that will try to dictate your agenda.  Yes, we have sprints and tasks, and you're obviously responsible for delivering on those tasks.  But exactly how you go about accomplishing those tasks is almost completely up to you.  So much so that I don't think I've ever seen anything quite like it.

Now you may be thinking, "That's _great_!!!"  And to be sure, it _is_!  But it also requires you to be inherently self-driven.  It requires that you speak up - loudly, and frequently - if anything has you "stuck".  It requires that you learn - most likely, _by yourself_ - how to navigate the company's (incredibly, mindblowingly) massive databanks of internal documentation.

I've also noticed that this can leave me, at times, feeling like I'm on a bit of an island.  Not that this is necessarily _bad_, per se.  But if you thrive on constantly chatting with your coworkers about last night's Big Game, you may find yourself feeling a bit... _alone_.

Like so much of corporate America, we use Slack.  And of course, I'm tied into about a dozen Slack channels that are central to my team and/or my job function.  But I've gone entire days without seeing a single message posted to _any_ of those Slack channels.  Even when I post something there, it can sometimes be a bit of a wait before anyone responds.

To be fair, whenever I've reached out to anyone individually, I almost always receive a timely response.  I'm not claiming that I feel _ignored_ here - not at all.  But at times, it's almost jarring to see the dearth of mindless chatter that I've grown accustomed to with other companies.  (Of course, it's also incredibly _refreshing_ - but it can be jarring as well.)

Also, on many days, I have _one_ meeting.  (Our regular standup.)  I don't get blindly dragged into a dozen meetings - all having many dozens of near-useless attendees - just for the sake of saying that I was _there_.  I don't get "looped into" an endless stream of emails on which I have no meaningful/useful input.  My time is respected in a way that I'm, quite frankly, very unaccustomed to.
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h1h7wqj9jjlmwtt8j6z7.jpg)
## Dev-Driven Culture
I've worked for companies that were founded by devs.  I've worked for companies where the devs were treated as some kinda "necessary evil".  I've worked for companies that operated everywhere along that spectrum.  But I don't think I've ever worked someplace where nearly _all_ of our initiatives seemed to emanate almost _directly_ from... the devs.

To be sure, we have execs higher up our chain who don't code and they certainly drive/approve/oversee our initiatives.  But nearly every goal we've discussed has emanated - from us.  And I don't just mean that the _execs_ are leaving us alone.

My main team has more than 10 people on it.  They're _all_ devs.  We don't have an embedded business analyst - or any BA "group" through which we must coordinate our activities.  We don't have an embedded QA person - or any QA "group" through which we must validate our work.  We don't have a product owner who tends to our queue and prioritizes fixes/features.  We don't even have anyone who's a formal "project manager".  Our dev manager (who doesn't really code anymore - but he definitely knows how to code) is basically our "project manager".

Do other teams have such roles?  Probably.  But I haven't met them yet.

Think about that for a minute.  Our code drives a massively-important business function.  It's responsible for the delivery of _billions_ of outbound messages.  And yet we don't have a single person who's constantly looking over our shoulder or trying to tailor our agenda to broader company/customer objectives.

Our timelines are driven _by us_.  Our deliverables are defined _by us_.  It's amazingly _awesome_.  But it's also borderline-intimidating to think of the trust that's placed upon us.

They also give individual teams a tremendous degree of autonomy to pick their own toolsets.  Do you think that new app should be built in Svelte?  Well, if you can convince _your own team_ that it's the best choice, then you'll probably be building it in Svelte.  Do you hate (or love) Redux?  Well, as long as your peers have bought in, you can probably ditch (or adopt) Redux.  As far as I can tell, there are almost no overriding corporate "rules" stating that you must use (or forego) a given technology.
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z2cejeuhftqk9hzbdv5d.jpg)
## Owning The Business Objectives
While I _love_ this approach, I also have to say that this can sometimes be a double-edged sword.  What I mean is that, sometimes there's a certain security as a programmer in knowing that you're just the guy who "builds the tools".  Because if you just "build the tools", it really doesn't matter what other people _do_ with those tools - so long as your tools _work_.

For example:

We just finished this exercise in codifying our objectives for the coming quarter/year.  Some of those objectives are things that are decidedly... "outside" the bounds of programming.  Like, we're working on objectives to increase click-through rates, and to lower opt-out rates.

When I first read these, I thought, _"I don't actually craft any of our marketing campaigns.  How in the world can I control whether any particular campaign has a low click-through rate?  Or a high opt-out rate?"_ 

I mean, if a marketer uses our tools to develop a poorly-targeted, shoddily-worded, overly-ambitious email campaign that's misguidedly sent out to 500 million people, what can I possibly do about that???  I can't possibly be tasked with _approving_ their campaigns.  Or _editing_ them.  Or, in the most extreme example, _killing_ them.  So how can I be expected to drive metrics such as click-through or opt-out?

Of course, the reality is somewhere in the middle.  No, I'm not expected (nor am I even wanted) to start sticking my nose in the middle of some campaign that's being crafted by a marketing group in Berlin.  But I am _empowered_ to think proactively about how our tools are used - and trying to strategize about every possible thing we could do in the software that could increase the success of our (many) marketing teams.

That can be a little overwhelming at times.  But if I'm being totally honest, it's also pretty friggin cool.
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mxxs5yxzkihop03mqvei.jpg)
## The Endless Proliferation Of Custom Tools
If this is all sounding like a developer's wet dream, I do think there are some, umm... downsides.  For example, Amazon has a seemingly-endless supply of in-house, custom-built tools - tools that do all the same stuff you've already learned to do with "industry standard" tools.  Amazon doesn't just re-invent the wheel.  They create a dozen specialized variants, all of which feature an insane level of over-engineering.  And nearly every one of those wheels basically does the same thing you've come to expect from... any other wheel.

Are you really familiar with deployment tools like Jenkins?  Well that's too bad.  Because you won't be using any of them here.  You'll be using **Pipelines** and **Apollo**.  And you'll be using something called **Brazil** to manage all of your build artifacts.

Are you a master of virtualization tools like Kerberos or Docker?  Well, you can just shove all that knowledge to the back of your mind.  Because here you'll be using **Rapid Development Environment** (RDE).

Are you accustomed to running your apps locally with good ol' chestnuts like `npm start` or `yarn run`?  Not at Amazon!  You'll probably need to deploy/run all of your code on one of their EC2 machines (known internally as a **Cloud Desktop**).

Do you know ticket-management systems (like Jira) like the back of your hand?  Won't do you a bit of good here.  They built their own tool called **Simple Issue Manager** (SIM).

You've probably spent countless hours mining and managing company knowledgebases like Confluence.  But Amazon wrote their own custom version (_Of course!_) called **Quip**. 

Do you think you understand pull requests front-to-back?  Well, you won't be using `git` to submit them here.  You'll be creating a "change request" (CR) in their own custom tool - **CRUX**.

I could go on, but I can't even begin to tell you just how many tools they've created to do _the exact same things that you've always been doing in other jobs_.  

In fact, they've created _so many_ of their own custom tools, that there's little point in trying to Google for answers if you ever get stuck.  But not to worry!  They created _their own custom version of Stack Overflow_, called **Sage**!

To be fair, I _get it_.  A lot of this actually makes perfect sense.  Because it's been many years since Amazon made the majority of its money from online book sales.  In fact, Amazon doesn't even make the majority of their money from selling _any_ kinda tangible "products" online.  Amazon's biggest cash cow is, hands down, AWS.  

And what is AWS?  It's a massive conglomeration of network/code management tools that they built for their own internal use - and then they productized them by opening them up to the public.  But it can still be hella-frustrating when you have to learn, from scratch, how to do something that you mastered many years ago with "standard" open-source tools.
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mxt77d9b8mn9jtmba9g7.png)
## Cultural Quirks
Like all corporations, Amazon definitely has their own unique _culture_.  Some of those cultural quirks are great.  And some of them are, ummm... culture.

**Automation**

I suppose it stands to reason that a company the size of Amazon could never survive with a plethora of manual processes.  But it can be outright exasperating when you run into a "problem" and that problem can only be fixed by submitting a ticket.  To someone... on the other side of the world (literally).  Who may-or-may-not get back to you, in any way, in the next week-or-more. 

I'm not just talking about your standard help-desk kinda stuff.  I'm talking about really stressful stuff, like - when there's a problem with your pay.  Or when you don't know where to sign up for a certain benefit.  Or when you've been (mistakenly) locked out of the network.

For some of the most pressing personal/HR issues, there is simply no one who can/will talk to you _in real time_.

**Shared, Silent Reading Time**

I don't know if I'll _ever_ truly get comfortable with this.  But I've already witnessed it over and over again.

Someone schedules a meeting where everyone's supposed to review some _lonnnnnng_ document.  So they send you a meeting request.  But there's no link to the document _in the request_.  Instead, they get many people on the call, and only _then_ do they send everyone the link, and then they sit there, _on a live call_, and tell everyone to silently read the document.  This often takes 10, 15, or 20 minutes.  A quarter hour (or more) of everyone sitting in silence while they all, independently, read a document. 

Why they can't simply send everyone the link _before the call_, I'll never understand.  But I've already witnessed this so many times that I'm convinced it's an embedded - and probably unchangeable - part of Amazon's culture.

**A Java/Backend Mindset**

This probably doesn't apply to _some_ teams.  Heck, maybe it doesn't apply to _most_ teams.  But from the apps I've been exposed to, it's painfully clear that most of the devs are "backend driven".  Specifically, they're incredibly _Java-driven_.

Not that there's anything inherently "wrong" with this.  There are millions of Java LoC at Amazon.  So _of course_ their dev focus is gonna be largely centered on Java.  But I've noticed that general frontend proficiency can be... lacking.

On my team, I'm (currently) the only frontend-focused dev.  I was farmed out to another team on a temporary project - on which I was the only frontend-focused dev.  My friend also just got hired on an entirely different team (in AWS), on which he's the only frontend-focused dev.

The "problem" with this is that, sometimes, I find that teams have very little knowledge about _their own_ frontend apps.  And when they make new design decisions, they're often driven from the mindset of a "backend dev".

For example: Just today I had a really strange conversation with a colleague when I tried to submit code and realized that it wouldn't compile - because the build engine is configured to only allow code that's ES5 (or earlier) compliant.

Lemme be clear on this.  We're building a new app _from scratch_ with a significant frontend presence.  But everyone else on the team can't fathom why we should possibly consider dropping the use of `var`.  Yes... _really_.  I've also been met by the digital equivalent of blank stares whenever I suggest that a particular app/page/feature shouldn't require a complete round-trip back to the server every time the user provides any sort of input.  In fact, I've specifically been told that we should continue building new functionality in an old-skool client-server architecture because most of the people on the team are Java devs and this is what they'll understand.  Umm...
<br/><br/>



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0549g8dkt52y04o6ppmz.jpg)
## All About The Benjamins (Sorta)
_Of course_, any "right" job or "wrong" job is about more than just money.  But I'd be remiss if I didn't at least mention this.  

You're probably aware that FAANG companies tend to pay quite well.  _Extremely_ well.  And while money alone can't make a crappy job great, the simple fact is that Amazon can be extremely... _lucrative_ for experienced devs.  And lemme tell ya.  That's definitely a factor in making this "good" job into a great job.

I've been slinging code now for a quarter century.  I've been privileged to receive a very generous salary from _all_ of my employers over the last coupla decades.  But Amazon??  Well... lemme tell you.  They have deep pockets.  And I'd be lying if I said that it didn't make any of the corporate "quirks" far easier to laugh off.

No, I'm not gonna spell out my exact compensation.  But lemme put it to you like this:

* I now make almost _double_ my previous-highest salary.<br/><br/>

* They paid me a "signing bonus" (that isn't _really_ a signing bonus, because it gets paid in 12 monthly installments throughout the year - so it's much more akin to "additional salary").  I get a signing bonus in Year 1.  _And_ another signing bonus in Year 2 (assuming that I haven't quit or been fired).  The amount of each "signing bonus" is... insane.<br/><br/>

* I get stock grants.  They'll be fully invested in three years.  And the value of the grants alone is massive.<br/><br/>

Again - none of that alone makes Amazon a good job.  Even the best pay can't make up for, say, a crappy manager or a poorly-run company.  But luckily, those "issues" have not been present in my situation.  And since the job itself is genuinely rewarding, the pay is just a (massive, generous, bank-account-padding) cherry on top.

Would any of these observations apply _to you_, if you were to work at Amazon (or if you already work at Amazon)?  I have no idea.  Maybe my experiences are incredibly unique?  Or maybe my viewpoints will change drastically after I've worked here for another four months?  Or after a coupla years?  Who knows??  But I'd imagine that many devs working here may experience some (or all) of the same things.