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

An Amazon programmer’s perspective (2015)

pastebin.com

Post reply on HN
Print view View original

171–180 of 281 posts

Re: An Amazon programmer’s perspective (2015)

#171

Post by smacktoward »

filoleg wrote: post #116
Barrin92 wrote: post #98

Earlier quoted context omitted.

>How are you proposing to run a complex system that essentially powers a big chunk of the entire internet and can go down any second without on-call? hire more people?

Hire more people to do what? Be on-call? Hiring more people is a great idea for making on-call less stressful, because it allows for much sparser on-call shifts (e.g., one week every 8 months vs. one week every 2 months). But I don't see how hiring more people gets rid of on-call completely. Someone will always have to be on-call. You cannot just hire people who do on-call-only duties and nothing else, you have to be…

According to TFA, programmers at Amazon are required to be on call for a full week at a time. More programmers could mean sparser on call shifts, but it could also mean shorter on call shifts -- i.e. instead of going from one week every two months to one every eight months, go to two or three days every two months.

Being effectively at work 24 hours a day for seven days straight sure sounds like a recipe for burnout to me. As TFA notes, these people aren't doctors, the only thing that happens if a glitch takes two hours to fix rather than one is that Amazon loses some money. Amazon naturally would prefer not to lose that money, but its workers presumably would prefer to be able to sleep too.

Re: An Amazon programmer’s perspective (2015)

#172

Post by majewsky »

rootusrootus wrote: post #123
SamuelAdams wrote: post #91

Earlier quoted context omitted.

Maybe it's just the type of people amazon hires? I've been programming for 5+ years. Know what I'm doing today at 5 pm? Headed over to Lake Michigan with the fiance. Yesterday I went on a 4 mile run. Personally I never check things outside of 8-5 and my employer is A-OK with that. The biggest problem is when people like this article's author get a job and the HR people never make it clear that they may need to have "…

One thing seems to have changed since the OP wrote their post -- managers at AWS are open about the on-call requirement. At least the ones in Portland. They were proud that they owned the product all the way from the code on the back to the customer at the front. So if you didn't want to be responsible for some level of ops, you knew that going in. I didn't move forward to an interview, this was just from a meet-and-…

> They were proud that they owned the product all the way from the code on the back to the customer at the front. So if you didn't want to be responsible for some level of ops, you knew that going in.

There's a huge difference between being responsible for (some level of) ops and literally climbing out of bed when the pager rings. At work, I'm responsible for the operations of the services I develop, which means that I'm doing third level support during normal business hours and I write the playbooks that first/second level support executes. You certainly won't catch me working after 5 PM.

Re: An Amazon programmer’s perspective (2015)

#173

Post by rantwasp »

MattGaiser wrote: post #136
rantwasp wrote: post #118

Earlier quoted context omitted.

yeah no. as someone who has worked at Amazon for 7 years I can tell you that it’s not true across the board and there are good “pockets” where there is respect for people’s boundaries. To add to this, in my time there I worked during the weekend 3 times (i don’t count oncall here). My work day included 8 hours at most. I would get in at around 8AM and leave at 4PM. (optimizing the commute) I started as an SDE 2 by th…

I am sure it is not all of Amazon, but that is where the horror stories are coming from. So Amazon as a whole may not have this culture, but the teams with this culture seem to disproportionately be at Amazon.

so, the bigger an org, the higher the likelihood of stories like this popping up.

also, the incentives and their structure play a part in how this unfolds.

It’s also very curious to me that only a certain type of person runs into situations like these: either they don’t know better or they have accepted the conditioning that work is more important than themselves. it’s sad really.

i think it’s really really important to have a good mentor with a strong set of values to help you navigate the corporate landscape.

i also think it’s important to pull a Ghandi (ie be the change you want to see) as often as possible. for example: one think i would inoculate in young devs is that it’s not acceptable to set meetings earlier than 9am or later than 4pm. meetings during lunch were not accepted. i would be pretty vocal about morons that worked over the weekend because they had some free time. i would also push really hard against management that had their sick little practices to extract more work out of the drones. this mostly worked because i got the job done - but again: you have a voice. you are NOT a machine

Re: An Amazon programmer’s perspective (2015)

#174

Post by jobhunt94110 »

dudul wrote: post #89
Barrin92 wrote: post #80

Earlier quoted context omitted.

>How are critical systems managed otherwise without having to 3x your team (assuming you want 24hr coverage with a 8hr workday)? They typically aren't, you need to hire more people then. In anything defined as critical I would suggest that being well rested is also a requirement rather than having a team of people who are so overworked they develop mental illness.

Doesn't make sense financially. You're gonna triple the size of your team, just to make sure that this one time of the week someone will restart the DB? I would much rather bite the bullet, be on call a week a month or so and use the budget for something else.

