Amazon

Half-decent culture; nobody gives a s**t if you swear or what you look like as long as you can get the job done and be semi-professional with how you talk to the higher-level managers.

Scale: potential to make a huge impact worldwide to add to the CV (e.g. saving 100s of millions in terms of S3 storage costs or DDB provisioned IOPs/usage).

Very well-defined and extensible CI/CD system.

Very well-integrated environment (i.e. all the internal web UIs for browsing code, CRs, deployment pipelines, alarms, etc. flow very well together and are often cross-linked).

Excellent version control, package/build versioning, and package group versioning, again very well coupled with automatic builds to seamlessly create CI/CD pipelines.

Lots of opportunity to use native AWS and become familiar with building and managing services at scale in native AWS.

Very motivated, tenacious, and technically fearless staff, diving into every possible thing no matter their background or prior knowledge (even my manager helps out on some CRs).

You may be able to make a big impact to multiple projects throughout the entire organization if you can prove yourself to your manager early on; managers are often asked to share engineering talent with the larger org if there are special projects in flight which require more staff temporarily.

Work is extremely structured and visible; you have stories and tasks you speak to during standups and sprint planning, and the expectation to document the minutiae of every task is high (could also be a con depending on preference, but pro because you will usually have a good idea what everyone else is working on).

• Compensation is very equity-focused and not really that competitive in comparison to the other FAANG monopolies.
• High attrition (had five different people leave the org over one year) due to the very demanding and draining nature of the work.
• The on-call load for a Tier-1 service is extremely bad, no matter how much automation we seem to put in place.
• Your time is always being bargained for by all levels of leadership, sometimes within the organization and sometimes from outside/customer support if on-call, and it can be overwhelming.
• The environment is programmed to suck every little bit of value they possibly can out of you, so be careful how much you let it. Try to work with your manager to find a sustainable work-life balance and try to be involved in meetings, offering input/soliciting feedback. The last thing you want is a PIP (performance improvement plan), which is where HR and your manager start figuring out how to terminate you (but this never happened to myself or anyone I've worked with to my knowledge).
• Deploying code to production should be easy because we have a system for creating and managing CI/CD pipelines, right? Wrong. The process on some teams is such that you could spend days just waiting for someone to review and approve your change control document, or working on revisions to the document because some wording isn't clear, despite the deployment procedure itself being straight-forward and intuitive for anyone who's worked with CI/CD before.
• All deployments come with risks, but the fact that we need change control at all means we are not deploying frequently enough to stamp out these risks. There are many things which simply lack test coverage in our system due to aggressive deadlines and emphasis on delivering new features over improving operational pain.
• Managers and SDEs alike have a tendency to pile all the dirty work onto systems engineers and SysDEs. For example: go figure out how much of these types of capacity we need in these regions and then increase the EC2 ASG capacity before we roll out our new service there (which often takes place through the AWS console because it's faster than writing a script to pull all the credentials for all the regions and run the increase-asg-capacity command), or go help out with these VIP-related SEV2s because you know how to click through that awful VIP management website. There are certainly opportunities to build automation, but not as many as you'd think because the stories to build it get constantly de-prioritized in favor of new, shinier things.

Do a better job at scaling the team, which means following up with team members to make sure that documentation is written and maintained, and giving more senior members of the team time to mentor them. High attrition is inevitable given the demanding nature of the job.

Invest the appropriate amount in automated testing such that we can be fully-CD on all our deployment pipelines, and not use change control for deployments ever again. Scale or precedence in the stack (i.e. Tier-1 vs Tier-2) is no excuse for not allowing the service to become full-CD, and no excuse for not investing the appropriate engineer time into it.

Take time to really understand and act on the concerns of engineers. Don't just say, "Well, I don't like being on-call either," because that's not a solution, and nobody seems like they signed up for this.