Amazon Senior Software Development Engineer reviews

The promotion process is, at best, convoluted. As I mentioned above, I'm having discussions all the way up to people at the VP level concerning Principal promotion requirements, and it's basically a one to two year process to get all of the ducks in a row, so to speak. On top of that, the formal titles and levels don't necessarily match the rest of the industry: what an SDEIII (aka Senior Software Development Engineer) does at Amazon most companies would likely call a Principal Engineer or similar. What we call a Principal Software Development Engineer would probably be a Principal Architect over much of the industry. These issues are, I think, related. The official standard is that you have to be already performing at the next level in order to get promoted. As such, there are a bunch of SDEII's which are doing SDEIII work but haven't yet managed to justify the promotion, a bunch of SDEIII's which are doing Principal work who haven't justified their promotion yet, etc... Because "justifying your promotion" can be so challenging, it makes the lower role look more senior than the title (or even leveling document) would suggest, thus making the problem even worse. SDEII's are expected to look like that SDEIII on their team, who is already starting to look like the Principal under their director, leading to an endless rat-race of more and more difficult promotions. While I support Frugality, there is a term floating around the company which comes up often: "Frupid" (Frugal-Stupid). I don't mind the lack of gym memberships, free food, or those sorts of things, but when you put an employee on a nine-hour flight for business purposes, don't make them sit in the cheapest seats on the airplane and at least let them book Economy Plus or whatever the second tier is. Five-year replacement cycles on laptops honestly leaves experienced employees with machines not up to professional standards and does impact performance. I would complain about the monitors they make Engineers use, but, finally, they just updated that standard to something very usable. On-call can, quite frankly, suck if you're in the wrong team, though they tend to be in the minority. I support engineers being on the line to make their systems work properly, but every team deserves follow-the-sun first line support to handle operational issues which don't fall back into a software issue. This is getting better and many teams do have some form of follow-the-sun first lines. There's a bit of "Management by Paranoia" at times, especially around peak (just before Christmas). The company can be too risk-averse in some ways. Even worse, its risk-aversion isn't always intelligent, avoiding high-value risky projects in order to push out a lower-value one which happens to have the attention of the right VP or SVP.

Ops burden, rushed deliveries, interruptions.