Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hire-to-fire at Amazon India?

leetcode.com

Post reply on HN
Print view View original

471–480 of 589 posts

Re: Hire-to-fire at Amazon India?

#471

Post by wly_cdgr »

awsthro00945 wrote: post #309
SheinhardtWigCo wrote: post #291

Earlier quoted context omitted.

I don’t get this. In this market, if you’re good, why take a job with any on-call work? It’s thankless, shitty work. If you can deliver features, that’s good enough to get paid extremely well at other Amazon-scale companies with dedicated SRE teams. What’s making you stay?

Because changing jobs is really fucking difficult. I'm probably one of the biggest proponents of "quit your job, you deserve better" that you'll ever find, but even I have to admit that finding a new job is ridiculously hard. Even in "this market", even if you're a top engineer, it's still ridiculously hard to even get an interview, let alone get hired. There is only a limited amount of companies that will pay at the…

There are many, many companies that will pay at the same level as Amazon and hire you after less than ten hours total of interviews, as long as you think of compensation the correct way: in hourly terms

Re: Hire-to-fire at Amazon India?

#472

Post by user275 »

Sorry that the OP has experienced this. I work for AWS (SA), have heard about this but does not seems as prevalent at AWS SDE teams as in Amazon teams. Agreed that there is a huge risk to loose skills and then it is hard to find an exciting job. Another point to have into consideration is how massively underpaid most folks are. It is common to hear stories of folks that move to the competition after carefully preparing for interviews and get good offer. Often AWS managers match or go above. Recently one of my colleagues left to the competition to rejoin AWS 3 months later with a 40k pay raise (same job, same team, same work output from the person). Knowing what i know after working at AWS for several years, be mindful that the company is so big that you might be the one doing crappy or low value work. Moreover, if you decide to take the risk of loosing your skillset, make sure you negotiate well and keep coding on the side.

Re: Hire-to-fire at Amazon India?

#473

Post by tablespoon »

kazen44 wrote: post #441
tablespoon wrote: post #248

Earlier quoted context omitted.

> Management has zero incentive to change any of problems you signal, and probably don't see them as an issue. It sounds like management intentionally created these practices. This is from a recent NY Times article about Amazon warehouse workers, but it wouldn't surprise me if this attitude was applied to all workers in the company to some degree: https://www.nytimes.com/2021/06/15/us/politics/amazon-wareho... : > 5.…

