Live data from Hacker News

Hire-to-fire at Amazon India?

leetcode.com

311–320 of 589 posts

Re: Hire-to-fire at Amazon India?

#311

Former AWS engineer here. I worked on a pretty critical product in AWS (big AWS service with lots of traffic) and I can safely say that it's totally up to your manager and pre-existing conditions which make up the job. My manager was great as a person but would always lack in my career-oriented goals (bigger projects, promotions, etc) But what really sucked for me was the pre-existing conditions. Our on-call was pret…

Current Amazon engineer: it's far and away the most incompetently run bureaucracy with self-defeating dysfunctions forced on the huge number of layers. The recent "leaks" to Business Insider, pointed out to me by coworkers, are exactly what we see. Everything the parent comment mentioned is exactly what we see. Laughably, our middle manager berates us as incapable noobs, entirely unaware that some of us at least actu…

> I contrast it with excellent experiences at Sun, Motorola, Apple and others over the past 20+ years, where in some cases I had very high engineering ranks with fabulous results, in very well run and just healthy orgs.

I can understand how junior devs end up in these positions for a while and stay on the ride, but what is making someone with your level of experience you stick to Amazon? Is the compensation that good?

Re: Hire-to-fire at Amazon India?

#312

Earlier quoted context omitted.

> seem to have hit one of these areas of toxicity yourself Have you considered that the original poster's experience is actually the norm and that your experience is the one that is the anomaly? I was 1 for 2 in organizations with shitty leadership, and the organization that was run properly had zero open headcount. Everywhere people are hiring into is not one of the "good ones". Check out the old-fart tool, 85% of t…

I have considered it. I don't see the pattern widely, and I'm watching for it. I've seen teams implode because of it, and other toxic patterns, so it's not that they're not there... they just seem to be in the minority. There are teams I won't send friends to work for, for sure.

I've been doing software development for nearly a decade now and I've seen 0 teams implode. Nothing I would call a "toxic pattern" springs to mind either. If you've seen multiple occurrences of both at Amazon and think it's an ok place to work then I think you've just normalized the dysfunction.

Re: Hire-to-fire at Amazon India?

#313
Hire to fire might just be the sign of a healthy organization that only wants performant employees. You can't really tell how well someone is going to do just form an interview. Given a reasonable sample of work you'll know if you should keep them or not. Of course, human nature will lead to some of the perversions of the core idea and lead to good people being let go and buddies being kept on.

Re: Hire-to-fire at Amazon India?

#314

Former AWS engineer here. I worked on a pretty critical product in AWS (big AWS service with lots of traffic) and I can safely say that it's totally up to your manager and pre-existing conditions which make up the job. My manager was great as a person but would always lack in my career-oriented goals (bigger projects, promotions, etc) But what really sucked for me was the pre-existing conditions. Our on-call was pret…

>but I know of other teams who would have no issues in taking in a fresh college grad, making them do work for 6-12 months and then just randomly putting them on PIP. stack ranking came up in another thread a few days ago and this practice of forced attrition seems like just another way to do the same thing. I thought it was understood that this kind of structure just incentivizes internecine fighting and politics ov…

> Mind-boggling that there still exists upper management that thinks otherwise.

Far too many Harvard MBAs calling the shots, I guess?

Re: Hire-to-fire at Amazon India?

#315

Former AWS engineer here. I worked on a pretty critical product in AWS (big AWS service with lots of traffic) and I can safely say that it's totally up to your manager and pre-existing conditions which make up the job. My manager was great as a person but would always lack in my career-oriented goals (bigger projects, promotions, etc) But what really sucked for me was the pre-existing conditions. Our on-call was pret…

>Our on-call was pretty bad (40-60 tickets a week) and there was very little investment being put in to improve it. We had a lot of little scripts here and there which would solve extremely specific situations but no focus was ever put on in building a general framework or trying to reduce the ticket count. AWS engineer here and I confirm everything you say, but this quote really struck home with me. The thing I've n…

Can you share your knowledge or reading materials for how to reduce on-call load?

I’ve worked at a number of big companies but all the problems driving the oncall load seemed, at best, domain specific if not application specific with highly variable fix times and unpredictable occurrence (eg started becoming more of a problem due to unrelated change X). As a result each team has to decide the cost of fixing the pain vs focusing on other things.

If there’s actually best-practices here that help that we’re not already doing, I’d be extremely eager to learn about them. I’m not an Amazon engineer but I’ve been bitten by oncall stuff.

Re: Hire-to-fire at Amazon India?

#316

Earlier quoted context omitted.

