Good corporate values, still small enough to retain that entrepreneurial spirit, but watch out for the pager
Pros
Amazon's decentralized structure gives teams a good amount of autonomy and freedom to set their own roadmaps and schedules. Everyone feels a strong sense of ownership in the systems they build. You are not just a code monkey. The decentralized nature also means that the employee experience may vary depending on what part of the company you work in, so my observations may differ from those of others. (If you're working on base-level functionality such as the order pipeline, you will have different pressures placed upon you than someone working on higher-level or internal-facing features.) One of Amazon's core values is frugality--a fact which doubtlessly helped the company survive the dot-com crash of the early 2000s, and should continue to serve it well during periods of economic uncertainty. This adds a nice degree of confidence in the security of one's job. Upper management attitude is that we should always be innovating, and based on the features the company has launched over the past few years, you can tell they aren't just using that as a buzzword. Amazon is still a relatively young company, so there is still a willingness to experiment. Look forward to the mid-2010 move to Seattle's growing South Lake Union neighborhood. We're building a new campus from the ground up. It's nice that they're using employee feedback in the design process. I've seen some headlines that seem to imply long hours (though I can't read the full reviews yet)--fortunately, that hasn't been my experience.
Cons
The majority of software developers participate in an on-call rotation, meaning you can expect to be paged at 3 AM from time to time. A typical example is one week of pager duty every 6-8 weeks, but the operational load varies considerably from team to team, so be sure to ask about it during your interview. (Typical Amazon development teams I've encountered consist primarily of SDEs with 1-2 management types; Microsoft-style "test engineers" are relatively rare, and all but a few teams handle their own operational support.) What is the line between "frugal" and "cheap"? This is one of the continuing debates among engineers, as Wall Street worries occasionally lead to the tightening of the purse strings. There may be some bureaucracy if you want to request new hardware, and periodic requests to justify your use of resources. This isn't necessarily a bad thing, as efficient use of resources is a good philosophy to have for long-term survival, but don't expect Google-like spending.