> Company data showed that most employees became less eager over time, he said, and Mr. Bezos believed that people were inherently lazy. “What he would say is that our nature as humans is to expend as little energy as possible to get what we want or need,” If this was truly the case, humans would have evolved very differently (and it's needs would be substantially smaller. Also, what about all those people working fo…

We'll it might be true from Bezos's perspective, even if it's not true generally. Basically Bezo's goal is to get people working as hard as possible to enrich him and his shareholders. I think in many cases people expend more energy than needed to get what they want or need, but it's almost never in the service of getting some asshole billionaire they've never met a little richer. The energy people get from a novel job or from trying to prove themselves to a new community is short lived.

Also, as another data-point: slaveholders of all eras could not stop complaining about how lazy their slaves were. They expected the slaves to give their all, even though practically nothing was in it for them.

Re: Hire-to-fire at Amazon India?

#474

Post by notacoward »

mavelikara wrote: post #336
notacoward wrote: post #214

Earlier quoted context omitted.

Yes, everyone should release code and watch metrics etc. but I think that's at the very edge of what "testing" encompasses. Between model checking, traditional forms of testing, and shadow-traffic testing (which can test higher per-server load than prod), finding something after deploy should be like a parachute failure. Yes those happen, yes there should be a reserve, but if it happens more than once in a blue moon…

Tangential, where can I learn more about shadow-traffic testing? Books, blogs, tools etc.

Cindy Sridharan often writes well about these topics.

https://copyconstruct.medium.com/testing-in-production-the-s...

For this one I'd start about half way down, under the heading

"Shadowing (also known as Dark Traffic Testing or Mirroring)"

Unfortunately the terminology is a bit fragmented - shadowing, mirroring, teeing, dark traffic (ick), ad nauseam.

Whatever you call it, it's often pretty high overhead to add the infrastructure, unless you're already using some sort of "service mesh" (Envoy/Istio/Caddy/whatever) that supports it. Even then, if you're dealing specifically with a storage system then there can be some thorny issues - idempotent vs. non-idempotent vs. destructive requests, requests which require other objects (files/objects or directories/buckets) to exist or be in specific states, etc. I'm not going to pretend it's easy.

If you can do it, though, it can be an incredibly valuable tool. There ain't nothing like the real traffic, baby. ;) My favorite feature, which I alluded to earlier, is that you can shadow traffic from a larger production cluster onto a smaller shadow cluster and give it a serious stress test. All sorts of bugs tend to fall out that way. The one thing you can't really catch, even with a good shadow, is interactions with other services - including things like permissions or quotas. But if those are the only things you have to shake out in true production, you're doing well.

Re: Hire-to-fire at Amazon India?

#475

Post by cduzz »

rodgerd wrote: post #454
cduzz wrote: post #75

Earlier quoted context omitted.

The org is getting what it wants out of the team; why would they fix it? As long as you've got meat for the grinder, you can keep making sausage.

Also: the cruelty is the point.

I'd disagree with that.

One doesn't need to be cruel to be callous or oblivious.

One can intentionally remain oblivious, but that doesn't imply that the cruelty is an actual goal.

See also people who happily eat meat (myself included) who are still troubled (as a 5th order concern) by the process.

Re: Hire-to-fire at Amazon India?

#476

Post by walshemj »

salil999 wrote: post #18

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…

Very weird if you do get called out do you not take TOIL? and get paid on call allowances? Having this cost exposed will lead to things getting fixed.

This solution works based on knowing developers on CSS the huge mainframe billing system and my own experience as the lead for a smaller BT billing system I worked on.

And TBH a 1-2 kloc method isn't that big I have seen individual SPROCS over 2.5k

Re: Hire-to-fire at Amazon India?

#478

Post by whakim »

wpietri wrote: post #114
pc86 wrote: post #50

Earlier quoted context omitted.

This isn't specific to Bezos, and it's not specific to any particular class or type of "worker." If Bezos could double his money today with zero work he'd certainly do it. The family business down the road would cut every employees' salary in half tomorrow if it could. It's just the free market, nothing particularly interesting or scary about it. Everyone wants to get the absolute best deal for themselves, and some a…

Nah. That's not "the free market". And that's not how most employers are. Wanting extra useless billions even if it immiserates others isn't commerce, it's sociopathy. Even sticking with industrial titans, look at Henry Ford, who insisted on paying his workers a living wage. That was revolutionary at the time, and put America on the road to having a significant middle class.

> Even sticking with industrial titans, look at Henry Ford, who insisted on paying his workers a living wage. That was revolutionary at the time, and put America on the road to having a significant middle class.

Henry Ford didn't pay a "living wage" (I have no idea if the amount Ford paid was actually technically a living wage or not, but just using your terminology) out of the goodness of his heart - he did so in order to combat extremely high turnover. It actually cost less money to pay his workers more and spend less money on hiring and training new staff.

Re: Hire-to-fire at Amazon India?

#479

Post by walshemj »

rossjudson wrote: post #403
YZF wrote: post #340

Earlier quoted context omitted.

I'm not the parent but lemme chime in on this topic. It's pretty simple, if you don't build crappy software you won't get a heavy on-call load. You're really asking how to build great software. Build strong teams, with experienced people, follow good practices, reward quality and stability and not features or lines of code, reduce complexity, etc. etc. I've worked on software used by millions of people with a very lo…

This is oversimplification. One reality is more like "You are handed a system with a heavy on-call load. Make it better." The other is "The system you built was great with 1e9 load, but now we're heading for 1e12 load. Make it better."

Sometimes throw it away and start again is the right answer

Re: Hire-to-fire at Amazon India?

#480

Post by [deleted] »

awscurrentdev wrote: post #121
salil999 wrote: post #18

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 AWS engineer here, can confirm. I'm absolutely broken. I'd second the point about the manager and pre-existing conditions making up the job. It's not clear to me if it's endemic, these are big orgs with teams run very differently. That being said, the on-call sucks. It's really awful, and something I've never seen before. It's also typically the primary cause of team churn for people in my org. This varies, a…

[deleted]
Post reply on HN