Amazon Software Development Engineer reviews

#1 Issue - Code Quality: Amazon has a leadership principle: "Insist on the Highest Standards." In theory, this means that the code quality should be high. In practice, managers have conflated unit test coverage with code quality. Is code coverage a good metric for code quality? Is it not possible to write incomprehensible spaghetti code with high coverage ratings? The manager still gets to submit a weekly report to the director with a nice, carefully-curated set of visual aids: pie charts and graphs, which business-types love. Meanwhile, the actual code has several problems: a) Many, many branches, with null being used as a sentinel value between interacting micro-services; b) Hard-coded domain knowledge; c) Overuse of semi-dynamic features like Map<String, Object> to bypass the need to write unit tests; d) Overuse of Gang of Four design patterns, with no actual knowledge of the appropriate use of those patterns; e) Extreme verbosity, with simple tasks requiring thousands of lines of unreadable code; #2 - Deadlines: Out of all the Amazon leadership principles, only one actually matters: "Deliver Results." Deadlines are short. Piling on more and more technical debt is encouraged. Promotions are given to the most "productive" engineers, and years later when the product they created can no longer withstand the demands of the market, they have long since left the team. You see this problem in the financial sector too. There is a strong incentive to hide latent problems deep in the software provided it gets it out the door faster, because the person who needs to maintain the software hasn't been hired yet, and by the time the latent problem becomes a real problem, the engineer has already been promoted and is long gone. A constant influx of fresh, low-level SDE-Is is required to maintain these old technologies that are drowning in technical debt. Attempting to sacrifice development velocity as a form of long-term investment in quality is punishable by placing you on a "Performance Improvement Plan." #3 - Primitive Tools: The tools that engineers use at Amazon are very similar to the tools you might find if you were to time travel to the year 2002. Ironically, there are no tools to help improve developer productivity. The "self help" culture at Amazon encourages you to solve your own problems, by yourself, on your own machine, with no help from others and without helping others. The productivity-based promotion system discourages collaboration. The leadership principle "Are Right, A Lot" is interpreted as meaning that only information which can be neatly fit into a graph is worth knowing. Thus, things that don't fit in a graph, such as intangible improvements to the development process, never receive a budget. There is no official support for your development environment, including the cloud machine you develop on and the software you use to write code. If you have a problem, you fall behind and your "productivity" is reduced. Your manager will get very angry with you, and threaten to put you on PIP. If you ask for help, other engineers will slowly start to resent you. It creates a very "wild west" culture complete with the lack of amenities, the aura of distrust of others, the lone cowboy... #4 - Lack of Diversity: Walking through the production floor at any building in the Seattle campus one might be stricken with the question: "Where are all the women?" The women who might be willing to work the hours expected of them, under the toxic conditions one finds in the engineering teams, will likely instead be found working as lawyers for triple the pay. Diverse types of people are not found because diverse ideas are not found. Amazon is so confident in the power of it's leadership principles that any dissenting opinions or personality types are ruthlessly cut from the employment pool by "bar raisers." The people who do end up working at Amazon are almost exclusively young men in their 20s, early in their careers, from parts of the world that have high male/female ratios. #5 - Poor Work/Life Balance: One consequence of poor code quality and short deadlines is that everything is breaking all the time. And in order to keep the lights on, teams have an On Call rotation. The On Call carries a pager and can be paged in the middle of the night when a metric is out of band. The On Call always looks frazzled at all hours of the day for the week or two that they carry the pager. New employees, who have never written a single service and who are hired to help maintain an old legacy system with poor code quality, can be expected to go On Call after 3 months. The will be paged repeatedly for problems caused by other people, including people who got promotions and long since left the team. In theory, On Call is designed to improve accountability and provide an incentive for engineers to write higher quality code. In practice, it socializes mistakes and therefore reduces code quality. There are people who work on the AWS teams work all the time and sleep at the office for just a few hours at night.

Amazon kind of takes from you as much as you are willing to give. Some people choose to do a lot of overtime work and this is not healthy in the long term, nor properly appreciated by the management. Some managers do not realize that the planning is too aggressive and the goals cannot be met in the normal working timeframe. This very possibly happens because devs do not complain about it, but actually hide it, in the desire to come across as extremely productive, even if this means working nights. Also, aggressive planning and deadline meeting leads to techical debt. Sometimes, we get the time to fix it afterwards, but not always. We are often requested to deliver feature after feature on a poorly written codebase. Also, there is not enough time spent on benchmarking new technologies. This might actually help us with frugality and productivity.