401–410 of 589 posts
Earlier quoted context omitted.
Yeah there's no way I'd put up with this. Trillion dollar company and still operating like it's amateur hour on many teams it seems.
American capitalism is built on employee heroics, but at least you can get the AWS stamp on your resie, which, let's be honest, will make you the "it" girl of job hunting.
Earlier quoted context omitted.
Business insider is a lying trash rag.
The primary source is the NYT, not Business Insider. They clearly name their source too, "David Niekerk, a former Amazon vice president who built the warehouse human resources operations" 1: https://www.nytimes.com/interactive/2021/06/15/us/amazon-wor...
Earlier quoted context omitted.
Can you share your knowledge or reading materials for how to reduce on-call load? I’ve worked at a number of big companies but all the problems driving the oncall load seemed, at best, domain specific if not application specific with highly variable fix times and unpredictable occurrence (eg started becoming more of a problem due to unrelated change X). As a result each team has to decide the cost of fixing the pain…
I'm not the parent but lemme chime in on this topic. It's pretty simple, if you don't build crappy software you won't get a heavy on-call load. You're really asking how to build great software. Build strong teams, with experienced people, follow good practices, reward quality and stability and not features or lines of code, reduce complexity, etc. etc. I've worked on software used by millions of people with a very lo…
One reality is more like "You are handed a system with a heavy on-call load. Make it better."
The other is "The system you built was great with 1e9 load, but now we're heading for 1e12 load. Make it better."
Former AWS engineer here. I worked on a pretty critical product in AWS (big AWS service with lots of traffic) and I can safely say that it's totally up to your manager and pre-existing conditions which make up the job. My manager was great as a person but would always lack in my career-oriented goals (bigger projects, promotions, etc) But what really sucked for me was the pre-existing conditions. Our on-call was pret…
Earlier quoted context omitted.
I’m genuinely curious how saying good luck gets down voted. Fuck the HN crowd for this shit.
Comments like “good luck!”, “me too”, and “hi James” will get downvoted because they don’t contribute to the conversation
Earlier quoted context omitted.
well the good news (for amazon) is that I used to work at a place where I was trying to build a cloud. And management suffered from EXACTLY THE SAME PROBLEMS (though for different structural reasons, there was no "build a feature" incentive). And then we hired someone who used to work on amazon cloud who came with rave reviews, even though he completely failed my interview, which basically tested "do you read the spe…
Yeah it’s surprising that despite the negative comments in this thread, AWS works almost flawlessly for stuff that matters (uptime, reliability etc.). Of course it’s painful to work with sometimes, but so are other cloud vendors. There’s literally zero incentive to change things internally until external KPIs start turning red.
Disclaimer: Former logistics Amazonian.
Former AWS engineer here. I worked on a pretty critical product in AWS (big AWS service with lots of traffic) and I can safely say that it's totally up to your manager and pre-existing conditions which make up the job. My manager was great as a person but would always lack in my career-oriented goals (bigger projects, promotions, etc) But what really sucked for me was the pre-existing conditions. Our on-call was pret…
Earlier quoted context omitted.
> I contrast it with excellent experiences at Sun, Motorola, Apple and others over the past 20+ years, where in some cases I had very high engineering ranks with fabulous results, in very well run and just healthy orgs. I can understand how junior devs end up in these positions for a while and stay on the ride, but what is making someone with your level of experience you stick to Amazon? Is the compensation that good…
Compensation seems good, but I'm there because I got fooled and plan to quit very soon, when graciously (not screw team-mates) feasible, because it's just a waste of time that could be spent helping positive efforts in healthy orgs.
Quit now, and encourage your teammates to do likewise. I understand where you're coming from, but the attitude you have can be a source of exploitation (e.g. using loyalty to peers to keep you while the org screws all of you more).
Earlier quoted context omitted.
>Our on-call was pretty bad (40-60 tickets a week) and there was very little investment being put in to improve it. We had a lot of little scripts here and there which would solve extremely specific situations but no focus was ever put on in building a general framework or trying to reduce the ticket count. AWS engineer here and I confirm everything you say, but this quote really struck home with me. The thing I've n…
Can you share your knowledge or reading materials for how to reduce on-call load? I’ve worked at a number of big companies but all the problems driving the oncall load seemed, at best, domain specific if not application specific with highly variable fix times and unpredictable occurrence (eg started becoming more of a problem due to unrelated change X). As a result each team has to decide the cost of fixing the pain…
1) Make a goal: we should get paged for at most N incidents per week. That goal should be closer to 0 than 10 IMO.
2) Track stats on this goal, both in aggregate and broken down by cases you think you can address separately. Example: tickets from alarms vs tickets filed by people. Alarms having to do with external dependencies vs alarms caused by your own bugs. Don't just make this a "it seems like we've had fewer pages lately" thing. Real numbers.
3) Review these stats on a graph every week. Someone should have an explanation of why they have spiked, why they haven't dropped, the breakdown of problem type, etc. There should be congratulations when they drop and a request for plans when they don't.
4) have management that can communicate upwards to leadership that ops improvement is a priority for your team and that you ultimately won't be able to continue other feature development if you are always mired in ops pain and people are either busy with mundanity or driven to leave the team.
5) dedicate time in each sprint to working on the most recent identified target from plans made in #3.
edit: formatted so indented list is readable on mobile. I have no idea how to do this without a code block. HN, please make this easier :)
I've had two job offers from AWS for SA and TAM and I turned both down. The actual position was always lower than what I was originally interviewing for (Senior instead of Staff) Literally the only company I've seen that does that. It's like a bait and switch. If I'm not actually qualified just say no lol