I still can't believe that Amazon measures performance by "numbers of commits" and "SLOC". Pure insanity.
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.
It was the amazon dash button wasn't it.
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..
Best idea is not to go somewhere without having friends on the inside who you trust and can tell you what it's like.
Zune music player?
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.
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.
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."
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.
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).
I don't understand why it matters what people wear as long as it's not offensive...
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 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.
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.
The institutional mechanism behind this insane thing is the URA target, just like many other insane things posted in this thread.
It seems unlikely this is universal, but at least in my management chain, focus on code was definitely a thing.
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.