It sounds like you had a bad manager and possibly team, and you made the right decision for yourself. I'd like to offer a few counterpoints from having landed on what I consider to be a good team/manager.

The first point is that things are manager and team dependent. Amazon is a lot more hierarchical than other companies when it comes to SDE levels, so I'd assume this also happens with managerial levels. There's probably a leadership disconnect that allows bad managers to thrive, but this is not a company-wide issue.

> Teammates are out for blood [...] metrics tracked are insanely stupid such as no of comments, revisions on a PR

I do agree with this to an extent. Some people at Amazon are more cut-throat and it can get annoying when you have to deal with them if you don't like playing those games. The metrics you're talking about are a mechanism for identifying outliers and are merely a data point; they aren't used to judge performance by themselves. I.e. if the rest of your team sends out 100 PRs a year on average but you sent out only 20, all it means is that it should be taken into account why your work style or output is different. If you've added 10 comments in the past year but your teammates have added 100 on average, that's also an indication that maybe you aren't pulling your weight in reviews. Managers don't have infinite time so they should be using these metrics as an indication of when to look into the details. Blindly using these metrics to evaluate performance is the sign of a bad manager. I'm sure there are bad managers, and people also try to game the system.

> Manager asks to crunch for no apparent reason

Could be the sign of a new manager (hasn't learned to say no to their leadership chain yet), or a bad manager. There are hard deadlines and soft deadlines, though even the hard deadlines can be softened up. Always pushing to meet every single deadline will lead to burnout and terrible output/operations in the long run. Prioritization is important, and that includes your team's mental health.

> People expect u to sacrifice weekends for "learning" internal tools

I won't lie, I definitely worked a lot my first year. There's a large ecosystem of internal tools, systems, and processes, and there's no other way to keep up unless you have prior experience or have someone helping you. The thing is that after about a year, I stopped having to do this. In the past year I haven't worked weekends or late into the night, except for a few operations-related high-severity issues (which is part of being on-call). My first year I definitely pulled 70 hour weeks on average, but I learned how to be self-sufficient. Now I pull 30 hour weeks, and I spend a lot of my time helping other developers on the team.

> Hell is an agile sprint system that has been optimized to require 10 hour days

Completely team dependent, we don't do any estimation for example and our sprints are more kanban.

> Leaders never sit quiet. If u hv nothing to say, then speak anything or just say i agree

We have some people on our team (newer hires in the past 1-2 years) that do not provide any feedback during design reviews or most meetings. Forcing people to say anything is a mechanism to get them to start talking so they get comfortable with providing feedback even when they aren't confident, so it builds up their confidence. Part of the issue here is the virtual environment, as it's a lot easier to get people contributing in person.

> If the guy reviewing ur work is not approving, its ur problem

This ownership aspect is definitely true and it's something that took me a while to get used to. There's no skating by on "I'm blocked by person X or thing Y". You have to figure it out, even if that means pinging them or their team or escalating to their manager (through yours). Typically you try to follow the reviewal process, make your PRs as good as possible, etc first instead of being annoying. Not all people work this way as a default, and you'll have a much harder time getting things done at Amazon if you don't learn.

> Deadlines are very top down where management promises castle in the sky

These deadlines include a business requirements document that includes various phases of prioritization: P0 (must be done by deadline or we have to move deadline), P1 (ideally should be done, but if it can't be we won't let the deadline slip), P2 (follow-up or nice to have), etc.

Part of a TPM's role is to figure out whats achievable in the timelines, and part of your role as an SDE is to provide the detailed inputs on whats achievable and move things to different phases if they're not. This type of work is uncomfortable for a lot of developers but if you don't do it, you'll be working 100-hour weeks and wondering if its worth it (its not).

One last point I'd like to make, which took me a long time to get comfortable with is that everyone gets assigned work that amounts to something like 150% of their max capacity (at the individual level, team level, org level). It then needs to be prioritized and some things will never get done--the most important things (in terms of customer impact) should get done, and the least important things should pretty much be ignored since there will be more important things coming in that should take priority. This means that if you try to get everything done you will always be busy and never finished, and burn yourself out. I wasn't comfortable with this at first, and I can definitely understand how some people would never become comfortable with it.