rating for

1.0 Company Won't Grow Up posted by rash on October 08, 2006

Experiences recent as of 2006.

Classical problem of mid-life company that still pretends to be a start up. Continues to use processes that though once somewhat successful, don't scale to the current size of the company.

Launch fixation. Amazon is always looking for new business at the expense of everything else. Maintenance to existing, even mission critical, software limited to 3 a.m. pager panics and quick band-aid fixes. Lots of really bad old code to muck through, with little or no documentation. High turnover means not even tribal knowledge is available. Some mission critical areas were unstaffed at times. I mean EVERY SINGLE PERSON working on those areas from senior management on down had quit and not been replaced.

Software rushed to meet patently unrealistic deadlines without thought towards long term maintenance and extensibility. Of course hitting the current launch schedule is frustrated by the unworkable code base that resulted from hitting the previous launch schedules. It's a vicious cycle in engineering (unlike the virtuous cycle that underlies the business). Value of engineering assets goes down with each project cycle.

Amazon hires smart people, but proves a frustratingly unproductive environment to work in. Instead of "getting things done", too much time is spent fighting the tools, fighting other teams, babysitting the pager, babysitting the fragile database infrastructure, etc. Amazon is the antiGoogle: 20% time spent working on actual assigned project, 80% wasted on overhead, +20% pager duty.

Poor cooperation between teams was especially frustrating. Interaction strategies limited to bully, lie or ignore. Hard to get some people to return calls or email. Managers of other teams would commit to doing work in meetings, with full intention of not doing so in fact. It sometimes took several meetings with several teams passing the buck to get one to even admit ownership of a critical software module (let alone commiting to work) -- and only when I cornered them by showing a 'paper trail' that took me three days to put together!

