Amazon

The compensation is top-tier in places you can work for Amazon. In fact, Amazon dominates the market in areas of the world that do not have a large tech presence, and you will be hard-pressed to find a company offering even roughly the same compensation for the same job.

Amazon operates on the cutting edge of scalability, which is an invaluable learning experience for any software engineer. Many of the AWS tools you get to use are leveraged at other companies, and as you master those tools, you will be able to build out your resume.

Benefits are good for the industry, and I would urge any present or future Amazon employees to fully leverage all of the benefit options available.

There are numerous special interest groups at Amazon that provide a way to meet like-minded individuals and establish long-lasting, valuable relationships with your peers.

Amazon has the ability to let you move almost anywhere in the world and keep a position with them. In fact, they encourage switching teams to get a wider perspective of the company as a whole, which is often a great excuse to move and receive relocation assistance from the company.

Amazon's culture is difficult to generalize because the manager has more impact on a team's culture than anything else. Unfortunately, Amazon encourages managers to take advantage of their direct reports through a handful of company mechanisms.

Amazon commonly issues promotions to management for high-performing teams, regardless of how the team reached their degree of high performance. Often, this leads to the manager indirectly encouraging absurd working hours in the name of fast results. Amazon also encourages management to 'trim the fat' by supporting a 5% employee fire rate to get rid of low performers. Unfortunately, this is often used as a tool to get rid of individuals that management does not like, regardless of their capabilities as an engineer.

It is common to see employees at Amazon quit or take sabbatical because of mental health concerns. In my time at Amazon, I witnessed approximately 60% of my peers either switch teams internally looking for greener pastures, quit outright, or mysteriously leave to 'pursue other opportunities,' as management put it.

Do not even get me started on the PIP culture, or as they call it, Pivot plans. Often portrayed as an opportunity to prove yourself, PIPs at Amazon are often the beginning to the end for an Amazon employee. I have witnessed individuals get PIP'd because management blamed an individual instead of owning a failure as a team. I have seen individuals get PIP'd numerous times in succession until they were unable to complete one. I have only heard from others while I was there that it is not uncommon for PIPs to be purposefully unachievable.

Lastly, Amazon eats its own dogfood. You will develop knowledge specific to internal Amazon tools that are not applicable anywhere else. This can have implications if you end up pursuing work at another company that uses common technologies like Docker, Kafka, etc., because Amazon has their own versions of most of these tools. Not to say these internal tools are not powerful, although many are dated.

I'll preface this by apologizing for the amount of generalizing I am about to do. There are amazing managers at Amazon who would go to the ends of the Earth for their team. Too bad for us, this is the exception, not the norm.

In traditional engineering professions, the manager is someone who insulates the team they manage from the chaos and nonsense of the surrounding business asks. It is typical for a manager in the civil, mechanical, material, electrical, etc., engineering space to advise their direct reports to "under promise and over deliver." This advice is sound, as the ideal client experience is to have expectations that are met or exceeded. Because of this, engineering managers will be more conservative with their estimates.

Then there's software engineering. How do you balance expectations with your clients? Who are your clients?

It is not uncommon for managers in software to advise their direct reports "not to sandbag their estimates" or to "not build in padding." This is in direct opposition to "under promise and over deliver."

Why is this? Is it because traditional software firms do not have clients? I would argue that upper management is your 'client' as a software engineer.

Now, imagine your client is your boss. This could make it much harder to under promise because your 'client' can demand more information when deadlines are being discussed if they are also your boss. It is also much more difficult to over deliver because expectations are fluid and progress is discussed regularly while simultaneously being subject to more pervasive inquiry.

As a result, managers in software are far more likely to pass through blame when things go awry. They are more likely to be ambitious when accepting tasks and projecting deadlines. This is true across the industry but even more so at Amazon because of the emphasis on personal career growth at the company.

My advice: Let's get back to under promising and over delivering. Managers are supposed to position their direct reports for success, not just the company.