>"Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas."
Who knows why you weren't chosen, but the above quote probably has a clue as to a potential why. Coming away from a failure and concluding "WTF $OTHER_PEOPLE" might have something to do with it. Sorry for the disappointing outcome; your technical skills can take you far, so don't lose hope.
The whole thing was so bad that I don’t think I’d ever like to work there. Maybe I’d go for the crazy money for a few years, but not expecting to work with nice people.
It's easier for companies to have a blanket policy of never telling than to educate everyone involved in the hiring process about the complex and ever-changing realities of employment law, discrimination law, protected classes, etc.
In most cases there's no answer beyond someone else seemed like a better fit for the position. How would it help to know you would have got the job if only this other person didn't apply?
1. It gives them a kind of closure and treats them with respect.
2. It can help them improve for future applications.
Usually, the reason is not "Someone else is a better fit". We're not just trying to fill one position -- if we find good engineers, we'll hire them. Usually feedback is related to stuff that came up in either the coding project or the interview. It helps people in the same way that code review helps them: by giving them an opportunity to learn and improve.
This is an excellent basis for a lawsuit.
(edit: I wonder if we're talking about slightly different things here. The "notes" I'm referring to are primarily code commentary -- the same kind of material we cover in pair programming. As far as I know, we don't share notes about our internal decision-making process, which perhaps is what you're talking about.)
great way to look at what bothers us all after a rejection - thanks
I wasn't there and I don't know why they rejected you, but that five-hour session was a five-hour soft skills test. That you don't recognize this increases my gut feeling that the GP may be right.
If you hire based on, say, STEM expertise, all of your employees will have lots of it. If you then do a study on what explains performance differences among your employees, STEM expertise will look useless, whether it is or not, because your employees all have similar levels of it.
The only real lesson you can draw from that is "don't do studies that have no theoretical chance of revealing any information".
Following your link, I notice that the top two replies are both making the same point.
That's got nothing to do with it, trust me.
That said, a lot of candidates also failed at very basic things (basic coding, cs trivia that everyone should know, experience questions, etc).
If you are really sure in your performance, my guess would be you just got unlucky with one or more interviewers as there seems to be a lot of randomness in the system and they just err on the side of "no hire".
I've also seen people who otherwise did well technically not be hired because they acted like a jerk.
Not saying that any of these necessarily apply to your situation of course, but no one can really know just from an Internet comment.
I'm currently working at a company that I interviewed unsuccessfully at seven years prior to getting the job. If I'd written up some big tell-all about the experience and waited a year and a day to publish it, it might've come up in a Google search from this round and revealed me as untrustworthy.