Maintenance burden ranges from headache to nightmare. Rather than fixing, the solution to previous hacks and shortcuts in software is pager rotation. Constant reinvention without replacement, so instead of one good solution to a particular problem, Amazon has several bad ones (e.g. multiple middleware solutions -- if your app had to interact with six others, you'd need seven different technologies to do it). Code base consists of several generations of overlapping and competing technologies and half-completed projects.

Much of this results from signicant engineering decisions being left in the hands of inexperienced or junior engineers (or those with just plainly bad engineering sensibilities) with little review or oversight. Some employees received accolades for keeping a bad system going with hacks, manual work-arounds, etc., rather than fixing them once and for all, while great engineering, because it simply worked and didn't cause panics requiring such heroic efforts, went unnoticed and unrewarded. Visibility is rewarded over productivity.

Frugal is not spending money on things you don't need, cheap is not spending money on things you do. Amazon is cheap when it comes to engineering. To much homegrown software where superior solutions exist in the marketplace. In house toolset has same problem with poor software and documentation as all other software.

Weak management. Too many of the managers are the previous generation of engineers who are responsible for the current mess, so don't see "what the problem is". Too many inexperienced and junior managers.

If considering interviewing with Amazon or accepting an offer (and coderific reviews haven't scared you away), my advice: Even if recruiters initiate contact, insist on picking the teams that will see your resume (just go to careers section of website). There is a lot of difference in quality of teams, so DO NOT let the team pick you. If you don't like the first teams, ask to go through the interview loop again with different teams. Push hard on a high salary number over signing bonus (which will go into your total comp at review time anyway) and RSUs (you probably won't last long enough to see the bulk of these anyway). Insist on actual job title and pay grade in offer.

Too much interview time spent solving generic programming problems that bear little relation to the actual work at Amazon. Amazon interview process does a bad job overall representing the actual work. Insist on details of actual job duties during interview process. Don't let weak or evasive responses slide.

Some pros. Good place to go for a year or two to learn e-commerce from the inside. Most employees are pleasant to socialize with. Interesting approach to metrics (though sometimes misapplied). Salary is moderately high for Seattle area, although only average to amount of work hours expected. Though there's little to learn here about software engineering (except in the negative), some of the business concepts are interesting. And if you last five years (odds say you won't), you'll likely be one of the more senior people in your group! (Is that really a pro?)

Summary: Smart people, stupid company. If you TRULY are a superstar, your talents will be wasted on Amazon.

See 24 more ratings for!


Write a comment!
  • Re: Company Won't Grow Up posted on February 12, 2007 07:17 PM

    Rash nails it on the head. Though, I think he's a bit to nice to the company in some areas. Management, at least in the areas I saw, was flat out incompetant up and down the line.

    Basically, Amazon engineering is a bunch of 1-3 year experienced engineers, half of whom are not US citizens and are shy or otherwise can't communicate well, all of whome have a lot of innate intelligence, but on average, not a lot of real engineering experience.... these are the good guys, and they are managed by, on one level up, engineers who have simply been at amazon long enough to get promoted, or non-engineers brought in to manage engineers. Above that first level of management, its non-engineers all the way to the top. So there is no product planning, no rational orgianization and no actual engineering going on.

    Amazon is the epitomy of a code house rather than an engineering shop.

    On the upside, if you want a comfortable job, are unmarried, and want to coast by with 40 hour weeks and a good salary... its a decent place to while away the hours. Especially if getting paged at 3am is ok because you were already up at 3am.

    Unfortunately, eventually you end up with a boss who then expects you in at 9am, even though you were up from 3-4am fixing some problem that is ultimately the fault of his incompetance. IF you can do that, and not get mad at him when he chews you out for not being there at ten, then Amazon is perfect for you.

    reply | quote

  • Re: Company Won't Grow Up posted by rash on March 10, 2007 07:46 AM

    Thinking about it more, Amazon is a sort of boot camp, especially for new grads. Most stay a year or two and move on.

    Having worked at my next job for a while, it seems that everyone here is moving in slow motion. I hadn't realized how much my Amazon experience had changed my perception until after leaving -- I was too busy hating the place while I was there. I get impatient now when something takes longer than a day to happen -- because I know it can be done faster. I manage my own time better. Having a whole day to work on a new project without constant interruption seems luxurious.

    Now, don't get me wrong -- take the usual trinity of quality, time and cost (good, fast and cheap, pick two, yadda, yadda), Amazon definitely locks in on time and cost. Do the math. Quality suffers. A lot. It's almost assumed solutions will be low quality. So you'll have to go elsewhere to learn about quality and proper engineering. And once you've learned that, how to balance all three variables (and scope).

    I already had that background in quality and engineering coming in to Amazon, which is likely why the experience was so unpleasant -- because I knew a better balance could be struck. And Amazon is suffering because of the lack of quality in its systems (operational overhead diverts bandwidth from new ventures, or to not be a geek wonk about the wording, fixing the old shit takes too much time away from building new shit -- and by fixing I mean jury rigging a hasty repair, not fixing fundamental problems once and for all -- and all that operational overhead does not open new revenue streams.) If Amazon ever found that balance, it would be a juggernaut (imagine Amazon with decent engineering and without the operational nightmares). But it isn't, and isn't trending that way either (in fact, quite the opposite).

    Beware of lifers though (as much as the term fits in such a young company). People who started their careers with Amazon, or came in without prior experience in quality and engineering, have dysfunctional notions about quality -- they truly don't see the massive problems in their engineering. It's not a question of emphasis on fast and cheap, but a blindspot that means these people are simply incapable of factoring quality into their decisions (which means the decisions are grossly sub-optimal). So don't sweat quality issues while you are there -- you can't fight the sea. Just wait for reincarnation in your next job.

    If the preceding paragraph sounds like you, leave Amazon already FFS. Test yourself in the real world -- Amazon isn't as top of the heap as it likes to think.

    reply | quote

  • Re: Company Won't Grow Up posted by Tamerlin on January 31, 2008 10:45 AM

    I'm sorry to say that my experience here so far jives with yours. Quality is rare here, and most of my group is dedicated to maintenance and integration, including me. This is particularly galling having relocated cross-country like many others because the job description sounded pretty exciting, and the reality is almost exactly like what I left, only the code is amazingly even lower in quality, higher in complexity, and the problems that it's intended to solve aren't particularly interesting or challenging to begin with.

    reply | quote

scores in this rating

development process

clear requirements 1.0
design and planning 1.0
quality assurance 3.0
automated testing 2.0
peer review 2.0
development environment 1.0
development hardware 2.0
physical workspace 1.0
infrastructure and support 2.0
issue tracking 2.0
source control 3.0
product quality 4.0


cultivation of creativity 4.0
mitigation of risk 1.0
reasonable workload 1.0
prevention of crunch time 1.0
hitting deadlines 1.0
taking responsibility 3.0
development autonomy 3.0
keeping ego in check 1.0


salary 3.0
health coverage 2.0
paid time off 2.0
snacks 2.0
other perks 1.0


advancement opportunities 1.0
employee retention 1.0
hiring process 1.0
quality of development management 1.0
quality of upper management 1.0
quality of developers 2.0
team-to-team communication 1.0
internal team communication 2.0
management-developer communication 2.0


location 4.0
nearby food 3.0
business model 3.0
cool technology 2.0
vision and strategy 3.0
warm fuzzy feeling 2.0
overall 1.0


casual dress code 4.0
use of Free Software 4.0
development of Free Software 2.0
use of GNU/Linux 4.0
use of Mac OS 2.0
use of Solaris unrated
use of Windows 2.0
use of BSD unrated
use of Python unrated
use of Perl 3.0
use of Ruby 1.0
use of Lisp unrated
use of Java 2.0
use of C# unrated
use of Objective-C unrated
use of C unrated
use of C++ 3.0
use of PHP unrated
use of ASP unrated
use of legacy languages unrated