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

151–160 of 589 posts

Re: Hire-to-fire at Amazon India?

#151

Post by oblio »

nuclearnice1 wrote: post #73
HenryKissinger wrote: post #6

What does Amazon need thousands of engineers for, exactly? Amazon.com is a fine website. It is finished. It is complete , perfect as it is. The website could remain the exact same for the next ten decades, with minor adjustments to the product menus to reflect new products, and it would serve its purpose perfectly without risking being dethroned by competitors. Why do millions of lines of code need to be written each…

Well this controversial opinion sure got pounded down. > The British cracked the German naval codes with no more mathematicians than can sit at a table. The Government Code and Cipher School employed almost 10k people during ww2.

Yeah, but you couldn't fit all those 10k people in a Hollywood movie.

Re: Hire-to-fire at Amazon India?

#152

Post by ixaxaar »

throwaway2037 wrote: post #144
ixaxaar wrote: post #116

Earlier quoted context omitted.

> But in India, jobs are careers for life, and your employer is part of your personal brand. In the last decade, I might have very rarely seen a resume with more than say 10 years of experience at a single place. The average would be somewhere in the range of 1-4 years.

I agree 100%. When we hire in or from India, the turnover on their CVs is incredible. Some people only stay one year, and then leave. How much impact can you really have after one year? It's bizarre, but I try very hard not to discriminate and just chalk it up to "local working culture".

An average software engineer can traverse the entire SDLC of a major revision of a product in less than a year. Perhaps in big tech that would be ~2 years if not less.

Re: Hire-to-fire at Amazon India?

#153

Post by throwaway2037 »

whakim wrote: post #110
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…

This is a very myopic way of looking at things. There are plenty of family businesses that aren't only interested in capturing an ever greater share of profits.

Yes absolutely -- in many places, like Taiwan, Korea, Japan, Germany, Austria, France, Netherlands, etc.

Re: Hire-to-fire at Amazon India?

#155

Post by sreque »

wpietri wrote: post #120
sreque wrote: post #109

Earlier quoted context omitted.

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…

Yeah, I really appreciate excellent rollout strategies, although I suspect a lot of them are more developed out of self defense by SRE teams. I see it as a series of safety nets: I'm still going to write tests for my code so that I don't have far to fall if I make a mistake. But I also want a safe rollout so if I miss the first net I don't splatter on the pavement. And I totally agree with out about developer product…

Agreed. I was an SRE for over a year and the philosophy is that anything that is shipped can be broken. SRE is all about detecting, limiting, and mitigating damage. I think this is the right philosophy for SREs but should not be the total picture in the org.

I am also agreed in that I anecdotally often see a disregard for automated testing. I am still trying to understand how to eliminate this tendency. I know that in every software project I've had a major hand in building, I've helped ensure automated testing, with a heavy emphasis on unit testing, become a major part of team culture, and I've always felt the tests more than paid for themselves over time, even in the relative short-term.

Re: Hire-to-fire at Amazon India?

#156

Post by mattacular »

Amazon has had this reputation for as long as I can remember. Sounds like they treat their employees like shit at every level and in every country. When I was looking for a new job it was not even a consideration to apply.

The only defense of the company seems to be "well maybe you'll get lucky and work for one of the good managers who will treat you with a modicum of respect and they'll stay good as long as you're there" - not exactly the dice roll I'd aim for.

Re: Hire-to-fire at Amazon India?

#157

Post by notacoward »

zorked wrote: post #82
wpietri wrote: post #54

Earlier quoted context omitted.

> AWS is pretty reliable for the most part so I am pretty surprise that the code quality is that bad. I'm not totally surprised because of two factors: very stable product definitions and lots and lots of users. A number of years back, I was talking with people at a famous and popular site with a broad audience. I asked them how much unit testing they did. They said that particular isolated pieces sometimes had tests…

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.

That's an overly general statement. Can you do that for front-end code that stores all of its state elsewhere? Sure. Can you do it for a storage system? Absolutely freaking not. If you introduce a bug that loses or corrupts data, there's no going back. You will have committed the worst sin that somebody in that specialty can commit. Better to test as much as you can, at every level. Other kinds of code are often somewhere in between.

Also, even if it's true that being live will exercise more edge cases etc., it's a terrible way to test changes during early development. For one thing, there's no isolation. It becomes harder to determine which of several recent changes caused a problem, and that burden unfairly falls on the person who's on call instead of the person who introduced the error. And decent unit/functional tests allow "dumb" mistakes (we all make them) to be caught earlier than waiting in a deploy queue, allowing faster iteration. "Most recent change probably caused the problem" is a very useful heuristic, but the more low-assurance changes you allow in the less useful it becomes.

To drive the point home even further: I have found data-loss bugs in focused testing that didn't show up in prod for months. I know because in many cases I was able to add logging for the preconditions when I fixed the bug. No logs for months, then some completely unrelated and completely valid change by another engineer tickles the preconditions and BAM. That would have been an absolute nightmare for other members of my team, possibly even after I was gone. Based on those experiences, I will never believe that foregoing systematic early tests can be valid. The systems most of us work on are too complex for that.

"Test in prod" only works for trivial code and/or trivial teams. Not in the grown-up world.

Re: Hire-to-fire at Amazon India?

#158

Post by midhhhthrow »

I can’t possibly imagine why anyone would ever go work at Amazon. How low would your prospects have to sink in order to make someone do that to themselves? I suppose if you’re completely homeless and in danger of starvation. Personally, I’d rather eat the weeds that form on the sidewalk or probably go dumpster diving. That’s much more dignified than working at amazon.

Just imagine the damage you’re doing to your resume. How do you explain having worked at the worst company in the world?

Re: Hire-to-fire at Amazon India?

#159

Post by muststopmyths »

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…

>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 over and above any imagined positive effects.

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

I mean, early Amazon must have hired a lot of ex-Microsofties with stack-ranking PTSD, being based in the same area. You would think they would know better.

It seems like the more employees you have under you, the less you see them as human beings instead of inputs and outputs into a Rube Goldbergian machine you are trying to keep running.

Re: Hire-to-fire at Amazon India?

#160

Post by hardwaresofton »

kottapar wrote: post #126
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…

> 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. wow, honestly this is surprising. For me as an end customer I was always impressed with the way the services are engineered. Kudos to people like you for making this happen. But then I was also under the impression that AWS h…

> Wouldn't interim patch-ups cause stability issues in the long term?

No matter what people tell you or put on their marketing blog, it feels like this is the state of play for 99% of software teams. The only time it doesn't end up like this is when you leave time up front to pay down technical debt (like Intel's tick-tock model), and almost no one does that.

Post reply on HN