Amazon

Amazon is a very decentralized and siloed company, so many areas are great for developers and managers to work in. In these good areas, devs get:

• A lot of freedom to do the right thing
• Great support from upper management
• The ability to experiment with new and interesting technologies
• A strong commitment to building tools and infrastructure to make life easier for devs

As a manager, if you're in these shiny areas, you own your project, soup-to-nuts. You will work with program managers and product managers, not for them. It isn't an easy environment to manage in: you're generally expected to do a lot of things that other companies use TPMs for, but I personally find the challenge very rewarding.

Amazon is a very decentralized and siloed company, so many areas are essentially rat holes that developers can easily get lost in. Most of the negative reviews are probably from those areas, and they are every bit as bad as you might imagine.

Rather than repeat the bad, I would encourage anyone looking seriously at Amazon to ask a few things of the developers (not the hiring manager) that they talk to:

• How often are you on call?
• How often do you get paged?
• What kind of schedule does this position require (45-hour weeks? 60+ hour weeks?)?
• When was the last time you worked a weekend when you weren't on call?
• How much legacy/technical debt is the team responsible for?

And probably the most important question of all you have to ask yourself: Is this team solving problems that are interesting to me? The teams that aren't are teams you will never be happy at, no matter what the rest of the environment is like.

The final tidbit that does somewhat make up for some of the less "optimal" teams: Amazon has a policy where anyone can change positions after they've been in their current position for a year (provided you don't get a negative review). So even if you don't like where you're at, you can always move, which is great if you don't want to lose your vesting stock grants.

We measure success and efficiency on so many dimensions. I think it would be worth taking a deeper look at what makes a successful development team inside Amazon. We would all benefit if some light was shined into some of these teams with high attrition, even among veteran Amazonians. What these teams cost the company is hard to measure, but it's certainly larger than a breadbox.