Thread regarding IBM layoffs

blog post: I quit Amazon 10 months after I joined the company

https://benadam.me/thoughts/my-experience-at-amazon/

by
| 2564 views | | 9 replies (last ) | Reply
Post ID: @OP+1eFPeql9

9 replies (most recent on top)

Yep exactly even if amzn is like the worst culture, staying there gives ample opportunity to goto other better companies compared to staying at ibm.

Ibm doesn't have money anyway to pay its experienced developers.

by
| | Reply
Post ID: @1tnx+1eFPeql9

This doesn't surprise me. I know a number of people who left IBM for Amazon, and within a year left Amazon - usually for Google or Facebook, one for Microsoft.

And before anybody accuses me of shilling for HR: I don't know anybody who left Amazon and came back to IBM.

by
| | Reply
Post ID: @1czq+1eFPeql9

I love being productive, but hate being pressured

by
| | Reply
Post ID: @1mou+1eFPeql9
  1. "How manual most of the processes were" - manual processes are more durable to turnover
  1. "Documentation is very important at Amazon" - helps alleviate the impact of constant turnover
  1. "Teams are fragile" - um, because of turnover?
  1. "Everything is urgent" - indirectly because of turnover, because if you don't nag people to enable your deliverables, you get fired.
  1. "Everything is built in house" - helps make you harder to fire, gives you bully power over other new hires since you know it top to bottom, protects you from the organization that is trying to constantly turn over people
by
| | Reply
Post ID: @1bji+1eFPeql9

Don't ignore your mental health! I've been with amazon for 8 years (still an employee) as a software engineer. I've concluded that your experience at amazon - both work life balance and technical - is entirely dependent on your skip manager and your org.

I started with Amazon in the bay area. When I joined we were still in the very early days of our project. The work was awesome, and it felt like we were creating great things. Unfortunately, the ops burden (oncall) became way too much for our team to handle and the quality of life plummeted. My existence during those days was pure pain. From there I relocated (through Amazon) to Seattle to work on something else. I did the move with the promise that I'd immediately get to work on a cool project, but I ended up sitting around doing nothing for months. I didn't even have a desk. Once the project finally started though, things become great. Both of these teams had different VPs, and the cultures of each org were very different as well. My experience in the bay area started off very positively, and then become extremely sh---y. My experience in Seattle started off extremely sh---y, but then it turned into the most fun 2 years of coding I've done.

Additionally, different orgs do things differently. AWS does things different from how Alexa/Retail/Music/Movies/etc do things. A good example of this: Twitch isn't fully integrated with all of Amazon's internal systems (see recent news for reference). Some teams don't have oncall rotations, other teams have brutal ones. One of my previous directors used to do bi-weekly (once every two weeks) fireside chats. I haven't even met my current director, and I've been under him for a year and a half.

If you're entering the company from the outside, you might very well be walking into a dumpster fire of a team. If you're inside the company, it's really easy to spot which teams are garbage and which ones are not. Below is my guide:

Red Flags: - No nearby principals (no tech guidance at the director level) - Too many principals (bureaucratic arm chair engineering he-l) - Average tenure of engineers on the team is SDE1 (trash code) - No PRFAQ/BRDs (projects have no north star, scope is all over the place, dumpster fire product team) - Ops burden is too high (you can check a teams ticket queue on SIM, high ticket count = bad oncall) .... and many more ....

Doing team switches are pretty straight forward as well (ymmv). Once you're in the door at amazon, do your research and determine whether you need to switch teams ASAP. You can search any engineer's username and look at what code they're contributing. It's pretty easy to investigate the code base you'll be working on in advance of joining the team to determine its health.

Regarding tooling, amazon does and doesn't have great tooling. There are things like Pipelines, CR/Crux, Sim/TT, Apollo, iGraph, etc that are actually world class tools and don't really have any rivals out there (yet!). Then there are other things like people wanting to fork bootstrap and react so that they can rebrand it as an amazon version.... In one of my early teams, I saw the SDETs (test engineers) metaphorically go to war with each other to write the best end-to-end integration test framework. There were four frameworks in the end.

Regarding the leadership principles. Those are predominately tools to be used during the decision making process. There is this concept called "one way door decisions" which would be any decision that is made such that the amount of effort needed to undo that decision is not feasible. Basically if you take that door, you can't come back out. When faced with a one way door decision, you use the leadership principles to decide.

Are you on a fixed timeline because your deliverable is tied to AWS Re:Invent? Then you need to optimize for Bias for Action and Deliver Results. Are you about to create a core platform service that many many teams will build on? Obviously you need to optimize for Insist on the Highest Standards, if not you sc--w over your org for years.

The leadership principles contradict each other, but that generally gives you an idea of what's being gained and lost in the decision making process.

For software engineers, I would not exclude amazon as an employer just because you read some stuff online. If you can get in, do it and stick around for a year or two at least. The amount that you learn in such a short amount of time is significant, and you can take that experience with you anywhere. If you're having a bad experience at Amazon, remember that the company is massive. You can switch orgs and it'll feel like you just changed companies (only the tooling is the same).

Final thoughts: don't ignore your mental health! I have never had a manager actually ask about my mental well being before. I don't think that culture is actually fostered at all at Amazon. Use your vacation time if you have it, switch teams if you need too, or just straight up quit.

by
| | Reply
Post ID: @jbw+1eFPeql9

One thing not often mentioned about FAANG is those massive compensation packages you see posted are almost entirely composed of one time RSU grant. Base salaries are below industry. No cash bonuses (just like IBM). Vesting at Amazon is 5% end of year 1, 15% end of year 2, then 5% every quarter thereafter, done because most people quit around the 18 month mark. Even if you make it 4 years, no guarantee of refresher RSUs.

by
| | Reply
Post ID: @eze+1eFPeql9

One thing I don't see mentioned enough is the forced PIP policy.
Basically every manager is forced to stack-rank their entire team, and the bottom N percent is put on a PIP. So even if your entire team is comprised of very top-notch engineers you will see forced attrition. It also disincentivizes helping team-members in deep ways and incentivizes back-stabbing politics.
Of course every org/VP has some latitude, but this is a common principle adopted by many VPs to appease the "bar raiser" standards as well as giving enough motivation to axe employees with considerable equity despite how good they may be on an absolute scale.
This was the policy at a number of orgs when I was there 5 years ago, and I have heard similar stories as recently as 2019 pre-covid.

by
| | Reply
Post ID: @zkj+1eFPeql9

Lol ibm hr thinks that posting bad amzn stories will give them good publicity 🤣

Ibm still sucks and nobody wants to work there.

by
| | Reply
Post ID: @lar+1eFPeql9

I also left Amazon after ~10mo. I've written about this elsewhere, but the short version is:

  • New manager who was a nice guy but didn't help me or other folks onboard
  • A skip-level (who I expected would be my direct) manager who was about as hands-off as could be and seemed interested in building his own empire.
  • SDE3 who was nominally my mentor but was less than useless. I asked him to whiteboard our services, and he said he "didn't know" what we owned. I asked him for help configuring a monitor for a service, and he said he couldn't figure it out while literally backing away from my desk slowly.
  • A culture within our team in which no one was willing or able to help others out. It was very much every man for himself.

I GTFO of there and have been happy across the lake since. Paying back my signing bonus was well worth the significant reduction in stress and quality of life.

by
| | Reply
Post ID: @nnj+1eFPeql9

Post a reply

: