Amazon System Development Engineer II reviews

Raises and promotions are hard to come by

* 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 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 and 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, and 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, e.g. go figure out how much of these types of capacity we need in these regions and then increase the EC2 ASG capacity before we rollout 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