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

Amazon Pip Horror Story

linkedin.com

Post reply on HN
Print view View original

511–520 of 771 posts

Re: Amazon Pip Horror Story

#511

Post by pseudalopex »

Jasp3r wrote: post #134
nickm12 wrote: post #60

I feel for the guy—taking the post at face value, it sounds like he had a shitty team and a shitty manager. At the same time, this post does not make me want to hire him and in fact quite the opposite. He seems to be fairly junior, but even at that level I cringe at measuring ones self in terms of lines of code written (though lines of code deleted is a metric I can get behind).

His job history agrees with you. It has been less than 2 years since he graduated, in which he has held 4 jobs. 3 months at his first job, then 4 months, 5 months and 10 months at Amazon. I would not take his given statement at face value.

His profile said he graduated in 2021. He joined Amazon in May 2021. 5 months was a teaching assistant at his university. 4 months was the right months for a summer internship.

Re: Amazon Pip Horror Story

#512

Post by shepherdjerred »

cvhashim wrote: post #497
shepherdjerred wrote: post #477

This exact thing happened to me when I tried to transfer internally.

What was the result ?

I applied to AWS Lambda and two days later my manager of two months (who was formerly my skip manager. My manager(s) quit and they couldn't find a replacement for several months, so my team shifted up the report chain.) told me that I had been under performing for the last year and likely put me in Focus [0] which is the precursor to being put in Pivot aka PIP. You can't transfer teams internally when you're in Focus, so I was stuck there.

My team's senior engineer he told me that I was nowhere near under performing during the last org-wide performance review. I received great Forte feedback that year. All of the teammates that I had talked to, and my former manager who was now at another AWS org, told me the situation seemed suspicious especially due to the timing.

I got out as fast as I could after my manager said that I was under performing. I applied to a handful jobs, interviewed, received an offer, and gave my two weeks notice all within 3 weeks of the start of events. Now I'm at RStudio [1] which pays about the same as AWS but has a significantly better culture while still being able to work on interesting projects.

That experience was pretty terrible. My team and former managers had all given me consistently positive feedback. There was always something I could improve, but overall I was a good engineer. My interactions with this manager still make me question if I am competent which isn't the best feeling.

I had a fairly positive experience at AWS up until this chain of events.

[0] https://www.theverge.com/2021/7/9/22570579/amazon-performanc...

[1] https://www.rstudio.com/

Re: Amazon Pip Horror Story

#513

Post by lostdog »

np- wrote: post #307
DarylZero wrote: post #290

Earlier quoted context omitted.

That's not what I'm talking about. Your working life is where you act on the world outside of yourself. If you don't care about what you're doing, you're spending most of your influence on the world on something you don't care about.

Why not? You can care about delivering beautiful code. You can care about ensuring the workplace is a pleasant place to work for all. You can care about your relationships you’re building. You may even be a huge fan of the product you’re building. That doesn’t mean you need to shit a brick when someone comes running in with their hair on fire—it’s not a binary proposition. Caring about things can be done “a la carte”…

Exactly. You can even care about your product and its users, but not care that it went down for a couple hours last tuesday or launched 4 weeks later than a made-up deadline.

Re: Amazon Pip Horror Story

#514

Post by tsol »

bathtub365 wrote: post #403
zelos wrote: post #394

Earlier quoted context omitted.

I kind of see that, but it completely ignores the cost of hiring (financial and in lost productivity in the team that has to onboard the new hire) and the loss of knowledge and experience from firing as well.

That’s why you hire to fire. Then your shortest tenure employee is the one you know you’ll be terminating and minimal knowledge is lost. The only downside is that it’s disgusting, soulless behaviour.

Also a huge waste of time, money, and other resources.

Re: Amazon Pip Horror Story

#515

Post by AitchEmArsey »

alistairSH wrote: post #450
Fiahil wrote: post #434

Earlier quoted context omitted.

Hold on, 700€ x 215 days worked (you don't count vacation time when freelance) = 150 500. Now, give it half to the taxman, and you're left with 75 250€ / year. And that's without the expenses, extra healthcare coverage, insurance etc. So pretty average when you considering that junior developer salaries are within this reach in EU capitals.

215 / 5 = 43 weeks of work. 9 weeks vacation? I used 4 weeks, and by my experience that's generous (not talking about paid leave - all the freelancers I know are workaholics and don't take much leave, but maybe that's a US thing). 5*48 = 240 days, which works out to around 84000 EUR. Or 120,000 EUR - 30%. Regardless, 700 EUR/day seems in the ball-park for a generic all-around developer.

Agreed. Some UK numbers for reference:

£500/day is the absolute minimum for developer/DevOps outside London, £600/day much more common and including the cheap end for London. Senior is more often £800/day. You don't see values above that advertised, but people do obviously negotiate higher for specialist work; I have seen a mainframe developer charging £1500/day (on the low end of his range). Anything higher than that has always been a large consultancy rather than a freelancer. In my specialist niche I'd be asking for £1500/day top-end, expecting £800-1200 with negotiation depending on flexibility.

Re: Amazon Pip Horror Story

#516

Post by dot1x »

melzarei wrote: post #383
flr03 wrote: post #189

This echoed so much what my girlfriend is experiencing at Amazon (London) that it is scary. She was not put on pip but one of her co-worker was last week. According to her the guy is competent and hard working. Everything about the toxic culture, the (unpaid) on call every 4 weeks, management doesn't care about estimations they just set you impossible deadlines, lots of turnover in the team, custom, unstable not docu…

Oncall is paid in Amazon Europe

Amazon EU here. Not it's not.

Re: Amazon Pip Horror Story

#517

Post by khazhoux »

kstrauser wrote: post #485
khazhoux wrote: post #90

Earlier quoted context omitted.

It’s absolutely a useful metric. I have managed many developers who insist their low LOC is in no way indicative of their productivity. They’ll say others are padding their code with comments, or writing bloated inefficient code, or that they themselves were tackling very tough problems that result in small (but tricky) fixes. Yes, we’ve all encountered that killer deadlock or memory leak deep in the runtime that tak…

That’s such a horrible metric. I try to mentor my colleagues to solve problems using what’s already there. If they take a week to launch a feature without increasing the code size, I’m incredibly proud of them. One of my own major wins last year was a big update to a project to strip out legacy cruft and tech debt, and scrapped maybe 5,000 LOC. The end result was smaller, faster, easier to test, and more robust. I co…

I agree with everything you say. I will congratulate any team member who submits a -2000 LOC commit, and at my last gig I used to run a twice-yearly code-reduction competition.

My point is rather this, and I suppose I'm not being clear: If a developer only ever submits tiny amounts of code --and they have no other responsibilities like design docs, mentoring team members, etc-- that's an indicator of a performance problem that should be looked into and discussed with the engineer in case there's an issue.

I'm in no way suggesting that, e.g., the developer who submitted 12K LOC last year is doing a "better" job than their teammate who only submitted 11K LOC. I'm talking about that person on the team who only writes 500 lines of new code in an entire year, and they trickle out tiny simple commits ever couple of weeks. Every team that I've taken over as a manager, I find one person like this, who pushes barely any code, and the code they do push is trivial, and they aren't doing anything else either.

People here are somehow suggesting that LOC is so meaningless, that somehow apparently a person can implement a new map routing algorithm in 10 lines, or implement a new 3D rendering engine in 10 lines, or create a new data-ingestion and validation pipeline in 10 lines -- because apparently LOC is a "meaningless" number.

Re: Amazon Pip Horror Story

#518

Post by sangnoir »

matthewowen wrote: post #388
zelos wrote: post #359

Earlier quoted context omitted.

What's the justification for an attrition target? It seems such a weird thing to want your staff to leave.

The devils advocate answer: Statistically, some of your employees probably aren’t good enough to be worth employing. But managers are human, hard conversations are hard, there are lots of incentives to not manage those people out. By having an attrition target and forcing people to cut the bottom 10%, you basically skip over the soft fuzzy human factors keeping people around, and instead fall back to the statistical…

Are managers stack ranked too? If not, and assuming the whole scheme works[1], then steady state is accumulation of bad managers, while they keep firing above-average ICs (that are still in their bottom 10).

1. It doesn't work, obviously because they are not in a closed system. Their policies affect their reputation, which will affect their ability to hire ICs who have to contend with an increasingly higher bar to clear.

Re: Amazon Pip Horror Story

#520

Post by cjbgkagh »

abirch wrote: post #301
praptak wrote: post #250

The pip quota is a HUGE perverse incentive here. Choosing someone to put on pip is hard because it is in manager's best interest to protect their core team from pip. So if someone is too good for your team, you put them on pip. They are going to leave anyway, so putting them on pip does the least damage to your team. The other pathological result is hiring dummies just to put them on pip, again protecting the core te…

This was the way for Microsoft in the late 90's. Hire to fire.

Aka, sacrificial lambs
Post reply on HN