Live data from Hacker News

Amazon Pip Horror Story

linkedin.com

311–320 of 771 posts

Re: Amazon Pip Horror Story

#311

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…

> 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.

This sounds like a lie people tell themselves after being PIP’d.

Engineers have an average tenure of 1.8 years. You can’t guarantee you’ll hold together anything. No manager PIPs someone for just being TOO good. It’s already difficult enough to find competent people.

Contrary to some other comments, the folks I’ve seen PIP’d did have performance issues. And I doubt they were hired to be fired. Teams are consistently understaffed and fighting for head count is a blood sport.

During review, PIP candidates come from all managers under a section of an org. There could be 3 from one team and 0 from another. The incentive is then to hire people who are actually good and defend your team’s performance.

Engineers lack visibility into cross team performance and this leads to thinking this system works differently.

Re: Amazon Pip Horror Story

#312
post #205

Earlier quoted context omitted.

Don’t sweat it; it might be healthy. I have made it a feature of my life that I don’t actually care about work and will not be changing it. It turned out that I’d spent at least 20 years being tricked into caring for things which ultimately someone else leveraged most of the benefit for with measly returns by proportion on that investment of time back to me. Never a thank you, always difficult to extract any entitlem…

But your life is spent at work, so if you don't care, your life is spent doing something you don't care about.

Not much of my life is spent at work. I spent the last 10 years optimising the ROI from work down to a suitable compromise of time vs money.

Re: Amazon Pip Horror Story

#314
post #21

How it started - https://i.imgur.com/7Cyia1U.jpeg How it is going - https://archive.fo/pdYHy#selection-525.105-525.423

The second post in your second link is shocking too: > One night, when I was a dev manager at Amazon, another dev manager in Seattle sent me a 20-page design document at 11:30 pm and told me that he wanted me to get him feedback by 5:30 am the next day. How fucking rude is that? It’s indicative of an absolutely staggering level of toxicity. Honestly, what a waste. Imagine how much better Amazon could be if they didn’…

So at 9am the next morning, you send a reply that you were sleeping?

Re: Amazon Pip Horror Story

#315
Who in their right mind PIPs a yearling? You've barely introduced them to the real world and they're far cheaper than your seasoned contributors.

As an aside, I don't see much horror in this story - this happens in many industries and is especially prevalent in companies that try to cull their lowest performers. The only sad part (and maybe illegal) is that it appears to be retaliation for requesting a transfer.

To the engineer who posted this on LinkedIn, producing three-fourths of your teams code shouldn't be a metric you use to measure yourself. Communication with the computer is perhaps 20% of your job - communication with your coworkers/customers is the more important 80%.

Re: Amazon Pip Horror Story

#316
post #111

Earlier quoted context omitted.

You may/may not learn, but living in situations like the OP was put in is horrible. Every day feels like hell, and if you burn out it may take years to recover.

This is my personal experience, which is why I'd advise people not to go through with the above thought experiment. Then again, I keep interviewing people with 5-10 years of experience, who will go something like this: > How would you manage a server? (leaving out a ton of context about what it means to "manage a server") > Very easy, SSH connection is very fast, reliable, ... > Awesome, love me some SSH, how about 5…

Whether someone is in a rut or not is a separate issue than whether they've worked with terraform. The key here isn't what technology they've used, it's a mindset towards automation.

I recently came off a project that was technically using "GitOps" but where every deployment involved copying and pasting dozens of files across 3 or 4 repos, and the whole thing was very error prone, and if you didn't change exactly the right things your service would just silently fail to deploy, or be unreachable, with zero feedback.

I've worked at a company with a bespoke CI/CD system hacked together with PHP scripts and Jenkins servers, but where every single process was ruthlessly automated, reversible, with multiple layers of fallback, failure recovery, garrulous feedback, and built-in approvals that you could automate, or if you didn't remember, you'd get a helpful reminder in email and a link to a page to fill in the required information. People could, and did, know how to do a deployment on it their first or second day.

Guess which one was more pleasant to deploy with?

It's the automation mindset that's important. You can find people with the right mindset who haven't had a chance yet to play with ansible or terraform, and you can find people who manage to create nightmarish complexities of manual processes out of ansible and terraform. Unfortunately, I haven't yet found this to correlate much with years of experience.

Re: Amazon Pip Horror Story

#317
post #267

Earlier quoted context omitted.

You can care about your career and your self improvement while still maintaining healthy boundaries around the mental effort expended for your job. We’re in it for a long time but jobs come and go

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.

I agree, and I still don’t have an answer for this dilemma. I don’t know if I’m the problem, or if it is the structure of our society.. In the meantime the only thing that I know is that I have to choose between not caring and feeling like I’m wasting most of my day, and caring with the potential abuse of an employer

Re: Amazon Pip Horror Story

#318

Earlier quoted context omitted.

I would expect him to not have worked anywhere longer than 4 months considering he just graduated and those were internships

The Full stack developer and ML engineer seem like full positions, considering he listed internships specifically in his prior experience as explicit internships. Also he has a background in bio, and managed to land a full stack and ML engineer positions, implying he is self taught, and therefore should be already fairly intelligent...but he decided to go get his MS in CS, without even doing any research project and…

I don't have an MSc (just something similar) but I have no idea what GTA and GRA means in this context. Also none of my CS BSc+MSc friends ever mentioned a research project (or do you mean the thesis?) Also I haven't seen where the person in the original post was studying, but this might be kinda different per country?

Re: Amazon Pip Horror Story

#319
post #139

This comment killed me : Will Ye Will Ye Engineering @ Cohere (cohere.io) 5mo Back when I worked at Amazon as a software engineer, the CRAZIEST thing happened to me. Here’s the story… I was working from home with my girlfriend (at the time), when suddenly I get an urgent ping from my coworker: “Our service is experiencing a SEV 2! We need all hands on deck!” Uh oh, our team’s application has gone down! However, as I…

You had me at first, haha.

Re: Amazon Pip Horror Story

#320
post #263

Earlier quoted context omitted.

> I can sit there as a project is falling over the edge of a cliff with total inner peace. This is what I'm (slowly) learning as well, even though I'm not entirely sure I want to. Working on projects where you care but almost nobody else does does that to you, but I'm afraid I won't be able to make it back to a position where I can care for projects.

What I’ve found is that you can care about things like craftsmanship, problem solving, and quality while not being bothered by the day to day short term project level thinking.

The problem is that writing good code requires more time than writing shitty one.. and if there is a lot of external pressure to finish the project, it’s quite difficult for me to stay focused on quality
Post reply on HN