521–530 of 706 posts
Earlier quoted context omitted.
> That sounds like a huge disincentive to mentoring and developing your team. I've heard there are huge communication issues within teams, thanks to policies like this. You have to look out for yourself first and foremost, otherwise you are up next for the stack ranking. Better to sabotage your team mate's onboarding than risk being next in line for the firing squad. It's actually worse, because it's actually a "unre…
And all these sounds to me that devs at Amazon needs unionization rather faster than the poor workers in their warehouses.
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 shitty. My experience in Seattle started off extremely shitty, 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 hell) - 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 screw 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.
Earlier quoted context omitted.
No. There are companies where you can have a life, but they are boring. And there are companies that pay you more, but there’s always a catch. In my long resume consisting of Startups to SV Giants, not one company paid you a lot to do less work.
I’ve heard it described as: “You can work on interesting problems, have a great work-life balance, or get paid really well, but you can only select two.”
> (It is incredible how flexible and effective Excel is for such a wide variety of use-cases) I worked for a Japanese company, and they used Excel for everything . GANTT Charts were done in Excel (not Project), documentation was written in Excel (not Word), etc. They had these monster 3,000-row excel punchlists for QC. If even one test failed, the whole shooting match was scrapped.
Oh, I forgot to mention. Slideshows were done in Excel (not PP).
Earlier quoted context omitted.
> I bag on Amazon a lot on here (which if I were to review with my therapist is likely because I had an absolutely HORRENDOUS experience in an interview loop with them my first step out of college that still makes me nervous in interviews, even 15 years later). Hey, I had a similar experience with Google! It was my first technical interview for my first job out of college. The interviewer laughed at my code, and then…
I would love to know how long the average FANG dev spent on leetcode practice before their interviews. From my small sample of friends who've done stints there, it's far less than "months". I similarly have had - but declined - an offer from one of them with prep measured in "hours" not "days."
Earlier quoted context omitted.
A quota of people who needed to be on PIPs? That's insane.
Just a few months ago it came to light that managers at Amazon hire new people they're planning to fire shortly after, so they don't have to fire people they're attached to in order to meet such a quota. https://www.businessinsider.com/amazon-tracks-unregretted-at...
Hey congrats on making it 10 months! "Urgent to not block progress, but also ironic that they are asking a person who has no clue what they are doing to deliver critical work" Friend of mine started a role there (this was 4-5 years ago) and was fired (sorry... more or less asked to leave, being told he could keep his signing bonus if he just left) within about six weeks because he wasn't immediately delivering on som…
> I bag on Amazon a lot on here (which if I were to review with my therapist is likely because I had an absolutely HORRENDOUS experience in an interview loop with them my first step out of college that still makes me nervous in interviews, even 15 years later). Hey, I had a similar experience with Google! It was my first technical interview for my first job out of college. The interviewer laughed at my code, and then…
It’s fine. I’ve seen code from FAANGs that evoked the same reaction from me.
Earlier quoted context omitted.
And all these sounds to me that devs at Amazon needs unionization rather faster than the poor workers in their warehouses.
As bad as it is for any developer at Amazon, I have to say that I'm going to feel more sympathy for the people in the warehouse who are told to get back to work when a line worker dies of a heart attack in the middle of their shift due to stress than any developer who can always leave and get a fine job somewhere else. The precariat in those warehouses need collective bargaining more than any developer, anywhere (exc…
I have a joke for you, goes something like this: "Big rich guy goes to Mexico for vacation. There he meets Julio, a simple worker who after work is drinking in the bar with his friends and enjoys a simple life. Rich guy asks why Julio doesn't work longer & harder to make more money.
Why?
So when you grow older to have time, like me, to enjoy life and party with friends.
I can party with my friends right now and enjoy life just as well"