Hacker News Reader

Comment by lakevieew | Hacker News Reader

I had joined Amazon as my first job out of school. I was super excited and would not mind working the long hours as the project was interesting. I enjoyed working with my team and manager. Just near the end of the year, my manager quit. The new manager ran my performance review and assessed that my performance didn’t meet expectations. I was not put on PIP. Instead, there would be a development plan that I had to complete. I was shocked and tried hard to not cry during my review. I had never been told earlier that there were any issues with my performance.

This review crushed me. It destroyed my confidence in my programming abilities. To be fair, I had made some mistakes during my first year at Amazon - had fewer commits and SLOC compared to my teammates. Being on a work visa meant I could not quit immediately. I had to endure working there for almost a year before I got a new job.

I took me quite some time to gain back my confidence. To this day, my time at Amazon makes me dread performance reviews.

View on HN

> had fewer commits and SLOC compared to my teammates

Hope this makes you feel slightly better: https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

It is impossible to measure someones productivity using metrics like commit counts and SLOC. There are times where I don't commit for weeks and provide actual business value by solving direct client issues without even a ticket being present.

At one time at my second IT job, I had a manager reprimand me (yelling over the phone) that I was away from my desk. I was remotely supporting a bank fixing consortium credit contracts (substantial amounts) after a migration. I was told to stop doing that. So, I told the support tech that my 1-up blocked this. He told the people at the bank; this went up the chain at the bank to the main accountants which resulted in a nasty call from the client to the skip manager of my manager. He called me back and asked me to resume what I did almost crying on the phone. Later that year I was selected employee of the year mostly because of that client constantly sending positive feedback on my help.

What do you think the reprimanding manager's motivation was? The possibility that you were doing work he wouldn't get credit for?

He assumed I was not working or doing work for a different manager (they implemented matrix management and he was at HQ 70 km away from the town I worked at). I made a judgement call as that migration was a $20 mln project. That corporation had time budgeting. I was supposed to account in a production tracking system every task I did in 15 minute granularity. I have a ton of crazy stories like that out of that place.

In essence, the guy was a micromanager with trust issues. They later replaced him, with someone that was actually worse.

> In essence, the guy was a micromanager with trust issues. They later replaced him, with someone that was actually worse.

At least it had a happy ending… oh wait.

out of the frying pan into the fire...

Unfortunately at Amazon, that is the norm. When the review time comes, 90% of the orgs will use the no. of Code Reviews raised and no. of commits pushed as the first line metric. Impact, customer focus and everything else is secondary.

I still can't believe that Amazon measures performance by "numbers of commits" and "SLOC". Pure insanity.

I wonder if people who are hired are being told about that before signing their contract.

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. :-)

they don't

To be fair, some morons at Microsoft do it too

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.

>retarded dead-end boondoggle of a device

It was the amazon dash button wasn't it.

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.

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..

was it a talking staple?

Just ask why they like working there. Ask for specifics. Ask for things they don't like. Ask for specifics.

Best idea is not to go somewhere without having friends on the inside who you trust and can tell you what it's like.

>retarded dead-end boondoggle of a device

Zune music player?

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

It has to be the microsoft mood bra, right?

Morons at Google do it, too.

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.

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.

> 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."

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.

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).

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.

> I knew a manager who wore a suit to every fucking meeting,

I don't understand why it matters what people wear as long as it's not offensive...

When you’re in a room full of people in normal casual attire you’re going to stand out like a sore thumb in a suit.

Or it's just an "objective metric" to use in a paper trail to fire a person.

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.

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.

um. no. or rather, yes. any manager (or co-worker) can decide to ding you based on your KLoC metrics.

There are lies, damned lies and CRUX statistics.

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.

This has been my experience and every org that I know as well. Blind agrees too. The guy above you seems like an HR plant.

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.

God damn, getting paid 250k a year to write about 500 LOC. Madness.

If each line you commit is worth more than $500, then it's not at all madness.

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!

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.

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.

I had a similar experience. I had a great manager on a very insulated, experimental team working fast and delivering results. Our Program Manager changed teams, soon our Product Manager changed teams, and we got merged into another team with new managers. I was told by my old managers I was on track to promotion and found out at the end of that cycle that I had a negative performance review and it was going to be even longer. I was delivering during this, but so was the whole team.

I swapped teams hoping that a new manager for an old colleague's team would be better and things didn't really improve. I stayed for a year before quitting due to my mental health. I think it can be hard to find the right team at a big tech company and even if you do, there's no guarantee of how long it will stay that way.

that's very similar to my experience. i swapped managers about a year in and my second manager put me on a PIP. except that it wasn't really a PIP, it was just him saying "i'm putting you on a PIP." -- I didn't know the difference until I had left. A friend in HR told me (after I quit) that managers do this to try to get more performance out of people. If you're on a PIP, HR will be involved.

Also, the best C++ coder I know got dinged 'cause he was refactoring huge amounts of redundant code checked in by a different developer. I think he was eventually able to convince his management chain that DRY is a good thing and got back on the promotion track, but not before the other developer (who introduced a metric crap-ton of crap code) got promoted. After taking a metaphoric crap on our project, he then left for a different team. It took two years to fix the codebase.

A real PIP always has HR involved. Note to any Googlers: If a manager tells you you're on a PIP, feel free to reach out directly to HR and ask for information about it. Or your skip level, who will be pretty surprised if it's not a real one, and probably not too happy about it.

On your second example, this is where having senior technical people in the calibration room is really important. The key there is ensuring that said technical people know about the work before they are in the room. It is really difficult to change outcomes after the fact. You can't expect them to defend something they don't know about.

You need an attitude readjustment. Your problem isn't the bad review; it's that you care what some big co apparatchik thinks about your work. What qualifications did your boss have to evaluate your work, other than his position assigned to him by fiat?

Being a successful middle manager in a large corp entails smiling when you're expected to smile, feigning frustration when you're expected to feign frustration, showing up to the meetings you're expected to show up to, and writing the documents you're expected to write. Your problem is that you think of them as people. They may be people outside of work, but at work they're a neural net that simulates the averaged behavior of other middle managers in the corp, and then tweaks it to locally optimize their own comp. That has fuck all to do with your programming ability.

It's of course possible that you suck. In fact, it's likely, because most people suck-- excellence is the exception, not the norm. But judging your own programming ability by a column in some HR database that your NPC manager filled in? That's bonkers, man. That feedback is at best a very weak signal for it. More likely you can disregard it altogether, but that's somewhat dependent on the situation. (It is, however, a very strong signal that you're low on the corporate totem pole and can be dispensed with with little risk to the manager in question)

The proper response to a new manager assessing your performance (regardless of whether the assessment is positive or negative) is "umm, and who are you?" Don't say that out loud, but that's roughly what you ought to be thinking.

Reply on news.ycombinator.com