You don't need to keep the primary development team as primary oncall 24/7. "Hire people to keep an eye on things off-hours, follow playbooks when necessary, and escalate to the right people if they can't resolve" is a reasonable pattern that folks have done for decades the world over. You get less incentive alignment perhaps, but it really isn't hard to come up with ways to make creating work for another team unappealing.

Re: An Amazon programmer’s perspective (2015)

#175

Post by rantwasp »

ultraluminous wrote: post #157
rantwasp wrote: post #118

Earlier quoted context omitted.

yeah no. as someone who has worked at Amazon for 7 years I can tell you that it’s not true across the board and there are good “pockets” where there is respect for people’s boundaries. To add to this, in my time there I worked during the weekend 3 times (i don’t count oncall here). My work day included 8 hours at most. I would get in at around 8AM and leave at 4PM. (optimizing the commute) I started as an SDE 2 by th…

"in my time there I worked during the weekend 3 times (i don’t count oncall here)" Why wouldn't you count it? Do those days not-count somehow?

i don’t count it as in: i worked more than 3 weekends, but not because i had a choice )

Re: An Amazon programmer’s perspective (2015)

#176

Post by supersimp »

sikim wrote: post #145
w0mbat wrote: post #132

Amazon's 401k plan is terrible when compared to competing companies. I cancelled my Amazon interview the second I saw the terms of it. I had to find the details for myself because the info packet the recruiter sent me, conveniently left out any details except that there was a 401k plan and some matching. Only 50% match, and the maximum match they will pay is 2% of salary. (Competitors match 1:1, high or no limit). Th…

This might be helpful to you http://perks.guide/

Is this accurate? I definitely do a mega backdoor roth and I'm at Amazon.

Re: An Amazon programmer’s perspective (2015)

#177

Post by smacktoward »

jakebellacera wrote: post #69
Barrin92 wrote: post #18

The on call stuff sounds outright dystopian to me, it's not even legal in my country. More places should think about adopting something akin to France's El Khomri law's ( https://en.wikipedia.org/wiki/Right_to_disconnect ) and ensure that every citizen has enough time to recuperate from work and isn't pestered by their employer 24/7.

What was stated seems pretty typical on small teams who manage critical systems. How are critical systems managed otherwise without having to 3x your team (assuming you want 24hr coverage with a 8hr workday)?

Why are we assuming that Amazon, the third largest corporation in the world by market cap, needs to limit itself to small teams?

They could afford to 3x the teams if they wanted to. They just don't want to, because management prefers to just keep the money and burn out their subordinates. (There's always more where they came from.)

Re: An Amazon programmer’s perspective (2015)

#178

Post by curiousllama »

I don't want to minimize what this guy went through - anything that takes you to the edge is too much - but I can't help but interpret this story as a story of professional & personal growth rather than an example of why Amazon sucks (Sidenote: I happen to agree they suck, just not for this particular reason).

How many people in other professions have had similar experiences from the perspective of intensity/amount of work? I-banking is _built_ around this level of intensity for years, and I've heard similar stories from people at other tech companies, plus VC, PE, consulting, medical residencies...

My big takeaway here is much less that Amazon sucks than that in a high pressure job, it's critical to know your limits: "I can go so far and no further." The author seems to acknowledge this; why are so many comments implying Amazon is uniquely terrible?

Re: An Amazon programmer’s perspective (2015)

#179

Post by dfinninger »

Austin_Conlon wrote: post #130
pkamb wrote: post #59

I've never understood how their Apple TV apps (Amazon Prime Video, Twitch, etc.) are so bad. If the Prime TV app was better I'd honestly probably cancel Netflix. But as-is I avoid using it completely. Then I interviewed for a mobile position at Amazon. Now I understand. A Facebook iOS recruiter laughed at my experience.

Is Facebook iOS engineering supposed to be impressive for laughing you off? I don't understand how they let slip crashing any app that used their iOS SDK: https://github.com/facebook/facebook-ios-sdk/issues/1374 .

I think the parent means that in a Facebook interview they shared a laugh at how terrible the Amazon interview was.

Re: An Amazon programmer’s perspective (2015)

#180

Post by dlp211 »

jedberg wrote: post #160
dlp211 wrote: post #106

Earlier quoted context omitted.

This is not evidence that payroll taxes are borne solely by the worker. I'm not claiming that workers don't bear any of the burden. Just that they don't bear all of the burden. this would be especially true in an asymmetrical payroll tax system in competitive labor markets like the Seattle Software Developer market.

I'm not sure how a competitive labor market makes any difference. They all have to pay the same payroll taxes. If anything it's a great equalizer -- all companies must bear that employee cost. So they will all take it out of their employee's earnings equally.

In this context, we are talking about the Seattle Head tax, which is NOT applied equally.

In the larger discussion of payroll taxes, to disprove that workers bear the entire burden of payroll taxes, just go through the thought experiment where we eliminate the employer side of the SS tax and whether wages would rise 6.2%. They wouldn't. Workers were willing to work for $N previously, there is no reason that they would stop working/change jobs unless they were paid $N + 6.2%.

Post reply on HN