Live data from Hacker News

Laying myself off from Amazon

daniel.do

91–100 of 374 posts

Re: Laying myself off from Amazon

#91
post #22

Earlier quoted context omitted.

A lot of internal teams don't use the AWS software for various reasons. So like, CodePipeline might be great, but there's an internal analogue (I'm not sure the detail I can go into here) that is awful that a lot of teams use. There's been an internal movement to try to get all teams onto AWS services, but it's incredibly slow moving and there's no timeline that I know of.

Oh man, we disagree! I miss Pipelines (the internal version of CodePipeline). Having worked at startups and now at Google, that tool is honestly best in class. FWIW, I don't miss Quilt, or VersionSets, or Apollo, or Hydra, or TOD, or NAWS Pipelines bridge. But Pipelines itself, brining all of those tools together is amazing!

I was referring to Apollo specifically, since we're naming things.

Re: Laying myself off from Amazon

#92
post #62

Earlier quoted context omitted.

You should have just switched teams. Amazon has amazing teams working on deep technology, they also have huge systems with technical debt and stress. People dont realize how different it can be inside the company.

How can you tell ahead of time if the team you're switching to has it any better?

Find out what they drink for "Team alcohol evenings."

Whiskey team? Ok, probably somewhat stressful but doable. Wine team? Plush and cushy, with a line of people who want to be on that team out the door. Vodka team? Oh hell no. Etc.

... I'm kidding. Sort of. But not entirely.

Re: Laying myself off from Amazon

#93

Earlier quoted context omitted.

it is when the focus is on having 100% coverage and not on test quality. When 100% becomes the metric it tends to get gamed pretty heavily with tests that have such a huge amount of mocks as to make the tests useless, or doing something to make it hit a branch, but ignoring actually verifying it cause that branch is just a log statement.

I seriously doubt it is actually 100%... let's verify that number.

When I was at Amazon, the general consensus was 90-95% but not higher. We also excluded all of our Java Spring/Guice configs.

Re: Laying myself off from Amazon

#94
post #63

Earlier quoted context omitted.

I believe you also need approvals from your current manager(s) to switch teams?

Nope no approval required

that can't be right (but i have no idea). In the new group, nobody has any desire to at least do a reference check with the previous group? That would be the first thing as a hiring manager i would try to check for, say "this person is a d-bag that the entire group hated, and we were about to pip him/her anyway"? That would be kind of an equivalent of an approval, even if there is no formal approval.

Re: Laying myself off from Amazon

#95

My experience has been similar at other large companies (MSFT, Google). My advice is to look for founder-led teams (not companies). If there are plenty of founders still on the team, they will likely care a lot about the product and code and hold everyone to high standards which make the work easier in the long run. On the other hand when I've been on teams where all the original founders left, it's been a constant s…

> My experience has been similar at other large companies (MSFT, Google).

I would expect Google to have better engineering discipline than Amazon or Meta.

Re: Laying myself off from Amazon

#96

Writing tests is dysfunctional? Funny, I thought that was part of the job.

it is when the focus is on having 100% coverage and not on test quality. When 100% becomes the metric it tends to get gamed pretty heavily with tests that have such a huge amount of mocks as to make the tests useless, or doing something to make it hit a branch, but ignoring actually verifying it cause that branch is just a log statement.

I work closely with the CR-time coverage/enforcement tool. The tool expects 70% new line coverage. The number was chosen arbitrarily, but individual teams/managers can choose to avoid the rule or set a different threshold.

It's not ridiculous to expect some, *configurable*, amount of test coverage for newly generated code, is it?

Re: Laying myself off from Amazon

#97

Worked for AWS for just under a year and a half; this mirrors my experience exactly. Poorly designed, failure-prone, brittle internal tooling was a time and energy sink to the point where even the most trivial deployment change was a nail-biter. Automated tooling and tests that were ostensibly created to make life easier were the number one pain point and constantly failed in obscure ways that required cutting ticket…

You are pretty much validating that Amazon is a 2-year company, as reflected in their vesting schedule.

Re: Laying myself off from Amazon

#98

Why does anyone work there?

Former Amazonian here. The learning is unmatched. I've been in different FAANGs but the way that Amazon pushes one to learn and challenge the status quo is unthinkable. I never saw "no, you can't do that, that system/business/area is sacred". Everything is up for grabs all the time. While there are pathological side effects to this (AWS promotion-per-launch, constantly battle for scope), the amount of knowledge one can gain in different areas from world-class people is pretty incredible. One of my systems at Amazon had more traffic in one day than my system at another FAANG had in 5 years. Working on a system that needs to support 5, 6, 7 MILLION TPs to perform complex operations was a great lesson for me.

Re: Laying myself off from Amazon

#99

> This is not counting the weeks where I was “on call” and forced to drop all of this to work on a backlog of DevOps related issues. I want to say sorry at the beginning if I misread what the author (you?) intended when you wrote this. And I'm coming at this from someone who is not a developer and who, compared to the lofty Software Engineer salaries in this industry, feels underpaid and underappreciated for doing th…

How, pray tell, is someone utterly unfamiliar with a code base supposed to be able to deal with unforeseen issues in production for that service?

(Worse, the incentives for improvements to production quality, and thus on-call quality, are utterly mis-aligned.)

Ironically, I say this as someone presently on-call for a bunch of stuff for which I am utterly unfamiliar with the code base of, and have no time to become familiar with. It's going predictably badly.

Re: Laying myself off from Amazon

#100

Earlier quoted context omitted.

I seriously doubt it is actually 100%... let's verify that number.

When I was at Amazon, the general consensus was 90-95% but not higher. We also excluded all of our Java Spring/Guice configs.

Just what I thought, thanks for the confirmation. HN loves to take a number and just run with it, without verifying anything.
Post reply on HN