rating for Amazon.com
posted
on
July 26, 2010
===============The problem with trying to numerically evaluate SDEs, is that each employee is doing different projects with different co-workers. One SDE may do 6 small projects and fix 30 bugs caused by other people in the space of a year. Another SDE may do 1 project only in the space of a year. How do you compare these different workloads? If you do 6 different projects with 6 different managers in a year, and you get 1 bad review out of the 6 then you can get fired. However if you stick with 1 large project, then you are less likely to get a bad review even if you do much less work. Quite frankly doing 6 different projects in 12 months is more difficult than doing 1 project in 12 months, because you have to learn much more about the undocumented codebase.In my review I named managers that liked the work I did. However my manager did not reference any of what these managers said in my review. My manager just honed in on one bad review, which was a mistake because the code was working fine until two different projects submitted code that altered the same functions at the same time. The problem was known and fixed internally. So this bad review was the result of a misunderstanding. One wide-boy SDE just jumped on this problem to look good at my expense. There never was any problem with the code I wrote, it was just another totally separate project submitted code into the same functions at about the same time.There was one bug that my manager suggested a hacky fix for. He attacked me in the review for not thinking of this fix. However this was unfair because I was not familiar with this area of the code because I had never worked on it before. As I had recently moved sub-groups this area of code was not even the responsible of the old sub-group I was in. The sick joke was this manager's hacky fix DID NOT EVEN WORK. So I was attacked over not thinking of something that did not even work. I had to remove this manager's hacky fix from the codebase after problems with it were noticed. Yet the attacks on this went on even after I had told the manager about this. Did they even read what I wrote and listened to what I said during the review? Obviously not.After being at Amazon.com for a few months, my workload increased enormously. I was working evenings and weekends. I was assigned one smallish project to do. The project manager for this project was different to my actual manager. My manager told me project managers can't tell you how to allocate your time, only managers can. While I was doing this small project my manager constantly gave me bug fixes (in projects I wasn't a part of) to do. In fact I was interrupted seven times during this one small project. I told the project manager of each interruption. At one point my manager told me to drop the project and then he ran off. I looked for him in his office but he wasn't there. I was going to tell him I just needed 30 more minutes on this project and then I could put it to one side and another employee was depending on this work. So I couldn't work on this project anymore. As another employee was being held up the project manager piped up. I had previously told my manager that I was being overloaded with work, but he just replied Amazon employees should be able to multitask. At my review I was criticized for the last interruption, although there was nothing I could do about it. The fault of my manager was that he didn't stick up for the SDEs enough. This was a management problem of giving all the bug fixes to people (i.e. me) with small projects and not making the people doing longer projects take up their fair share.The whole review was a joke. The people responsible for it should be ashamed.A Colleague Was Fired But Management Didn't Know What He Did Last
=========================================================A fellow group member of mine was fired. Well actually he was in a different sub-group of the same group. I didn't really know him that well. I had only spoken to him once or twice. A couple of projects he was working on were passed on to me. My manager just told me to push out the projects as fast as possible. I was not familiar with the background of these projects or what had gone on. My new manager just assumed that the project work was mostly or totally completed and only needed some QA. After looking through what code had been written I finally worked out that very little working code had been written for both projects and one project only consisted of cut-and-pasted code from a totally different bit of work. Obviously the code did not work, not because it wasn't buggy code - it was totally the wrong code! Maybe the guy had no real time allocated to do this work. Actually his experience was writing code in another language and so he was at a disadvantage doing this kind of work.As such I never had any time to work on these projects and I was constantly given a stream of bugs to fix caused by other groups and people. I finally managed to finish both projects and my code worked first time around.But it just shows my colleague was fired and management had no clue what he had been doing in the last months.What management should have done is waited until this guy had finished and pushed out his project work instead of firing him before the work was finished. The incomplete project work was handed to me and then within days or weeks of being handed this work, I too was told I would be fired!!!!You're Fired, But We Expect You To Work A Few Weekends Before You Go
============================================================Thinking back it was just crazy that I should effectively told I was incompetent, was fired, had to work my last two or so months and then was asked by the management of the group to work on some weekends. I also was woken up at midnight to fix some major problems (not caused by me). Why did management not think this state of affairs was crazy? I could have easily have told them I was fired and they should fix their own problems when I was on-call in the early hours of the morning. But I did not.The Arrogance
=============
Amazon.com may have achieved great things, but when I was there (circa 2001) areas of the code base were mostly undocumented and fragile. A great deal of my work was fixing problems causing by other groups, people or bad process. Yet despite this my manager had the bare-faced arrogance to attack me again and again over unresearched and imaginary problems. How could I be incompetent when a lot of my job was to fix problems caused by other people (well maybe this happens when the code gets very complicated)? Since I have left Amazon my software works first time around and has thousands of happy customers. I make a living that does not involve waking up at odd hours to keep buggy systems alive.The End
=======The most disappointing thing about my time at Amazon.com, was not that I lost my job (although the procedure employed by my manager was awful - I should have just been fired instantly instead of the procedure dragged over months), was that what I am competent at was wasted. A lot of my time was fixing bugs, being woken up at 6am and midnight for false alarms and not actually writing real software.Now that I'm out of Amazon.com I have managed to make a difference. In my small area I've managed to create software that managed to maintain several advantages over the competition for years. People congratulate me for what I've done rather than dragging me down in a quagmire.Summary
========
Although I was told I was being fired, it took months for the process to complete. During this process I still was woken up at 5/6am in the morning for false alarms, had to work weekends (pager duty, sharing pager duty etc) and had to wake up in the middle of the night to fix problems (not caused by me!). Despite this work my manager threw complete nonsense in my face during this period. It was shameful.
See 24 more ratings for Amazon.com!
0 comments
Write a comment!| scores in this rating | |
|---|---|
development process | |
| clear requirements | unrated |
| design and planning | unrated |
| quality assurance | unrated |
| automated testing | unrated |
| peer review | unrated |
| development environment | unrated |
| development hardware | unrated |
| physical workspace | unrated |
| infrastructure and support | unrated |
| issue tracking | unrated |
| source control | unrated |
| product quality | unrated |
culture | |
| cultivation of creativity | unrated |
| mitigation of risk | unrated |
| reasonable workload | unrated |
| prevention of crunch time | unrated |
| hitting deadlines | unrated |
| taking responsibility | unrated |
| development autonomy | unrated |
| keeping ego in check | unrated |
compensation | |
| salary | unrated |
| health coverage | unrated |
| paid time off | unrated |
| snacks | unrated |
| other perks | unrated |
organization | |
| advancement opportunities | unrated |
| employee retention | unrated |
| hiring process | unrated |
| quality of development management | unrated |
| quality of upper management | unrated |
| quality of developers | unrated |
| team-to-team communication | unrated |
| internal team communication | unrated |
| management-developer communication | unrated |
general | |
| location | unrated |
| nearby food | unrated |
| business model | unrated |
| cool technology | unrated |
| vision and strategy | unrated |
| warm fuzzy feeling | unrated |
| overall | ![]() |
preferences | |
| casual dress code | unrated |
| use of Free Software | unrated |
| development of Free Software | unrated |
| use of GNU/Linux | unrated |
| use of Mac OS | unrated |
| use of Solaris | unrated |
| use of Windows | unrated |
| use of BSD | unrated |
| use of Python | unrated |
| use of Perl | unrated |
| use of Ruby | unrated |
| use of Lisp | unrated |
| use of Java | unrated |
| use of C# | unrated |
| use of Objective-C | unrated |
| use of C | unrated |
| use of C++ | unrated |
| use of PHP | unrated |
| use of ASP | unrated |
| use of legacy languages | unrated |