Way back I used to work in telecommunications at a place that provided POTS service. They are two very completely different worlds. Software engineers act as if 5 9's is a badge of honor, when really it isn't. When you are responsible for something that people use to dial 911 and can make the difference between life and death a few minutes of downtime doesn't cut it.

Right, and even five nines would be impressive compared to: AWS will use commercially reasonable efforts to ensure that each individual Amazon EC2 instance (“Single EC2 Instance”) has an Hourly Uptime Percentage of at least 90% of the time in which that Single EC2 Instance is deployed during each clock hour (the “Hourly Commitment”). In the event any Single EC2 Instance does not meet the Hourly Commitment, you will n…

EC2 is absolutely not meant for this, though. Use an abstraction layer like Heroku if you're going to not understand what you're getting into.

The amount of times I've had to 'advise' small businesses that are somehow running their small business site off a single EC2 instance's ephemeral boot volume is atrocious.

Re: Hire-to-fire at Amazon India?

#317

Earlier quoted context omitted.

I'll tell you mine, L7. Seen and experienced personally things the author describes.

Like I said, I don't doubt that they happen, but given that you've also left the company and seem to have hit one of these areas of toxicity yourself, I'm not surprised you'd think so. Who was your last manager? I'm curious if it's anybody I know?

Amazon FinTech is such a toxic dumpster fire of unprofessional conduct, there’s a chance not only will they significantly harm the company, they’ll cause a legal issue with China, India, EU, or US by violating finance law.

If they haven’t already.

Amazon is routinely fined $15M+ in tax audits because they’re saving a few headcount on critical financial systems.

Leadership doesn’t care.

So yeah, if all of FGBS counts as “parts” — then sure, your comment may be technically correct.

Re: Hire-to-fire at Amazon India?

#318

Current (long tenured, moderately senior) AWS engineer here. I've been at the company long enough it's pretty clear that I'm a "good culture fit", so take what I'm saying with that in mind. While I absolutely believe that there are pockets of the company that work this way, more because of sheer scale than anything systemic, I have sat in the annual ratings meeting for engineers enough times, in enough organizations…

It’s a thing. The author was not unlucky. It’s actually a thing (I worked in AWS, I have heard this from several managers, some which actually had trouble struggling with how stupid the system is). You have a team of X engineers and you want to grow. You hire a couple more. The current engineers have 0 incentives to help the new ones. Most people don’t have the chops (technical or emotional) to go up against a whole…

>The current engineers have 0 incentives to help the new ones. Most people don’t have the chops (technical or emotional) to go up against a whole team.

This is why companies want to hire rockstars who can be productive in a couple of months without being helped by colleagues. One can't get such rockstars just by leetcode. Maybe, these companies should pay $1M per annum for such rockstars.

Re: Hire-to-fire at Amazon India?

#319

Former AWS engineer here. I worked on a pretty critical product in AWS (big AWS service with lots of traffic) and I can safely say that it's totally up to your manager and pre-existing conditions which make up the job. My manager was great as a person but would always lack in my career-oriented goals (bigger projects, promotions, etc) But what really sucked for me was the pre-existing conditions. Our on-call was pret…

> I can safely say that it's totally up to your manager and pre-existing conditions which make up the job

Isn't it like that at any job?

Re: Hire-to-fire at Amazon India?

#320

Earlier quoted context omitted.

>Our on-call was pretty bad (40-60 tickets a week) and there was very little investment being put in to improve it. We had a lot of little scripts here and there which would solve extremely specific situations but no focus was ever put on in building a general framework or trying to reduce the ticket count. AWS engineer here and I confirm everything you say, but this quote really struck home with me. The thing I've n…

Related to part of what you said. I've worked in a half dozen different industries; I've worked in little companies with a half-dozen employees and globe spanning companies with tens of thousands and employees. They all think that they have special unique problems that nobody else has - 90% of it is the same problem I've seen in other companies in different industries, with different industry specific acronyms and wo…

Same is true in academic research (though old-timers catch it often). The common pattern is:

* approach “A” was invented in 1970 or so and didn’t work

* “B” extends “A” in multiple ways and now works

* noobs assume “B” invented “A” and treat “B” as the root of modern knowledge. “B” often has more market presence so noobs (without deep understanding) don’t see the relationship to prior attempts.

Examples:

* AlexNet/deep learning/ML in general

* MapReduce/databases/functional programming primitives

* Docker/chroot “Jail” Containers

* Bitcoin/90s coins/blockchains

Ego and ignorance are rarely a great combination :)

Post reply on HN