Amazon 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.

Teams in amazon are very, very independent. So much so that some of them might as well be in a separate company for all intents and purposes (some of them technically are). So there's bound to be bad teams and good teams. In the good teams (which I believe would be most of them), the high standards and expectations push you to transform yourself into an extremely well rounded Leader+Engineer. But, the same standards can crush you if you aren't smart enough. If you're having to work 10-12 hours a day to keep up/stay ahead of the curve, then you aren't smart enough.