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

201–210 of 589 posts

Re: Hire-to-fire at Amazon India?

#201

Post by markus_zhang »

nobleach wrote: post #179
markus_zhang wrote: post #85

Earlier quoted context omitted.

I'm always surprised why industry leads (like Amazon) sometimes treat their products as an amateur treats his/her weekend projects. This is definitely not the worst as I know one of the leading options marketmaker has been using a giant shit mountain of MS Access/Excel VBA code to run their system since the 90s. Last time I heard about it (a few years ago) they are planning to replace that shit mountain with somethin…

It's built into the culture to ship, ship, ship. Shipped code is better than good code, or clean code, or fast code. At my last job, the C-level was fascinated by Amazon success stories. They wanted to achieve the same success, so they urged us to ship, ship, ship. Unfortunately, we were all very seasoned engineers, and we knew the nightmare that would ensue if we purposely piled on the tech debt. The part of this ar…

I think this culture is OK or even good to a company in start-up because you have to be quick. Once it grow into maturity those rules should be abandonned.

Re: Hire-to-fire at Amazon India?

#202

Post by throwaway_32242 »

Current Amazon engineer (not AWS, not in NA or India) here. I feel very surprised to see folks in India having such a bad experience working in Amazon, because we're almost completely the opposite here. I feel bad for those who suffered.

I've been working for 2 years here now, never heard about the "intent to fire" thing. Our oncall is not perfect but we're definitely working to improve service stability. Working hours have been worse than before since the start of COVID (working at home makes it easier to overwork), but it's still manageable, and when we were in the office it was mostly a 9-5 (or 10-6) job. Unless you're oncall and get paged, nobody would expect you to think about work from the moment you walk out of the office in the evening.

Like people have said, managers really decide your experience. I've had some bad managers and did internal transfer to improve my experience. There were some projects where I worked with teams located in India, and sometimes I do feel that they're quite different. Some PMs and even leadership there would push really hard to get things done, to the extent that we could feel their pressure. That never happened in other projects we did before, and this post seems to give me some hints on why that happened.

Update: minor edits on grammar

Re: Hire-to-fire at Amazon India?

#203

Post by nobleach »

leros wrote: post #171

I work at a company that hires developers out of Amazon. We joke about having to deprogram them, but it's not really a joke. They bring a lot of emotional issues and toxic workplace habits with them. Don't get me wrong, the Amazon engineers are fantastic, but there is clearly something unhealthy going on at Amazon.

I left a place that was full of death-marches. Those old habits really can stick with you. It took me months at my new job where I kept asking myself, "why do I still feel stressed? No one is behind me telling me I have to deliver" Because I was so used to that constant stress, I had begun to place those expectations on myself! What's worse, I was frustrated that no one else was on Slack on Saturday at 11am to look at my PRs... I've come down off of that lately. And it's such a relief.

Re: Hire-to-fire at Amazon India?

#204

Post by ako »

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…

What is really problematic is that from a management perspective they're doing really great: company is growing and extremely valueable, stock price is doing great, revenue and profits are doing great, and bezos is the richest person in the world.

Management has zero incentive to change any of problems you signal, and probably don't see them as an issue. Probably the opposite, they see this as a winning system, and who can blaim them. AWS practices are often used as examples of best practices: you build it, you run it, 2 pizza teams, api first, etc. Survivorship bias and all, the probably regard the other characterestics of the current system as best practices as well.

Re: Hire-to-fire at Amazon India?

#207

Post by lumost »

papito wrote: post #90
lucasyvas wrote: post #63

Earlier quoted context omitted.

Yeah there's no way I'd put up with this. Trillion dollar company and still operating like it's amateur hour on many teams it seems.

American capitalism is built on employee heroics, but at least you can get the AWS stamp on your resie, which, let's be honest, will make you the "it" girl of job hunting.

This works when the company is hot, but eventually it's not. When the last time you saw HP, or IBM positively on a resume?

Big companies breed big company problems that can leave engineers poorly equipped for the rapid delivery world of startups/scaleups.

Re: Hire-to-fire at Amazon India?

#208

Post by [deleted] »

exikyut wrote: post #169
amazon_throw wrote: post #166

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…

> steer people clear of it from inside What's really needed here is a way to maintain super-scale in a way that is, shall we say, "eventually morally consistent". Applying selection theory, if you create a pocket of badness wrapped in a function that reliably extracts all the good out of it... well all you'll be left with is a local maximum of even more suffering. Yeow. Of course, designing and maintaining such socia…

[deleted]

Re: Hire-to-fire at Amazon India?

#209

Post by kablow »

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…

I'm in non-AWS and things aren't any better here. It is very much dependent on the manager and team, and I've been optimistic (~3 years now), but it gets harder as time goes on.

> I'm just not 100% sure about the whole PIP scene. Our service was extremely critical and we were extremely understaffed. So I don't think it applied to anyone in our org 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.

Our team is over-worked and has a large ticket queue, constant sev-2 pages, understaffed, etc. - and yet they still PIP'd (and then fired) someone last year who didn't deserve it IMO.

Re: Hire-to-fire at Amazon India?

#210

Post by hibikir »

sreque wrote: post #109
zorked wrote: post #82

Earlier quoted context omitted.

For very, very popular services, a second of being live will exercise more code paths and edge cases than even the most dedicated testing team could ever dream of. We hear a hell of a lot about testing but the most fundamental piece of software quality nowadays is the release strategy: running on tee'd live production traffic, canarying, metrics and alerting, quick roll backs, etc.

It's a very short-sighted view on testing, although I'm not surprised SREs would say it. The biggest problem with software deployment is that it is owned and managed by people who have no vested interest in developer productivity, including devops engineers. A major goal of any org should be developer productivity; otherwise you are just hemorrhaging money and talent. When I say developer productivity, I mean: How co…

If the release/rollback process is fast enough, and your detection of anomalies is fast enough, you can still have great productivity, and few relevant outages, when testing in production. Hell, there are situations where testing outside of production is never going to cut it, as generation of sufficient load of the right shape would take you a whole lot more of engineering time than the consequences of failure.

That said, the tradeoffs are different for different companies, and different services in the same company: Within the same team at $large_company, I owned code where testing in production, via deployments and an amazing feature flag system, was better than unit tests, while there were other areas where the build system would dedicate many CPU-hours to testing before any release. To be able to have that flexibility though, you need to know your systems, know your problems, and have great tooling for both testing in production and extremely parallelized test suites. Small and medium sized companies might not have either alternative, and we had both!

So what I'd say is that any general rule on what should be the primary means of testing code correctness is going to not lead to optimal productivity, and even more so if you don't have top quality of tooling across every possible dimension. It's perfectly OK to argue about specific examples, but without judgement of this kinds of things without having the entire story of what's there is just hubris.

Post reply on HN