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

Laying myself off from Amazon

daniel.do

Post reply on HN
Print view View original

221–230 of 374 posts

Re: Laying myself off from Amazon

#221

Post by Aeolun »

bb88 wrote: post #78
goostavos wrote: post #56

Earlier quoted context omitted.

I've been on 4 different teams at Amazon (now migrating to a 5th). It depends entirely on the team and as well as your current level. Some do loops just like with external candidates. Others barely require more than a conversation with someone on the team -- though this one is a huge red flag. Teams looking for warm bodies are seldom good teams. Most of the time its somewhere in between. You'll speak with the manager…

I've seen a lot of red flags in my career where managers put people on PIPs -- when in reality it's not a PIP but a personality conflict. And from what I understand at Amazon, it's kind of the same thing, but PIPs have been aggressively weaponized.

Isn’t that what a PIP is? A Personality Improvement Plan?

Re: Laying myself off from Amazon

#222

Post by dimmke »

p0rkbelly wrote: post #186
techsupporter wrote: post #50

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

If your code breaks something, you should fix that code. Who else should? If your system/product/service is down because you have a dependency on something that broke -- well it's up to that team to fix their code.

This is the pat answer Amazon gives to defend this absurd practice, but it breaks down really easily.

>If your code breaks something, you should fix that code. Who else should?

What if it wasn't my code, but code written by someone 3 years ago who quit because most people only work at the company for 2 years? And it's in a part of the codebase I've never touched. That's a much more likely scenario.

Re: Laying myself off from Amazon

#223

Post by 8n4vidtmkvmk »

ChrisMarshallNY wrote: post #112

> but also a job that made me feel more unhappy than any other job I’ve ever had. I can relate. I worked for many years for one "those" companies that is a household name. The pay wasn't outstanding, and the job was not one that gave me much fulfillment, but it was at a marquee brand. My business card opened a lot of doors. When that job finally ended (after almost 27 years), I started looking at working for other co…

it's weird to hate on older generations, particularly when you consider so much of what we use today in terms of algorithms was thought of in the 70s or older. none of that became irrelevant. the only maybe maybe advantage that younger folk have is that they might use newer languages or frameworks, but then when those go out of style and they only have 1 tool in their belt and you've collected dozens over the years... it really won't matter if they're more proficient in one tiny area. but let's be real, the languages and frameworks were never the problem to begin with. its the knowledge and foresight to see where things are going to go wrong which you can only get by years of experience

Re: Laying myself off from Amazon

#224

Post by scubbo »

int_19h wrote: post #201
scubbo wrote: post #110

Earlier quoted context omitted.

Yeah, comparatively, I find Github's process to be bizarre. Why do I have to fork a repo just to propose a change to it? Why does my "Pull Request" (really it's a Push Request, but it's called a Pull Request because of the 2 repo requirement) have to be associated with a remote repo in the first place? (I wouldn't say I love the CR process - making multi-package CRs is definitely flawed, and I had a Sage question ope…

You can do PRs from branches in the same repo on GitHub just fine if you want to. Having them in a separate repo makes more sense because 1) it doesn't require the dev submitting a PR to have anything above and beyond simple read access to the target repo, and 2) there's no concern that someone might depend on WIP branches created in those private forks, so they can be deleted or rebased at will. The reason why it's…

> You can do PRs from branches in the same repo on GitHub just fine if you want to. Having them in a separate repo makes more sense because 1) it doesn't require the dev submitting a PR to have anything above and beyond simple read access to the target repo

Right, that's my point, though - why is there no distinction between "ability to create a real, actual, complete branch on a repo" and "ability to create a 'fake' branch that only exists for the purposes of diffs for a change request"?

For contrast, the flow I was used to inside Amazon was: 1. Clone the repo locally 2. Make my changes locally 3. Run a command that creates a 'fake branch' on the main upstream repo, which is used as the reference for the change. This works even if I don't have push-permissions on the repo (in which case, I can still push my change once it gets approval by clicking a button in the UI, whereupon a service account will push "on my behalf")

Whereas for Github, the process (if you don't have push-permissions) appears to be: 1. Fork the repo to my own Github account 2. Clone that locally (equivalent of 1. above) 3. Make my changes locally (equivalent of 2. above) 4. Push my changes to my own forked repo 5. Run a command (either CLI or UI) that creates a Pull Request from my repo to the target repo

Sure, it's only two extra steps - but I don't see why that friction has to exist in the first place. It gets _much_ worse if your change is open for a while (which will happen to coincide with the case when you don't have push permissions - that is, when you're contributing to code that you don't own), because then you need to resolve rebase locally and push to your fork rather than just being able to update in the UI (Github UI doesn't support rebase-pulls, only merges).

Re: Laying myself off from Amazon

#225

Post by scubbo »

innocentoldguy wrote: post #200
p0rkbelly wrote: post #188

Earlier quoted context omitted.

It's all about the RSUs. That all kicks in after year 2. If you're a lower level maybe you don't feel it as much. But for a high performing L6+ RSUs typically are -- or at least were designed to be -- the majority of your income compared to base pay.

I was an L6 and my RSUs were worth sticking around for a year ago. Not so much today.

I was an L6 and, at the time, my RSUs certainly gave me pause for leaving, but in the end the urgency of my mental health won out. My timescale was dictated by getting my Green Card, not (primarily) by finances.

Re: Laying myself off from Amazon

#226

Post by I_AM_A_SMURF »

p0rkbelly wrote: post #186
techsupporter wrote: post #50

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

If your code breaks something, you should fix that code. Who else should? If your system/product/service is down because you have a dependency on something that broke -- well it's up to that team to fix their code.

Ideally incident handling should "just" be rolling back the broken change. Fixing the problem should be done in the morning with no time pressure, not in the middle of the night half asleep with customers on the other side of the world yelling at you. Of course it's not always that simple, but most of the time that's what on call should be about

Re: Laying myself off from Amazon

#227

Post by mguterl »

nicksf wrote: post #169
wmichelin wrote: post #168

This author sounds insufferable. Tooling sucks? Fix it. It's important to lead with a culture of quality and impact. Wasting 40 hours a month on something broken? It'd literally be faster to stop your feature work, fix that thing, and then go back to your feature work. Be the change you want to see.

Easier said than done. Amazon is a top-down org, where each pod's (aka pizza team) work is planned 12-18 months in advance through their OLR process.

OP1

Re: Laying myself off from Amazon

#228

Post by andrewxdiamond »

yodsanklai wrote: post #95
olladecarne wrote: post #36

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.

Googles engineering culture is much better, but their culture around customers is bottom rung compared to MS and Amazon

Re: Laying myself off from Amazon

#230

Post by lmm »

anyfoo wrote: post #164
Zvez wrote: post #163

Earlier quoted context omitted.

>There's a lot of complexity to be tamed, and in my experience that can be a very enjoyable part of actually engineering In my experience there is almost no correlation between complexity of the project and time needed to do 'non-technical' work. Quite contrary, the most complex things I did as a dev required me to do a lot of coding - to prototype, to experiment, to load testing and so on. And at the same time the e…

I fundamentally disagree with the notion that design and discussion, of often very detailed technical aspects, is "non-technical work" of any kind, or that sitting down and writing code is the only "technical work".

Doing design and discussion without writing code just feels like deliberately hampering yourself. Code is the best language we have for describing things unambiguously! Weeks of plain-English discussion can save you hours of prototyping.
Post reply on HN