Live data from Hacker News

Amazon Pip Horror Story

linkedin.com

541–550 of 771 posts

Re: Amazon Pip Horror Story

#541
post #191

Earlier quoted context omitted.

It’s how you fire people in tech companies. You put them on a PiP, give them some tasks to do and then fire them when they don’t deliver. Obviously nobody survives the PiP because for an engineer not on a pip, taking 9 weeks on an 8 week project is pretty good, but on a pip 9 weeks for an 8 week project is a failure to deliver and you’re out. Obviously this is evil bullshit, but I’ve been in this industry for a very…

That's not how you fire people in tech companies. Not all tech companies are Faang/American. I've been working in several "tech companies" in Europe and it was not a thing. Let's not normalise this awful, inhuman process like there is no other alternative.

This is certanly a thing in European companies as well, especially since the employment law demands more paper trail for each firing.

It's just named differently and adds more paperwork (more performance warnings, "talks" with your manager, etc.) before you get terminated.

Re: Amazon Pip Horror Story

#542
post #359

I've been an Amazon SDE and an Amazon SDM. I enjoyed my time as an SDE, luckily free from these horror stories. After having been an SDM, I understand how these horror stories can form. Generally, Amazon has two minds about performance management. In written documentation, it's all about whether your reports meet the role guidelines. The written documentation is solid. They share how to evaluate people objectively an…

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

Thank you Jack Welch (the guy who drove this insane idea in the first place). Hope it’s warm enough for you down there.

Re: Amazon Pip Horror Story

#543

Earlier quoted context omitted.

> Shitty managers like you That's rude and against HN guidelines. Don't make this personal. I'm not attacking you. You think I'm taking an extreme position ("Managers should measure developers by their LOC"), which I am not. Are you actually taking the opposite extreme position, that a developer's LOC tells you absolutely nothing about their productivity? That there's not even a correlation or a hint of a connection,…

> Don't make this personal. I'm not attacking you. I am sorry for the adjective, what I meant was "extremely incompetent". That is still harsh, but hopefully conveys my opinion regarding your grasp of management in a more objective manner. It's not meant to be personal, I would say the same thing about someone attempting to use the OCaml compiler to run a Python program, and telling me that's how they do things at th…

> I am sorry for the adjective, what I meant was "extremely incompetent"

LOL. Oh, you!

> I am taking the slightly less strong stance that a developer's LOC tells you no more about their productivity than any other random metric, e.g. the number of lines they type into Slack, the number of bugs they file in the internal bugtracker, or how many geek jokes they made that month.

