What is it about tech culture that people within it refuse to admit the level of abuse-by-design that happens at these companies? Is it that they want to believe that they are somehow fundamentally different from the distribution and grocery store workers, and fundamentally similar to Bezos? I can't help but feel it's just this kind of false consciousness that prevents developers from _getting organized_.
Sidenote, payroll tax on Amazon in Seattle trying to get revived. It's a long and winding story. Check out taxamazon.net
This iteration is targeting the 800 largest employers in Seattle, many of whom aren’t currently profitable.
“Tax Amazon” is classic dishonesty — neither bill has been focused on Amazon, both would be a disaster for Seattle, and proponents try to focus on Amazon to keep people from noticing how damaging their out of control spending is.
In 2010, the Seattle budget was 3.8B; in 2020, it’s 6.5B. An increase of 2.7B and growth of 71% in a decade. (Per capita, the Seattle budget is 37% more now than in 2010.)
Seattle population has grown by around 23%  and inflation means $1 in 2010 has the spending power of $1.18 today , you'd expect a 45% increase (1.18*1.23) just accounting for population change. According to seattle's open government website, their budget was $6.24Bn in 2020, and $4.13Bn in 2010, a 51% increase. So just ball park spending has grown probably less than 0.5% per annum over inflation in the last decade.
: Acutally 2010-2018 - https://www.google.com/search?client=firefox-b-d&q=seattle+p...
If your goal is to reduce rents by reducing the number of people living nearby, then it can meet the goal.
And look where that got cities.
One school of thought is "just keep importing jobs AND add a ton of new housing" but there's a sort of capitalistic dystopian feeling to that, like that's the path to Blade Runner. Just need to start shipping out the people without high-enough paying jobs (again, actually - Europeans moving to the Americas doesn't seem that dissimilar) and we're there!
That's from 2017 when it was introduced but it's a good non-partisan explanation, including the many problems with the proposal. https://sccinsight.com/tag/head-tax/ has newer posts.
> This iteration is targeting the 800 largest employers in Seattle, many of whom aren’t currently profitable.
Citations needed. Citing a few articles quoting a few politicians does not count.
Creating an alt account to make this one comment not really trust-inspiring either.
Writing off the opposition as solely "pro-amazon shills" is exactly what gets those bs laws passed in the first place. I wonder how much money was wasted on all of this, given that it was repealed shortly after. Seems to be very in-line with how wastefully Seattle City Council has been running things.
That's a bold assertion without any citation.
The Amazon example is extreme, but a lot of tech workers fit the stereotype of people who don't have a lot else to do.
I spend 100+ hours at my computer a week, so if you want long hours, I can live with that.
I am up at 1AM anyway, so if you need something done at that time, sure. I just need to switch to my remote desktop.
I have colleagues and friends who will log in on weekends or evenings out of boredom to do work. No pressure to do it, but they just want something to do.
I fill my time with internet commenting and various online contests, but if they need help at 9PM, I am fine with jumping on the VPN to help and have done that a few times myself.
Amazon still has problems beyond the long hours and the 3AM calls, but there are people ok with those things or at least ok enough with them to not put up a fuss.
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 "pager duty" or otherwise work outside of 8-5. Those different expectations is what caused him to have a very bad experience.
If the company thinks its applications are important enough that it needs people around 24/7 to work on them then the company should hire enough people to have 3 shifts a day.
I didn't move forward to an interview, this was just from a meet-and-greet they did a few months ago (they do it every month IIRC). I have other reasons for not being at all interested in working for Amazon, but I figured it would be interesting to meet with them informally anyway.
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.
I'm a pretty heavy sleeper, and would go to bed with my phone on silent, set to ring a long time before going to answerphone, and with my Apple Watch on my wrist. If my phone rang then my watch would buzz me awake, eventually. The only snag was if, in my sleep, I knocked the watch out of contact enough that it locked and wouldn’t buzz on calls, but in practice I was lucky enough that I never got a call when that happened.
Not that I was called often. The company had developers around the world so it was only if they needed some specific knowledge or skills. That meant that being on-call was mostly a fee to compensate for being available at short notice and not drinking, etc.
Ultimately they decided they weren’t getting enough calls to justify the cost of paying the on-call fees and scrapped the system, just relying upon whichever developers around the world were working.
I then started wearing headphones to bed so that I would hear the phone ring and not disturb them, but when you're rolling out of bed and hopping on a call at 3AM it's difficult.
What I seriously underestimated was the strain that being on-call can put on a relationship, it's a massive regret.
Yes, these expectations should be made clear from the beginning.
I suspect they don't as they would be even more desperate to hire.
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 the time I left I was a Principal SDE.
Do good work, be in a good org.
Amazon is not a huge, homogeneous entity. It’s more like hundreds of small companies that are forced to work together, bound together by senior leadership.
Why wouldn't you count it? Do those days not-count somehow?
So, don't you think that, in the context of having to give up nights and weekends, you should mention on-call? Your choice or not, the weekends and nights are affected, in fact isn't it kind of worse when it's not your choice?
i also think there is a huge difference between being oncall and having to respond in case something breaks vs mandatory death marches all day, every day.
to give you an example. the team i was in at amazon had 3000 tickets in the queue when i started. anything except sev2s were basically ignored. lower severity tickets would escalate when shit hit the fan. i advocated for fixing classes of issues instead of myopically focusing on one-offs. by the time i left the queue was tens tickets and mostly feature request or higher level investigations.
to give you another example: i would basically remove all alerting that was not actionable. the worst possible thing that you can do is wake up in the middle of the night and not be able to do anything. i would ask for runbooks and the test was “if i take a developer from another team and put them oncall can they function independently 95% of the time”. i would think about what the experience of being oncall was (ie you don’t take people and throw them in the deep end of the pool and wonder why they drown)
so i guess what i’m saying is that oncall for me wasn’t that bad or stressful. it sucks having to be near a computer but I was rarely paged for stuff that broke or needed to be fixed right NOW. (once stabilized our team had 1 sev2 every other week)
our team had 7 people and at some point we started sharing the oncall load with a sister team (ie you were oncall for the services on both teams), meaning that you would be oncall roughly once every 3 months. not ideal - but not the worst thing in the world.
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
How many promotions was that? 4? How did you manage to do that in 7 years? That doesn’t sound easy at all.
My friends and I spent most of our lives since grade 9 doing school stuff or stuff to get into school stuff. In my case, couple that with introversion and an aversion to most normal activities and the easiest thing to do is be good at the get into school stuff.
In university, most of my social activities revolved around the startup world, hackathons, or other competition-oriented activities as that is what I was good at. I went to one hackathon a weekend in my final academic year.
So I became good at a lot of these types of things which all revolved around the academic world.
I am not in university anymore, but I can still fill my time with the kinds of competitions and challenges in that world. If I couldn't, I doubt that I would know how to use my time. Even with those, I spend a ton of time commenting online.
Most of the people I know are in the same kind of boat. They were good at one or two things (might be science fair, research, conference organizing, etc) back in university which consumed their time. Then they left and are now left wondering, "now what?"
Like taking up some challenges in life. Besides maintaining physical fitness and getting tired in the process, one thing I like is to create contraptions (does not have to be a "product") that could be useful to you or people you know. An air purifier, a charging station for a phone, a piece of wooden furniture, or anything else. Get some tools and get working.
If you prefer social activity, plan to do the above with a friend.
Then you ssh in and work to fill the hole. Now I don’t even get to see my co-workers.
Very sad when you think about it. Wasted potential.
Eh, you leave the university environment of all its clubs, hackathons, etc, likely to another city where you know far fewer people. You need to wake up the next morning, so gaming until 5AM with your friends no longer works. Someone is also on on-call, so they can't join, so you postpose it further.
The end result is a lot more free time.
Nobody shamed Chopin for spending his life in front of the piano. Some people choose to dedicate their lives to one single thing, and often those are the people who end up contributing the most.
And maybe, just maybe, universally acclaimed musical geniuses are not a good point of comparison for common folk.
So at the same time it can be true that company X is a great place and also true that company X is a nightmare.
The divide between AWS employees and everyone else employed at Amazon seems to be "2007 Google employee" against "sweatshop"; they're run mostly-separately, from what I've read.
This was also four years ago; the gist is a copy of a post from 2015, by the above reddit poster.
This is not true. Amazon and AWS are exactly the same organizationally speaking. You could hardly tell who works in an Amazon team and who works in an AWS team. Maybe if they tell you their building.
The cultural drift happens in the teams and orgs, not the parent "company". Everyone at Amazon knows this and that’s why many people know changing teams is a gamble and prefer staying at the same team doing the same menial tasks, than venturing into finding another team.
Amazon and AWS have both great teams and shitty teams. There’s just not an easy way to tell, except for one internal tool that allows you to see how people are rating their managers but this is all bs because some teams don’t have enough data or any data at all. Also the data itself is probably skewed, since people are afraid of giving poor rates to their managers (this is a general problem in the modern workplace dynamics, not at an Amazon problem)
The other way is asking a friend but I don’t know how people do that since I only knew people from my team and teams that sat nearby. Maybe I’m too socially incompetent.
This is incredibly offensive. I work in CDO and have friends in retail and AWS and the biggest difference day-to-day is that we have different systems to manage our AWS accounts.
Equivocating me to a Wipro employee is honestly really disgusting. These sorts of microaggressions are the worst part of working at Amazon, the WLB is fine.
If psychologists surveyed one of these companies, like Amazon, to look at the sorts of attachements the employees have now, and had as a child, I think you will find distinct deficit of people who had a happy childhoods with secure attachments sticking around at these companies.
The bravado and masochism so common in such places, in my opinion, is a form of self-bullying. You don't have to look hard to find managers exploiting this characteristic, and I suspect the most of the ones who thrive in such an environment do it. I worked a brief contract there and it was clear that the manager was used to making statements designed to trigger his subordinates' insecurities.
When your self worth is tied to the quality of your work, but your ability to self-evaluate is not solid. you are vulnerable to manipulation. I have that trigger too, it's just harder to hit, especially by some punk who is used to saying 'frog' and having people jump. I felt sometimes like he was waiting for me to react to some subtly passive-aggressive statement he just made and I just shrugged it off and stopped talking or kept going.
A master can be very tied to the quality of their work, and hand you your ass if you try to disagree with them. This doesn't develop overnight, and it's a winding road, but it's very undeveloped in a bunch of 25 year olds with a toxic cocktail of Impostor and Dunning-Kruger, and any 28 year old who spent more time honing their interpersonal skills in college has some ideas how to get what they want out of such people.
And those people think this is okay. Normal. That it's only what they deserve. And then we have a culture of avoiding psychotherapists, who would tell you two sessions in that this is bullshit and you shouldn't have to live this way.
you're 100% right
Amazon is a fascinating company, it's Big Capitalism in a way no other company is today, and as such it's writing History, for better or worse. For the average developer it's not great, though.
He's not coming in as a no name peon. He's financially well off, internet famous and would (and could) probably leave at the first sign of mistreatment.
He's in Canada, do health insurance isn't tied to job.
“It is difficult to get a man to understand something, when his salary depends on his not understanding it.”
― Upton Sinclair
I think this might be a big part of it. The idea that "I'm college educated and don't perform physical labor means I'm not like them" seems to be a pervasive societal thought not even strictly related to tech.
If these developers don't ever see or talk to the people who are suffering from the company strategy, then the problem may remain to appear imaginary or abstract.
It's not even programmers like OP but also all the servicepeople and staff at datacenters, and the rest of the crew which makes up the infrastructure that makes it work.
That's how every business works. All per employee costs are borne by the employee one way or another.
By the same argument, customers are paying the costs for Best Buy's internal logistics and retail floor operations to enable “free browse and instant pickup”. If those costs are higher than Amazon/NewEgg's costs for "free shipping", I'd expect to see exactly the relative prices that you're seeing.
I'll reiterate my point that shipping is a cost that has to be paid, but who bears that cost is not necessarily the customer. If it was the case that the customer was the one bearing that cost, there would be a difference in the price you pay for goods at a physical store vs. goods shipped to your home, implicitly or explicitly. There is generally no difference, and in many cases, ship to home is cheaper because you can select from more retailers.
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%.
But now do the thought experiment where the employee must explicitly pay the extra 6.2%. Now of course you have to give them a 6.2% raise, because they would demand it to cover their increased costs.
Numbers: I pay the worker $10000 a month. Let's say my tax cost is $500 a month, and their tax cost is $500/mo. So they get a check for $9500, they see a $500 tax deduction, and they net $9000.
My all in cost is $10000.
Now the city says "you don't have to pay your part of the tax anymore, the worker does!"
So now I pay them $10000, they see a deduction of $1000 on their paycheck, and net $9000. My all in cost is still $10000, their net is still $9000. Nothing has changed.
I'm still paying $10000 to have that worker. And if my budget is 100000, I can still only afford 10 workers.
My first job out of college I had two bosses. HORRIBLE.
This came up recently, a manager, trying to be helpful, not sure they could manage someone said why don't we both manage them. NO!
The other things - trading sleep and shutting off friends - the first will destroy your quality of life and the second you will regret for a LONG time no matter how critical the day to day was.
I'm not perfect. Setting boundries. I focus on situations in my case - what situation lead to bad results. Also - you can sometimes trade time for reduced money - which in some of these situations is a NO BRAINER. I'm trying to do that. Society really IS NOT setup to support that.
I go home even if I'm behind. I sleep next to my wife and play with my kid. Covid has made catching back up with friends harder.
I think what folks from the outside don't realize is that folks making big money+ - you put a lot of pressure ON YOURSELF. You are given lots of money, often lots of responsibility, your work impacts lots of people (internally and externally). This is even if Jeff Bezos is not your boss.
I think talking about the Leadership Principles as a 'typical corporate motto' is unfair. Amazon lives their leadership principles far more than the other companies I've seen. They don't include things they don't actually care about, like most corporate mottos do (you'll notice the lack of 'we care about our employees' or 'do no evil' LPs).
At least in my experience, you only need to pay back Amazon proportional to (2 years minus duration employed) so it really isn't that bad (maybe that wasn't the case when this was written).
Maybe it's changed, but the signing bonuses I saw were essentially increased salary until your stock starts vesting seriously. It gets paid out and vests every paycheck so there isn't anything you need to pay back.
Relocation bonus would have had to have been repaid in full if I had left during my first year.
From the perspective of not taking advantage of the financial irresponsibility of recent grads, this is an improvement over the structure described in TFA, but the right solution is make sure that recent grads know what compensation agreement they're signing and can resist the urge to spend it all, that can't be left to employers, whose every incentives push against that. Big lump sum payment right out of college are very useful as emergency slush funds even if you can't responsibly do much with them for a few months.
I was made an offer for L5 at Amazon earlier this year. For compensation, it's like you suggested: the offer is structured such that the first two years weigh more heavily toward cash (a separate signing bonus for each of the first two years, which IMO was pretty good and _does not_ need to be paid back, it's just combined with your normal bi-weekly paychecks) and then the latter two years are where you get the majority of your RSU rewards, which wind up being worth the same or more than the cash bonuses of the first two years (assuming I suppose that the stock price continues to be stable and/or increase from what it was at time of signing).
A note about the signing bonuses, the offer letter details basically do not say anything about needing to pay them back for leaving early. If your employment is terminated (by yourself or Amazon itself), then you just end with the prorated portion for the current pay cycle and that's it, you don't get any more of it (fairly obvious anyway if you leave a place).
Two things about it: it's not feel-good bullshit like the parent said. That makes it real. And another: so many principles are at direct odds. Do you "Insist on the highest standards" and delay the launch or do you "Deliver results" now? How do you "Think Big" while also obeying the mandate for "Frugality"? There is a lot of tension in the principles which matches real-world choices. It's not the shallow corporatese of most mission statements.
You're right. The proportional compensation is something I was very wrong about.
At the time, I was also in debt due to being straight out of college and having been dumb AF with money (student loans, car, & credit cards) and so owing anything would've been bankrupting.
It was so easy to be stupid with money when you're making an engineer's salary.
Not shifting blame, I did that debt to myself and I dug myself out of it after educating myself.
Just giving more context.
Customer Obsession is "do no evil".
I think there is a real tension between customer obsession and 'do no evil'. Serving the individual needs of consumers can come at the expense of the public good. I think example of that are the amount of waste that Amazon packages generate by shipping as fast as possible and the amount of environmental damage AWS can quietly cause via their datacenters.
On the other hand at the end of year 2 when you have gotten used to the monthly payments I guess the we told you so is it bit harder to agree with.
Does he have to pay $3000 for a 2 bedroom rent?
I was specifically talking about the Seattle market for housing since I also live here.
Comparing base compensation without taking into consideration the city the person lives in is useless.
You can make a ton of money as a doctor nearly anywhere in the United States. Software engineers don't get that freedom. Maybe now with more WFH being common place.
However, now to get to the point of being a physical you need to go under a ton of debt. That wasn't the case for our parents and grandparents.
The original OP's write-up misses the main questions and helpful perspective. Doctors (we have several in the extended family), lawyers (worked with some), entrepreneurs (have been one) all put in very long hours. So do grad students, and undergrad's working on tough assignments.
It's not work per se; the issues are larger, and different:
- do you enjoy what you do? If you're new, out of school you may not know this without experience. This guy got experience. We are aware that plenty of people make career changes inside and outside their industry right? Because of they realized the enjoyment and fulfillment wasn't there, right?
- do you have friends, hobbies, a social life, a wife (husband) and family? Do you do anything with them? If not, why not? Why does one work all the time?
- do you have self awareness of your red lines? If no, why not? If yes, why were they repeatedly crossed? Individuals have choice, agency if they are relatively self-aware.
- Why would a team put up with so many bugs, and so many late calls? There are a zillion developer teams ... we all have support issues/challenges, and part of the job is reducing outages which feeds into software engineering, quality, management, cross functional management with business people providing requirements, corporate culture, and many other facets.
I didn't find this article helpful. I do not cherish or dismiss the trauma reported herein, but something bad X happened at company Y is neither new, insightful, or explanative in any ultimate way that counts.
Paying back a signing bonus if they fire you seems super rough. Is this common elsewhere? 2 years also seems high - the time I got a signing bonus, it was "pay back if you leave voluntarily in 1 year" which was much nicer than the described.
Unfortunately, much of this seems pretty common, especially months-of-crunch-time. Being able to figure out projects to avoid (if you're at a big corp like this where such things are possible), and being able to avoid them is a very good career skill to cultivate.
On-call can work quite well if the team has sufficient ownership to improve the underlying issues, not just keep the lights on. I've done this with good success. I'm often disappointed by how many managers and companies I've seen who don't get that aspect.
Believing too much in mantras like "adding manpower to a late software project makes it later" can be dangerous, too, though. How well it works depends on the manager and the person scoping and planning the work. Another critical skill to develop to escape being the person doing the grunt work.
I actually don't think this is true. My understanding is if you're PIPed they don't really care. The signing bonus is paid out monthly the 2nd year (and for people hired at SDE2+ its first year too) so you don't have to pay it back after the first year.
Disclaimer: Amazon L4
Part one is in your first year where you get a lump sum signing bonus with your first paycheck (paid monthly) with the understanding that if you leave you would pay back a pro-rated amount proportional to how many months were left in the year.
Part two is in your second year and is paid partially with every pay check and if you leave you don’t pay anything back, you just don’t get the remainder of the money to be paid out the rest of the year.
After year two stock vests tend to vastly outpace the signing bonus pay but I’d imagine this varies on the stock price.
I've interviewed at Amazon and had a lot of conversations about compensation. I don't know about the terms of the relocation bonus, but for the signing bonus, you don't pay it back if you are fired and even if you leave voluntarily, you only pay back a pro-rated amount. For example if your signing bonus is $20k, and you leave at the 6 months mark, you owe $10k back but you get to keep the other $10k.
When I graduated college, all of my friend group discussed it and we all took out a small chunk of the bonus to go on a small group vacation, but the rest of the bonus got put into an investment account and not touched for at least a year. That way if we did decide to leave, the money was easily accessible to be paid back. I know not everyone has that flexibility, but it's probably the best way to approach signing bonuses if you're not 100% sure you will be at the company long term.
also, anecdotally, it you were fired they would not ask for the bonus back - it opened a whole can of worms in the wrongful termination bucket
so op definitely did not read his employment contract
Author mentions that he traded sleep for code, and I hear this from so many people but I really cannot understand how well they manage to pull this off. I simply cannot code productively if I get less than 7 hours of sleep or code for more than 8 hours straight, and caffeine doesn’t help me. So how do you people manage to pull this off? I’m really envious that people can code all day long but does it really provide good code? Doesn’t that increase the bug count of the code?
I don't say that disparagingly, this is 90% of my day to day life as a mid-level engineer at a FAANG. The other 10% I might get to do something "neat" that I can justify somehow. It depends on the team of course, but I find the Author's experience believable.
Don't do it :) Please don't be envious
It didn't produce good code, but to be fair, the project didn't need to have great code, just working code.
It absolutely increased the bug count. Again, in hindsight and with a calmed mind, it's obvious.
Try working for some IT firm that supports healthcare, utility, defense, or what not, and I can assure you that there's rotation duty where you need to be on-call within xx minutes, 24/7.
During college I was interning for IT firm that provided networking for local hospitals, and they had the same rotation. My friend who got me the gig, worked there FT, and he basically had to forego social activities every 3 or 4 week, because he'd be on call 24/7.
Not to say that there aren't toxic on-call rotations and such, only that it's a lot more common than you'd think, and is not limited to just doctors eyeroll
Any time a business unit needs to be accountable to another party after-hours, some sort of call schedule is created.
It should be very clear what the actual expectation is, though, instead of a nebulous "we may need you to work extra sometimes." It's a guarantee that you will work extra at a fixed interval, and that extra work happens to be psychologically draining.
I ask for quite the premium in salary if I know I'm going to be on call.
I don't work at Amazon but the situation is very similar to my job. On-call can be brutal, even if there are no incidents during your week (which is rare.)
Just the fact that you have to be 24/7 _ready_ during a whole week sucks, especially when you have a family. During my on-call week, I can't go get groceries, I can't take my kid to her hockey practice, we can't go out for lunch over the weekend, etc.
It takes a toll, for sure.
I’ve found that just having someone else to commiserate with at midnight, if needed, really helps the mental state of on-call.
"on call" was super, super vague and I pushed back hard on it. If they require me to work outside something reasonable like 6am-6pm, they will pay me at least double for it. No exceptions.
I wish everyone would push back that hard, and that on-call was an official opt-in "extra pay" scenario.
Needless to say I turned down their "promotion" even after months of them trying to make me take it.
Note: I am NOT saying I'll work 12 hour days. I'm just saying if I have to come in early for a meeting for 6am, or stay until 6pm sometimes, that's fine. If I'm expected to come in or be on call at 2am, that's a different story.
Also, I consider that my child is dead because of what happened.
See https://amazonandmykid.com for the full story.
Are you willing to give more details?
Short version: Think what you will. My story serves as a warning to anyone who thinks you can survive the Amazon hell. I may have issues of various sorts, but no one should have to tolerate the "Amazon way" or be subjected to their insanity.
Only 50% match, and the maximum match they will pay is 2% of salary. (Competitors match 1:1, high or no limit).
Three years vesting on the match. (Immediate vesting elsewhere, e.g. Google).
No match on catch-up contributions. (WTF? Naked age discrimination as policy?)
Yet to know anyone who lasted more than a year or two there. Obviously some do, but they go through an enormous number of people.
I was at Amazon for four years and enjoyed my time there. I had one stint on a high profile high-pressure team that lasted about 6 months (no on-call, though). That was the busiest time I had at Amazon but it was kinda known going into that project.
I generally worked 45-50 hour weeks, with the occasional 50-60 hour weeks but that was pretty rare.
It's a big company. It really depends a lot on your manager, your team, and your org.
Uh, not even close. I used to get up at 4am EST to trade European markets for a hedge fund. I was on call 24/7/365. I had my laptop and Bloomberg fingerprint scanner with me on any trip I took.
And this is just my experience. I have had many friends in engineering, management consulting, fin tech, etc who have similar demands made of them.
I’m not saying it’s right, but it is part of the rules of the game that we all sign up to. There’s a reason all of the aforementioned jobs pay so well.
I think oncall is a common requirement for anything involving large sums of money, treatment of high risk injuries, or geopolitical power struggles.
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.
A key difference is that the oncall engineer is usually able to directly influence the quality and robustness of the systems being watched. Sort of like preventative medicine, but much more direct.
Crappy teams make crappy software that pages often (or not at all if their ops fails to write any meaningful alerts)
If you work on a buggy-enough system, and don't do the root causing, then you will have incredibly bad on-call experiences.
If a big selling point of your system is the ability to be on 24/7, on-call is inevitable. But it definitely can be way less gruesome than it currently is at Amazon for a lot of teams right now. For example, my on-call schedule is extremely relaxed and low-stress, it is never a worry I actually have or something I dread ahead of time. But getting rid of it completely is simply impossible for a lot of "always online" services.
hire more people?
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 very closely familiar with the code and features being written in order to resolve issues effectively. Which usually means that you need to be someone who actually worked on those things, not just some glorified extra-fancy customer-support worker.
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.
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.
I would much rather bite the bullet, be on call a week a month or so and use the budget for something else.
And I'm not talking about Amazon here. Of course Amazon can afford to hire everybody and their mom to cover 24 hours in a day. I'm under the impression that your original comment was really a critic of the practice in general, not just this specific example.
Some small companies build products they try to sell to bigger companies. These bigger companies have SLAs, so they need SLAs from their providers to sign a contract. Even at a small startup on call may be necessary to get customers.
It absolutely was criticism of the practise in general. Yes, small companies that can't ensure that there workers aren't overworked don't really make sense with protections like these. But the same is true for environmental protection.
Critical infrastructure arguably ought to be handled by companies large enough and with enough staff to comply with regulation like this.
For anything else I don't see the issue. Some random smartphone app company doesn't need to fix anything at 3 am in the morning, it can be fixed the next day. That's exactly the culture I'm critizing. 24/7 readiness to work for some random product at the expense of mental health is awful.
I gave you examples of how to implement on call without overworking your employees and even giving them the option to run a few errands here and there. So what's the problem? You seem to be against the practice just for the principle, not even really for any bad effets due to bad implementations.
As for which products are worth implementing "on call" for, yes I agree, some companies are too quick to think that the world can't function 30 minutes without their product.
Anyways, I've seen it implemented successfully at companies with very low attrition and I do believe it is a necessary tool sometimes for small companies to grow and sign big whale customers.
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.)
It doesn't make financial sense because companies can get away with exploitative behavior because software engineers are quite naive (or even actively detrimental to themselves and their peers) when it comes to labor relations.
I see this comment again and again on this thread "if it's really critical spend the money", but the thing is even small companies sometimes have critical systems. Simply because they're trying to compete with bigger ones, or they're partnering with companies that do have critical systems and the SLA gets passed down the chain of dependencies.
The description in the post is not even that bad. A page a week is nothing. And it is clearly state that your workload is reduced during your on call period.
In practice, your workload may not be reduced during on call because it's "expected" and you still have to meet your normal deliverables while the team isn't staffed with "extra" people. It also takes a toll on employees to be mentally-available at all times in case some triviality emerges and raises an alarm. You'll find many engineers not willing to leave a small area or even go out for dinner without bringing their laptop and a hotspot, just in case.
- use a primary and secondary on call so that the primary can still go get groceries, or play in the yard with their kids, etc
- overlap on call and work hours. I did that at a job and I was fine with working 6pm - 2am just to cover this time slot. Won't work for everyone, but may be a nice compromise for some.
Like everything else, there are ways to do it right, and way to go complete bananas with it.
Sure, agreed. Sometimes it's implemented well and sometimes it isn't. I've experienced some of both.
When it isn't well-implemented and is particularly non-critical, it can feel a bit dystopian to the engineers. If done well and for a good cause, it should be fine.
My only advice to this person is:
- talk to someone who does customer-facing tech support in your own company
- never take a job in customer-facing tech support
I worked in high volume manufacturing where process engineers could be on-call 24/7-365 unless you explicitly asked a backup to cover you during a vacation or weekend. Depending on the part of the process you owned, that might mean a middle-of-the-night call a couple times a month or several times a week. No human lives on the line, just lots of money.
Wow, I wish I had once a week. This is way better than my previous employer/role. I was on-call for months straight, and would get paged multiple times a night, every day, even at 2am, 4am. I had to carry my laptop to dinners, date nights, game nights, etc.
I got burned out and moved careers into a role that never has on-call. I don't get to code much anymore, but I've found other things to enjoy
At one previous employer, you were on a 2-week rotation for on-call.
But Every time you were on call, it was the same set of problems, always at the same inconvenient times (Mid sunday afternoon, random weekdays but always between 3-5AM, etc.) Admittedly often they were NOPs (Oh, alert came in, but when you check the system it's fine.)
But we didn't fix the false alarms. And we didn't fix the recurring real problems either; the Org's view was that was the entire purpose of the On-call person; that middle child you send to pay the loan shark not-quite enough because you don't care what happens to them.
At later employer, I actually had to deal with -more- on call issues, both in severity and frequency. And yet, I hate being on-call less, because at the very least when we find problems on-call the org puts a focus on fixing them.
It was horrible and in retrospect a really bad decision with the expected outcomes, mostly broken mental health.
>There is something great about having code you wrote be actually executed by thousands of people every day. So few people get to show their friends and family a site they visit often and say "I did that thing there." Maybe it will wear off eventually, but it's still my favorite.
It has never worn off for me! I've worked in automotive for over 20 years, and it feels great every time I see something I worked on drive by.
The reason for it isn't employee retention. It's to stop people from accepting a job from Amazon just so someone will pay for their move to Seattle and give them a free bonus.
Would people do this? Yes. I've seen them try. It also discourages people who aren't serious about the job.
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?
You are absolutely right.
As other have pointed out, it's probably 1000x worse to be a doctor saddled with med school debt who is literally operating on people. I will not argue that, ever.
But that's also not me and so I told the story I could; mine.
I really want this to be more about how vital professional and personal boundaries are.
While also highlighting how certain company behaviors make it challenging (on/call, etc.)
Before Amazon I had worked at a company that (due to the nature of the work) necessitated a strict 9-5. You literally couldn't work a minute more.
Before that, I was in college and had hourly jobs.
So you could say this was my first big-boy job with salary-hours, as well as real responsibilities (rent, car, wife, life)
Different software products have different severity levels. For my team, the oncall burden is not so bad. We have an internally facing tool. When we do get paged, it's usually requires acknowledging a ticket, a few minutes to validate something, sending an email out, and that's it. For teams with more externally visible products, a particular page can be stressful, but my understanding is they also spend a lot of time in ensuring system robustness in order to limit the number of pages. The "15 minute" response time the post referred to is generally to acknowledgement - the expected time to resolution can be quite variable.
The working hours are generally pretty good as well. The general expectation is that you're not working crazy hours.
I've ran into "project crunch time" at Amazon, but the experience at Amazon was like everywhere else I've worked. This also will vary by team: teams that need to make changes to support Black Friday obviously have a pretty hard deadline. Or if your team is getting ready for a re:invent announcement, there's no way to work around that. But from what I've heard, teams that have such a hard deadline also have a corresponding quiet period in December or January.
Most people I know within Amazon that get burned out on one team and feel like there's no resolution within that team (or just feel like they've had enough with one area) solve that by switching teams. This is generally pretty easy, since most teams are hiring at any time, and they would rather take an internal transfer than an outside hire.
Amazon has a pretty good system around having a senior individual contributor track (I haven't worked for any of the other big tech companies, my understanding is that they're similar). Part of the benefit of this system is that SDE1's/SDE2's have someone to reach out to for helping navigate management. Anyone at Amazon who reads this who is experiencing something similar to the OP should feel free to reach out to one of the senior engineers for help.
Overall, I don't doubt that the post in the original article is that person's experience, but it has not been my experience.
Before covid happened, I was interviewing for a SDE-2 position within AWS Canada, so it would be of great value to me!
'Encourage employees to be critical not just of ideas, but also of expectations.'
From my experience as a developer; I've never really been involved in the process of setting expectations. Something I find incredibly frustrating at times. It's like sure you can give your opinion but it's too late to make any difference. I think it comes back to the main point in the article about open communication.
I think open communication needs to be inclusive. However, that's rarely the case at least in terms of setting business expectations. It's only natural to want to be involved in shaping some objective or some expectation that impacts you and for which you may be one of the more qualified to discuss.
Nobody will ask you. You have to be upfront about it from the start.
Request time estimations and fully fledged requirement definitions from the start. Review them before accepting a project, push back against overly ambitious plans and propose changes that allow you to deliver value quickly and iteratively. It's easier to react to surprises if you are able to test the ideas as you go.
Stick to the plan as much as you can. Push back against changes to the requirements if they're not vital. Let others know about blockers clearly, as soon as you run into them. If you get behind schedule, communicate it properly. Stuff happens, unfortunately, and deadlines not being met is a part of life. You just get better at estimating with experience.
There's no way the upper echelons will adapt if they don't receive input timely and loudly enough. If your boss is any kind of decent, they will listen to you and trust your input. If they don't listen, then you should reconsider your current job.
I would personally love to tell Bezos to "fuck off" if the ask was unreasonable. Worst case scenario, I have to find a new job (which I usually have a few companies/recruiters in my back pocket), or best case scenario I get "respected" and the deadline is pushed to a more reasonable date. Typically massive corporations like this put you on a "performance improvement plan" which can give you few weeks to a few months to find a new job (or "improve").
Also learn to make friends with your teammates in the trenches. Presenting a push back to management in a unified front is much more compelling than a 1:1.
1-datapoint (@India): Their interviewers have uniformly managed to be both obnoxious, and somehow simultaneously also quite insipid.
I want it to happen. I'd like a word.
You could be shown the door in no-time. Amazon has forced attrition and the manager decides who gets the cull. They may make a mountain out of a mole to further their objectives.
I feel like it's common wisdom now that forced culling is not a great strategy and has lots of perverse incentives, but still not universal.
Do you know how they implement it? Is it the old Microsoft model with obligatory bell curve distribution of performance reviews?
Each manager of, say, 10 people rates their own reports.
The managers in the org compare notes, and count up how many poor performers they have between them.
If the number is below X, managers who did not downrate enough people are told to go back, and find more people to give bad ratings to.
If they can't find those people, that's fine - then those managers will get downrated.
OK, that's what I meant. Thank you.
I was part (as a manager) of a smallish org that started doing that after being acquired by a big corpo. I just left :)
IMO it's the lowest effort blogging platform (for people who already know how to use git). You don't have to go to a webpage - just write some text in the editor of your choice.
You don't even need to use something like Hugo since Github will render markdown files properly.
I've only ever used Pastebin for gaming leaks and I don't think the interface leads itself well for long form posts. Probably just me being picky though.
It probably caused a lot of drama.
> SDE II basically means a software developer with at least 2–3 years of industry experience
If this is true, the hiring bar has been lowered incredibly.
... or literally thousands of people in the military right now, oil rig work, countless other IT help desk jobs, etc.
> are you willing to work nights and/or weekends
To be fair I'd say this is mention enough.
If someone is willing to (or has to) look the other way at the time of hiring when something like this was explicitly said, then even a "hey, we have on-call here, you fine with that?" would be okay.
However on the interviewee's side, if you see something in a job description that asks if you're willing to work nights and weekends, that should be an immediate indicator to you that you should ask why you possibly would have to work nights/weekends and in what capacity. It's the interviewee's responsibility to ask questions like this even if the employer isn't immediately forthcoming.
I understand that this person was coming straight out of school, but the onus is on the applicant to figure out more about the job during the interview process.
Dude, have you fucking seen the Android libraries? They're awful! At least the AWS SDK libraries are like that because they're all autogenerated from a spec.