61–70 of 374 posts
Writing tests is dysfunctional? Funny, I thought that was part of the job.
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 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.
Earlier quoted context omitted.
How easy is it to transfer between teams? Some companies make this easy, others make it almost harder to apply internally then externally.
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…
How was the work/life balance though? Did you find you were able to have downtime and rest or were you constantly worrying about unfinished work and looming deadlines?
I don't think I've ever heard a testimony of Amazon having good work life balance. The best you hear is that some people get lucky and things are "ok" on that front.
But then I saw how some teams (predominantly, but not exclusively, based in Seattle) worked, and....yeah. Overall, not great.
Earlier quoted context omitted.
I thought that the deployment pipelines are part of their core business considering AWS has such products that are meant to be used by customers. I assume that the internal tools are different than what AWS customers use for deployments?
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.
The entire CodeBuild suite kind of sucks when you stack it up to options available on the market including GitHub Actions, GitLab Runners, Azure DevOps, literally almost anything.
If the internal analogue is worse than the CodeStar suite, then yikes.
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.
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…
I figured this was pretty common. I've only had one job where I didn't feel the need to do this.
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…
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…
I'm battling something for weeks now which is a completely broken ass piece of shit inside AWS. I spent the first 3 weeks trying to get attention for this via support tickets and someone to take it seriously, resulting in escalating to account management. I've been on calls with the programme managers, been apologised to constantly and absolutely nothing has been done that is productive. Not only that they sheepishly suggested other customers were in the same shit.
My conclusion at the end is that critical bits of AWS are held together with only a couple of people who actually know how it works and they don't even have the ability to do fix anything...
Not that the consuming company I work for isn't a complete mess either but I expected better from AWS.
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 believe you also need approvals from your current manager(s) to switch teams?