Why I left Amazon… (PIP?)

Amazon.com is well known to be an extremely valued company. Although, their engineering work culture doesn’t garnish the same respect. With worries of performance improvement plans (PIP) that translate to letting go of under performing employees, there’s a lot of concern about joining or staying at the company. I was Amazon for a year before I left, here’s what happened

My Quick Background

I’m a current software engineer at Microsoft who has previously worked at Amazon as a software engineer. Both my tenure’s at each company is approximately 1 year exactly. While I have a lot to say about the differences between the two companies, here’s the issues I had with Amazon specifically.

Why I left

I won’t keep you in suspense, I wasn’t pip’d but that doesn’t mean there’s a lot of other reasons I was considering other opportunities.

Compensation

Nobody will outright admit to another employer that they are leaving simply because of compensation. It sounds outright greedy, but often times this tends to be one of the largest reasons for employees moving around.

My compensation at Amazon was $150,000 for a new graduate out of college. This is a huge compensation for anyone with 0 years of experience, I agree. But when Microsoft is offering $180,000, I had to consider making the move to switch over. Especially when I’m considering the missing benefits at Amazon.

1. 401k plan that takes 3 years to vest ($.50 match up to %6 of salary).
2. Back-loaded stock schedule of 5% 15% 40% 40%.
3. Non-existant stock purchase plan.

Day spent coding

Maybe you’ve been asked this in an interview: “What percent of your day is spent coding?” Most companies would like to hear 60% or more for engineers. I wasn’t meeting that threshold at 30%.

There’s a lot of operations work at Amazon and a big reason has to do with the coding standards the company has. When you look at the Amazon Leadership principles, notice how many are geared towards code quality (1 — Invent and simplify?). With so much focus on customers, the engineering work starts to become neglected.

My operations work included things like being on-call once a month. This translates to 12 weeks or 2 months of just managing a ticket queue and being woken up at 3am. I spent more time understanding why something broke instead of coding something to fix it before my on-call shift ended.

There wasn’t enough time to focus on coding project work. I was too busy trying to understand code someone wrote years ago who was no longer at the company.

Project Politics

Projects move around. One day a team can own a different service or product, the next day that service or product can be forced to another team. Here’s why this isn’t good.

1. It takes time to ramp up on that new project. Slowing people down to understand this new project holds them back from focusing on other project work
2. There will be more mistakes, more operations, and more stress. The new team doesn’t know the project as well as the original team and they won’t hold themselves to the same standard of code when trying to fix problems.

Needless to say, when I saw teams trading projects, I could tell they were both going to be stressed.

I wasn’t set up to be successful

My first month at work, I was moved to a project with a tight 1-month deadline. Here’s how I failed

1. I did not know the language we were using very well (Scala). I was only ever taught Java in school. Is this my fault? I think I just needed more time to get familiar with the language.
2. No one was there to onboard me. With everyone stressed over this project, I had little guidance or support on how to contribute to this project. The most help I could get was reading complicated design docs that I wouldn’t expect most new graduates to understand.
3. I did not understand the codebase very well or why it was set up the way it was. Needless to say, finding where my changes belonged slowed me down to the point where I felt helpless to contribute

All these issues compounded and made me worried about my own career as a software engineer.

Constantly being worried about PIP culture

5%-10% of the department/organization will always have to be under a performance improvement plan. This is similar to old stack ranking practiced by Microsoft.

If you’re always worried about performing well, keeping your job, yet not able to make contributions because you’re not set up for success working on operations, then your mental health will start taking a toll.

Sadly, if it was possible to just have more open conversation regarding PIP with my manager, this would have been one less thing to worry about. But how often can you say to your manager

“I’m worried about the PIP culture, how can we make sure I can be successful?”

Rather, the answer feels implicit. Work harder, show results, and make sure you’re better than the bottom 10%.

It all was too much stress for me to handle.

If you enjoyed this experience consider being a member for more content like this!

Please consider subscribing to be the first to be the first to receive emails for my experiences.

I later applied to Google. Here’s how that experience went

And follow me on my quest to 30,000 followers on LinkedIn Alex Nguyen | LinkedIn

Here’s the best system design resource that helped me with my interviews.