1. If you are a new grad hire, they may place you on a team that has nothing to do with your interests or what org you were told you would work for when you accepted the offer. Even if you have 0 experience in that area. I've heard this from at least 10 people. It seems to be common.
2. Extremely high operational load, especially in Retail.
3. "Fail fast" approach and unrealistic deadlines have lead to shortcuts being taken, widespread tech debt, and a very serious retention problem. Even the engineers that stay at Amazon switch teams every 2-3 years.
4. Hardly anything is documented (including widely-used services and tooling). Building almost anything requires constantly engaging other teams, who are often unresponsive or unhelpful. Tribal knowledge is lost when people leave the team (in my first year, 80% of the 20 engineers on my team left - and this is not uncommon). Imagine that you have to write an app using a web framework (AngularJS, as an example) that you aren't familiar with and you must call 5 services with undocumented APIs. You aren't allowed to use any documentation at all, or refer to any books on AngularJS. You do have an IDE, and can contact the creators of the services you need to use. This is exactly what it is like developing at Amazon. It takes the fun out of it entirely, and makes building anything much harder than it should be (compared to using off-the-shelf tools/libraries and documented APIs). Amazon has been lauded for adopting a Service-oriented architecture; what isn't mentioned is that none of the services are documented, even though they have (usually multiple) clients.
5. Culture is very cult-like.
6. The company highly values fresh-out-of-college hires. They believe that potential is everything. In software engineering, though, experience can be incredibly important, too. I suspect they prefer college hires because it is much easier to get them to overwork, and they are less likely to have families. College teaches data structures & algorithms, but not software best practices. Code quality is often very poor.
7. The work is challenging only due to the complexity of figuring out what is undocumented, interfacing with other teams, etc., not the actual coding part.
8. Very difficult to change any entrenched practice, even if it can be demonstrated to be ineffective and better alternatives are available.
9. Management is typically very short-sighted. Schedules are determined by when higher-level mgmt wants a project to be completed, and all projects must be completed by the end of the current calendar year. Usually there is little to no input from the actual engineers. All that matters is if the code meets the goal or not, with little if any consideration on whether it is a ticking time-bomb that will be unreliable and require frequent maintenance. Most code at Amazon is not robust, and requires 24/7 oncall coverage for frequent breakages.
