rating for Amazon.com

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 22 more ratings for Amazon.com!

3 comments

Write a comment!