Reductio ad absurdum. A new feature is expressed quite literally as code in a repository. All other things equal (i.e., if one person isn't busy with design docs, or mentoring teammates, etc) if one developer cranks out 5K lines of solid (not bloated, well-tested, etc) code in a quarter, while the other person eked out 150 lines in 3 months, that's an indicator of a potential productivity issue. How can one argue it's not even a hint of a possible problem?

> Is this person engaging at all with their teammates?

No

> Have they been active on design docs or architecture?

No

> Have they been responding to queries from sales engineers?

No

> Have they been maybe going through a big life change?

Sometimes yes. And when I find out that's why they stopped submitting code, I tell them to take the time they need to take care of themselves and their family. And we offload their work to someone else for a few weeks or however long until they're back.

> That is the crux of why I think manager who use LOC as a metric are incompetent managers. They have and project to others a simplistic view of "developer in, code out".

I wonder if maybe you had a terrible manager who was like this. Because you're interpreting my statements in the most cartoonish way possible, like I'm here saying "more code good developer, less code bad developer."

This thread started with someone saying LOC tells you nothing. I claim it tells you something, and then it's the job of the eng manager to figure out what. I totally agree that a shitty manager who literally connects LOC to productivity, is doing it wrong. But again: a good manager should be looking at the code from their team, and making sure the amount and complexity matches their expectation of what that person is supposed to be delivering.

Re: Amazon Pip Horror Story

#544
post #391
post #293

Earlier quoted context omitted.

> —— > I now work at Cohere (cohere.io)! Give it a spin Recruiter/spammer

Author here. I’m a software engineer who likes to have fun on LinkedIn, not a recruiter/spammer. And yes, I was actually an SDE at Amazon!

Good to see that the Duke meme god is still meming

Re: Amazon Pip Horror Story

#545
post #307

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”…

At least to me, of the best things about this attitude is that the working culture starts to matter a lot when you search for jobs. That's what you care about. You look for places where relationship building is important and people try to get along and support each other. Other stuff starts to matter less. Lots of places basically put so much pressure on you to deliver that being a decent human being becomes impossible.

If my choice is between working at a boring job where I can support my colleagues, and an exciting job with cool tech where people are having mental breakdowns and nobody has the mental space to support them, I'll take the boring job where people don't care about stupid directives and dealines from above.

Re: Amazon Pip Horror Story

#546
post #359

I've been an Amazon SDE and an Amazon SDM. I enjoyed my time as an SDE, luckily free from these horror stories. After having been an SDM, I understand how these horror stories can form. Generally, Amazon has two minds about performance management. In written documentation, it's all about whether your reports meet the role guidelines. The written documentation is solid. They share how to evaluate people objectively an…

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

No post body was provided.

Re: Amazon Pip Horror Story

#547
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…

> the statistical truth that the worst 10% probably are negative value employees.

Why is this a statistical truth? In a large, Gaussian distributed population MAYBE this is true (but hiring isn’t random, is it?). But the thresholds are not applied to large populations anywhere I’ve worked. It’s pressure applied to management at all levels.

Re: Amazon Pip Horror Story

#548

Earlier quoted context omitted.

Heh, as a salaried dev who gets 1700 - 1800 Euros per month (so around 90 Euros per day) after taxes in Latvia, some of the numbers in this thread are pretty sobering, even if you take the costs of being self employed or taxes into account. If you take the run of the mill Java dev salary here, the net value is somewhere between 900 - 3000 Euros or so, across all levels of seniority [1]. Really makes one consider the…

There are some great remote work opportunities these days. It might be worth starting to look at other European countries who are hiring. Take Ireland for example. You're not going to be making US level money but I'd say you could easily double what you're making now and there's the potential to go much higher than that.

Yep, and it seems like the pandemic largely showed that there are quite a few jobs out there that can be done remotely with decent success in many environments.

Well, at least as long as the culture fit is there etc., admittedly remote isn't for everyone, but on the flip side, geography/commute being less of an issue for the remainder of people is great!

Re: Amazon Pip Horror Story

#549

Earlier quoted context omitted.

The issue with Amazon is that due to its size, working on a team is essentially like working for a separate company. If you are moving across big orgs, you are just a blip in the system should something like this come up. And just like a group of startups, some are going to be run worse than others. Additionally, because of the internal transfer policy and teams frequently switching out members, a lot of work is desi…

> If you are a talented software engineer, not just a developer and generally know how to navigate around managers, you can hit senior engineer or manager levels quite easily, How do you “navigate” your way around an 11:30 PM email that contains a 5:30 AM deadline, as mentioned elsewhere in this thread?

Pre-declare available working hours, and adhere to them.

I have a cronjob that signs out of {slack, email, zoom, ...} at a particular time of day, my work accounts aren't attached to my personal devices, and i respond promptly to communication during working hours. I genuinely don't see work-related comms when i'm not working, and my work availability is in my slack profile, my internal email signature, and in my outlook calendar.

Re: Amazon Pip Horror Story

#550

Earlier quoted context omitted.

> If you are that smart to have a background in bio, and land the jobs that he did, your career would look very different. Is that really so impressive? Bio people do a lot of coding, and good dev practices can be learned on the job. ML is probably also something he played with during his studies. Full stack + some ML experience is probably enough for a junior ML engineer.

Sure but then having those jobs for 3 months at a time still looks shady

During his studies and very early career? That's completely normal and I don't understand why more people don't do it.

Studies don't give you any idea of what a job is actually like. They also don't give you a reliable indication that you'll like a field. Choosing bio out of high school, then moving to CS for any reason, then trying a few jobs using these skills is a normal and healthy way of searching for a job he really likes.

Post reply on HN