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.
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".
(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,
"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."
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.
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.
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.
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.
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...
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.
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.
I get stock grants. They'll be fully invested in three years. And the value of the grants alone is massive.
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.
Top comments (35)
I'm an Amazon Sr. SDE of nearly 10 YOE.
First, you're absolutely right that Amazon is HUGE so there's no such thing as "never" or "always" Individual teams can be remarkably different.
That said, here's my responses:
This is quite rare. Each team I've been on works closely with business, data engineers, product managers, and marketing.
A lot of the times, we were inventing the wheel. Apollo/Pipelines simply didn't exist in the world when they were first written.
That said, Amazon is absolutely obsessed with writing their own version of everything or putting wrappers around everything. You're spot on there.
However, you still need to know the fundamentals. CRUX still relies on you knowing how to use git
Ironically enough, it's meant to respect everyone's time. By doing the reading within the meeting, it ensures that everyone is on the same page (quite literally lol). If they sent out the doc ahead, there would be maybe 20% of people that would actually read it and most wouldn't. Speaking from experience. At the beginning of COVID we tried not doing reading within the meeting and it never worked.
My trick is to just leave the meeting and come back in 15 mins. I cannot stand just being on a muted call. Someone always wants to talk and it interrupts my reading.
Yep. 100%
We do have access to and can use babel. It's easy to setup.
Thank you for providing this context!!
I have heard that the work load is very high there. Is it true?
It's very true. It takes quite the toll and Amazon certainly gets their money's worth (which makes sense, given what Amazon SDE salaries are). It's certainly on the individual to set their professional boundaries and to determine what "work-life balance" looks like for you.
On the one hand, I find myself doing interviews, going on-call, reviewing system designs, doing code reviews for six different programming languages, while writing in three different on my own project, etc. etc.
On the other hand, if I need to leave in the middle of the day to run an important errand or if I need to just log off a bit early every now and then, that's totally fine too.
You also get the work experience that fulfills any job description's wish list. AWS and Docker experience? HA! of course! CD/CI and testing? Of course!! etc.
@val_baca provided some great feedback on this already. And with the caveat that I've only worked here since March, I'll say that I agree with what he's mentioned. The workload doesn't honestly feel inordinately high - to me, at least. Yes, we have a lotta work. (And honestly, we should have a lotta work, considering how we're compensated.) But there's a tremendous amount of trust/freedom afforded to us as well. I've had to call out for a few days here-and-there, and no one's batted an eye at it yet. (Although I'm sure that would be quite different if you didn't know how to properly/professionally communicate those times off with your manager and/or your colleagues.)
I also think, given that Amazon tends to hire very "top-shelf" kinda devs, one of the expectations about being in that kinda privileged position is that you're inherently self-driven. For example, it's almost 9:30PM right now - and I'm still working. But am I working cuz someone at Amazon yelled at me or pressured me into working late?? Not at all. I'm working now because 1) this is a great time for me to work, and 2) I'm incredibly invested in finishing the coding task in front of me at the moment. If I had just shut down my laptop at 5PM, nobody woulda said a darn thing to me about it. But I want to be working on this code right now.
Ultimately, it's about whether or not you can deliver a large volume of quality solutions in an "efficient" period of time. When you're trying to get a lotta stuff done, and you feel personally invested in the work, then sometimes you find yourself working late - entirely of your own accord.
Thanks for sharing! I felt a lot of these things when I joined Google as well. What hit me the most was how much you actually owned and were accountable for. You are expected to find useful work that fulfills the business objectives. It's really cool to be empowered at that level but it can also be overwhelming at times!
You don't get stock options, you get stock grants. And yes, it's annoying as h3ll that they have their own tools that are poor versions of readily available software. However, that's true at many a large, sw-oriented company (RE: Microsoft).
So you're working at Amazon, but not at AWS? I definitely agree about the double-sided edge of autonomy one gets at Amazon. The team I used to be on gave up on hiring less than senior people as too many floundered when left alone to find their way.
That speaks to terrible mentoring, which is part of every Senior's job description.
Nope. As I said, too many, but not all, floundered. I would agree with you if everyone floundered. At some point, every mentor must let their protege on their own.
Thank you for the correction on stocks-vs-grants. And no, I don't work directly for an AWS team.
With the exception of the great pay, my experiences at Microsoft were exactly the same.
Why use webpack or anything else that just follows the import statements when we can use our proprietary thingy from circa 2002 that has to have all dependencies manually entered, in order, in massive .ini files.
What kills me is that neither company seem to produce actually good code. I sometimes wonder how they haven't gone under.
Great article, very interesting.
I have to admit I am curious about the salary part, you mention it almost double and that it's very high. Everything is relative so it really doesn't mean much. But can you tell us if you are talking over 100k, 200k, 300k or more than that (salary alone, no signing bonus)? I think telling us that would really put into context the salary you describe.
I should clarify that my total comp is more than double what I was previously making. I have a base salary that is still the highest I've ever had (in the upper $100k-$200k range). But while the salary is very good, it's def not double my previous highest salary. In fact, I had a job last year where I was making $160k. But that job did not come with the (very valuable) stock grants or the (very sizable) signing bonuses.
Ok I see. That's really great. But I think Amazon makes you pass ridiculously complicated technical tests and interviews. Isn't it like an elitist process to be hired?
I was actually shocked at how NON-elitist it was. You can read about that here: dev.to/bytebodger/how-i-got-hired-...
That being said: Are some Amazon jobs incredibly elitist to get into?? Yeah. I'm sure they are. Again, Amazon's friggin huge. And many of their teams interview in many different ways.
Very interesting man! Thanks for the discussion
Great write up, and the whole time reading it i'm like "This explains why AWS' interfaces and UI/UX are so terrible in so many ways"
Don't get me wrong, AWS is an amazing platform, it can do far too much in far too many ways and the interfaces are often confusing as hell.
And then there's the stupid little things that kill me. Why can't we download an S3 bucket as a zip file....sure they're not "directories"...who cares, you can write code to make em directories for a moment and then zip em up...i've had at least half a dozen clients ask me about this....
So, we wrote our own api connection to S3 that just loops through the files downloads them and then zips em up....but man it's a pain in the butt to deal with.
Just one example of many "simple" things I feel were overlooked because AWS is developer driven.
Great points! I too had many frustrations with AWS long before I came to work for Amazon. It's an amazingly-powerful suite of tools. But I always felt that it was surprisingly obtuse/confusing and it often felt like it was missing key features. But now I realize that this is because most of the AWS tools were built to meet internal needs. And those internal needs don't always map to customer requirements when it's exposed as a public service.
Great insights and thanks for sharing.
I've read about the silent meetings before and find the idea exciting. seems to go right back to Jeff Bezos.
qz.com/work/1422191/why-silent-mee...
@bytebodger
Dang that sounds so cool but also intimidating when there is noone who provides you with tasks or does code reviews.
Speaking of which, are you doing pair programming even with backend devs at times or do you have any mentor programs there?
Is it better to learn multiple frameworks (svelte, vue, react...) or to concentrate on one you are good at? In your example it sounds like you have to decide the best outcome and therefore you need the knowledge for it even if you didn't master it yet.
There's the occasional screenshare, but nothing I've seen that would qualify as "pair programming" IMHO. As for learning multiple frameworks, when you have the chance to influence the decision-making for a new app (which is rare - in any job), it's always nice to have knowledge of many different languages / frameworks / platforms / etc. But it's not like it's required. If you're on the team and all you know is Angular, they're not gonna expect you to offer a detailed evaluation of Svelte, Vue, React, etc.
How did the ES5 situation ended? I'm thinking to myself, if I would feel happy working with "old code".. In the past I was in a project using jquery and I felt really sad... stuck.. since I felt that I was going backwards ... How do you feel with that situation?
And about needing help.. since you are the only frontend dev, how do you do when you need help from another person? And about the quality? Who checks your code quality? Is done by a backender?
Sorry for the questions, you got me super curious!
To be clear, it's not as though everything is ES5. It's just on this one side project for which I've been farmed out. And that little drama hasn't been completely resolved yet (although the team lead does seem to agree with me about the need to get off an ES5 standard).
My code is checked often by backend devs. Of course, the "backend" devs aren't usually 1000% backend. Most of them have written frontend code and are at least reasonably familiar with it.
However, when I truly need help on something, it can sometimes be a little tricky trying to get useful input from the other team members who don't typically touch any of the frontend code.
Will I get into danger of being an attempted target of recruitment by Amazon if I post a comment here?
it's a strange position to not already be targeted lol
Some comments may only be visible to logged-in visitors. Sign in to view all comments.