My skip-level manager put me on a performance improvement plan there because he said someone else had done 10x as much work as me. It turned out that the other engineer had closed out something like 1 "bug" ticket per day, and I'd closed out 1 "task" ticket per day PLUS some bugs, so I'd done substantially more work.
I just waited until my next stock vesting, then took a severance package and left that rancid shithole. We were working on some retarded dead-end boondoggle of a device, and I'm sure everyone in the org got a frowny face on their report card when it was eventually canceled.
Ironically, I actually had a pretty decent experience at Amazon before that. I guess it just goes to show that the most important thing about any job is your manager and your team.
haha, this was at Microsoft, and the dash button was a glowing success compared to the project I'm talking about
I'd better not dump any more details though, since it's technically still under NDA..
What I'd really like would be a good set of questions to ask as the job interviewee to help me filter out bad teams/orgs. I guess the ability to do that could be considered part of the skillset of a good VP of engineering, though, so maybe it's unreasonable to expect us grunts to pull it off..
It sounded like that story was at Microsoft to me, but now that I know you thought it was Amazon, I can see that it’s ambiguous and could be read either way.
Ah you're probably right that it was at Microsoft. My brain must have forgotten the first line by the end of reading the comment, among all the other Amazon specific stories in this thread.
Zune was actually pretty popular and had its fans for its time, despite getting completely outsold and outshone by the iPod. I think it didn’t get cancelled until smartphones were clearly starting to replace dedicated music players.
If I had to guess it would be the Kin devices that evolved from the purchase of Danger, those things clearly fit the OP’s description: https://en.m.wikipedia.org/wiki/Microsoft_Kin
I knew a manager who wore a suit to every fucking meeting, and would make a point to bring up IC’s CL counts and lines of code changed during calibration / promo review.
He still works there and likely has sway over the careers of countless more competent individuals than himself.
Quitting Google was the best decision I ever made. Good teams are outnumbered by shitty teams with shitty managers there.
Any manager at Google who quotes "lines of code" in any context other than actively defending someone or noting something truly exceptional is doing so because they have no idea what their report actually does, or whether it matters.
Really!!! I am surprised to hear this. I always thought that Google is akin to "Chocolate factory" for programmers where programmer is the king and each and every decision is made by programmers. In my circle, Google is considered to be the final nirvana and a Software Engineer badge the ultimate status of "you made it in life". Even I found their coding interviews so damn hard. In my opinion, they are at least 5-10x notch harder than interviews at FB, MSFT, AMZN and other tier-1 places for comparable level.
Hey buddy, I'm going to pull back the curtains a little on those coding interviews. Solving coding interview questions is a skill that you can learn, just like playing musical instruments or solving mystery novels or mastering a type of video game.
If you hit up TopCoder or Leetcode or one of those other corny interview programming sites and grind away at it for a few months, you can get to a point where you have a really solid chance of getting past any coding interview.
Google is a little sneaky, since they take "Can solve a leetcode question" as a starting point, then crank the difficulty up on the questions even more so you have to be able to solve the base question in ~10 minutes and then expand on it. It's like "OK, you solved the locked room mystery. But now can you talk me through a locked room mystery solution.. WHILE PLAYING DARK SOULS?"
There's a ton of luck involved too. I've run into a lot of interviewers who ask questions they themselves don't actually understand very well. Then I'm in the unenviable position of wondering "Do I tell the interviewer he's wrong? Is it a trick, or is he just an idiot? Is he going to get mad if I tell him?" Another problem is that coding interviewers will ask a question, not try to code up the answer themselves, and just assume it's way easier than it really is.
If you want to get hired by the GAFMAN, just grind out those coding questions (and write working code answers in your IDE of choice or on the command line with vim/gcc). Brush up on your CS when you come across a concept you don't understand. Then get some referrals to get past the HR filter, and roll the dice.
BTW, when you get an offer, don't sell yourself short. Check levels (dot) fyi and/or talk to your peers to make sure you're getting the market rate for your skills.
> programmers where programmer is the king and each and every decision is made by programmers
Programmers at Google make no decisions. The only people 'making decisions' are the product owners and project managers.
> Even I found their coding interviews so damn hard.
A hard coding interview is not a valid metric on how good a place is to work.
> Google is considered to be the final nirvana and a Software Engineer badge the ultimate status of "you made it in life"
I've known people who feel like this as well. Some of them are still at Google and it's the best thing they ever did for their career.
On the other hand, I know people who felt this way, got a job at Google and it completely destroyed any passion for programming/computers that they had, to the point where they never worked in tech again.
Personally I feel it's dangerous to attach "you made it in life" to getting a job at Company X.
My general impression is that there are only three broad ways to be happy in life:
1. Genetically (i.e. your brain just works that way)
2. Luck into it
3. Iterate towards it (continuously)
The whole concept of "get job X and now I'm done" doesn't really fit well into any of those. A job could be a good iteration or you could get lucky and have it turn out to be a wonderful team/position/whatever, but the likelihood of your plan being "I need to do x" and then you do x and are then happy seems immensely unlikely. Like Samuel Johnson said, "Life is a progression from want to want, not enjoyment to enjoyment."
It used to be, long ago. Lots of other places caught up and they went down.
Of course, like any very large companies, it's going to be fragmented. Some groups at Google are really that awesome. Some are awful.
It's no longer "the place to be" for the top engineers though who will frequently pick other places, though it does look good on your resume.
For the interview being harder, they give you a flier that tells you almost exactly what they're going to ask, and they expect you to prep specifically for those things, so it's a lot more of a test of will than a test of skill. If you "really want to get a job there", you just cram your head with whatever the PDF says you should know and repeat it during the interview and you should be in. It's of course not that simple for people with personal situations that prevent them from just cramming reading material, and they're somewhat famous in some circles for discrimination (especially gender based, from anecdotal evidence).
Its unfortunately pretty common. Measuring perf that way is bullshit.
It is, however, still a useful signal. It should never be how the final decision is made, but in orgs where managers have way too many reports (which is a separate problems), it can accelerate things a bit.
Eg: look at the team's or orgs LoC/Commits over a long period of time in similar roles (long enough to smooth out outliers). Then if someone is DRASTICALLY underperforming (like, 1/10th of the output), you don't jump to conclusion. You starts looking at the code itself and ask questions about the projects, get opinions from the rest of the team, etc. Stuff you should be doing ANYWAY, but with a little more focus.
Based on -those- data points, then you can start making a judgement call. But yeah, any manager who stops at the SLOC or number of commits to make perf decisions is awful.
I actually worked with a manager who used number of commits exclusively. He also did not know about squash + merge workflows. So people who squashed would get in trouble and those who didn't would get raises until someone in the team finally figured out which metrics he was actually using. That was so sad...
it's not the only thing they measure. but if you're at the front end of a project, you often don't have other metrics (issues closed, internal customers giving you props, etc.) so the classic (and mostly flawed) measures of performance are used.
It should also surprise no-one that design documents are not considered deliverables, only code. There's no motivation to fix a crap design. You generally have to do the absolute minimum documentation your management chain will accept, then push out some code, let it fail, then redesign it in your spare time and start pushing out incremental changes as part of your bug fixing work.
I never saw anyone intentionally build crap designs / code so they could then get props for fixing the bugs they introduced, but there were several times people didn't have time to think through the problem and built crap code that led to sev 1 / sev 2 problems. People weren't trying to build crap code, it's just a side effect of being judged on how well you implement code, not on how well you design systems.
I have given this feedback for a person at Google who made fewer than five commits in a year, each with just a handful of lines. The lines were good, so it wasn't about the quality of the work.
This is my favorite kind of Google story. It doesn't happen all the time. But I've seen it...where a person studies the problem for a considerable period of time, followed by a minimal and precise solution. Those are often followed by mass deletion of newly superfluous code. And those are generally worth a team celebration!
It doesn't, a bad manager (allegedly) did. Having said that, having say 50% fewer commits than your peers is probably a reason to dive-deeper...it could be a good thing, maybe you were unblocking tasks and writing docs, or tackling the thorny issues...but also could be you are less productive.
Current engineer at Amazon. Maybe a particular bad manager is doing this, but there's no institutional mechanism where management or executives literally count people's commits.
Worst case, you're on a team who's late on deadlines and you have 0 commits in the past several months. Yeah, there are going to be questions about where people's time is being spent and are those the right priorities. Aside from that, people aren't comparing commit counts to stack employees. The simplest reason is – it's much more expensive to let go someone and re-hire and train another engineer. You won't hear about that on any of these news stories because it's not so attention grabbing or interesting.
Amazon for sure can do better in many areas. No denying that.
But keep in mind we have a massive workforce of engineers. If 1% of them are unhappy, and even 5% of those unhappy people are willing to post about it on Reddit, Hacker News, Leetcode, or where ever, you're going to feel like every person at Amazon basically hates their job.
And the other thing is the people who do respond with positive experiences don't get the "upvotes" and get their experiences pushed to the top of the discussion. They often get down ranked and personally attacked.
Lastly – No one is counting lines of code. This is actually a pretty absurd claim, and I can't say it's NEVER happened, but anyone doing that is a wrong hire. Less code is generally better. There are no brownie points for more code or more complexity. Amazon's leadership principals encourage frugality and invent and simplify.
EVERY manager I've interacted with at Amazon looks at CRUX statistics -- it is the actual reason that they exist.
My current manage (5 year badge employee btw) is counting my code. We are both L6s and he has shared with me the various target CR each level is expect to do (per week).
For L6 it is 4 (in the AWS org) per week.
The leadership principals also say "hire and develop the best", which ought to mean that they would be doing the damnedest to keep people.
But they don't. I've seen three people Pivoted in the last 6 months -- two of them had been with Amazon (AWS) for over 4 years.
These people did not "suddenly" become bad, or shit at their job, or etc. What happened is that they were stacked ranked, and they were at the bottom. The job was, and remains, exactly the same.
Which is why stack ranking is stupid. Same job. Same person. One year you are meeting the bar. The next you are the worst at it.
I've seen "lines of code" used against someone at Amazon before. I'm sure the manager knew that it isn't a performance metric, but the manager had to hit a Unregretted Attrition (PIP) target so they just threw whatever they could think of at the person.
The institutional mechanism behind this insane thing is the URA target, just like many other insane things posted in this thread.
I had relative number of commits mentioned as part of my negative performance evaluation. I was working on a project involving a long information gathering phase and a long design process for the architecture, but that wasn't considered an excuse. It 100% depends on your manager, though. I think managers might feel forced to make a comparisons and put an otherwise acceptable engineer on the bottom of the stack. Lines of code and commit count is a pretty low-thought way of doing that.
oh man. that is the kiss of death at amazon. ALWAYS BE CODING. ALWAYS BE COMMITTING. My director told me they looked at commit cadence, KLoC and (ugh) story points retired per sprint because it was something they could measure. You can measure code that compiles vs. code that doesn't compile. Architecture docs and designs can't be automagically evaluated; there's a lot of subjective judgement as to whether or not they're useful.
It seems unlikely this is universal, but at least in my management chain, focus on code was definitely a thing.
Amazonian here, I speak only for myself. FWIW, 4+ years in as an SDE and I've never been judged on that metric. If I had a manager like that, I would do what's best for my career. :-)
