Re:Google admits brainteasers were useless for hiring (2013)
by sjg007 on Thursday May 31, 2018 @02:01PM
(#17198526)
I wouldn't worry about it. It is their loss.
I would imagine that if Google did a randomized controlled trial among a pool of qualified resumes (say after they pass a phone screen) or a small coding challenge.. that they would find that job performance is not correlated with technical interview performance. They already found that GPA and where you went to school doesn't matter. In fact Bock thinks it's only behavioral traits that determine performance. So here's a challenge to Google or Facebook: ask the behavioral questions, ask some technical ones. Score only on the behavioral and hire. In one year see what the "performance" levels are... I'm guessing they did the latter test where they accepted based on technical performance and ignored the behavioral pieces which is why Bock nows says that behavioral are the most important...
My hypothesis is that the bar is still too high and that if you have a basic technical baseline you'd still perform well regardless of your white-boarding abilities. Google could run this experiment and in fact they might already have enough data to answer it with a causal analysis.
The key issue is how do you define "performance" both in the interview and in your yearly review... nobody has a clue how to actually measure performance.
http://www.businessinsider.com/how-google-hires-people-2013-...
Re:Google admits brainteasers were useless for hiring (2013)
by fjsolwmv on Thursday May 31, 2018 @07:58PM
(#17201379)
You are misreading the research, which showed that after filtering for interview performance, excess programming talent or GPA wasn't important.
Re:Google admits brainteasers were useless for hiring (2013)
by mixmastamyk on Thursday May 31, 2018 @02:12PM
(#17198630)
Yes, a time-consuming disaster, the tech interview has become. Same thing just happened to me yesterday. I'd be willing to challenge the interviewer to an impartial programming competition.
The point of this final exercise was for me to talk through my thought process. It was a debugging problem, and I eventually succeeded, but not without fumbling around for 15 minutes or so. The solution was a stereotypical example of being "right in front of you", but the nature of this exercise threw me off. When I look back, the analogy that makes the most sense to me is the boxing glove wall from the TV show, Wipeout [1]. It's a simple problem of getting from point A to point B with the twist of getting punched in the face, or the stomach, or the leg, at seemingly arbitrary intervals. I can see this as a good simulation for the reality of an engineering job (being faced with unplanned interruptions and having to bounce back from them) but, at the same time, I've never had to verbally talk someone through every keystroke and mouse movement that I make while debugging. I was frustrated with the exercise and with my inability to immediately diagnose the issue. The interviewer was amazing at getting me back into the right mindset after noticing I had fallen off the wagon each time, which showed me just how good of a manager they were. However, the more I realized how terrible I was doing, the worse I performed. I left with the unmistakable feeling of dread having set-up camp in my stomach. Despite arriving at the solution, I knew I had blown that exercise.
In the end, I was turned down. The official reason was that another candidate had accepted an offer for the position, but the hiring manager also told me that my programming skills were perceived as sub-par due to the final exercise. They said I'd be a great fit culturally, and that their team enjoyed the conversations we had, but my Python skills just weren't good enough. Being someone that really identifies with their abilities as a programmer, with Python being my language of choice, this verdict has kept me awake at night. I'll never know if the actual reason was due to the other candidate accepting or due to me being my own worst enemy during the final exercise.
The tech hiring process is one of the only times I've gotten 100% of the problems correct yet still failed. Half of me says that's bad, but another part of me understands in situations that require context like mine above. It's not the manager's job to babysit me when I psych myself out, or when I'm having a bad day. Engineers need to be reliable and stable enough to work efficiently on their own. Had I been alone, I would have found the solution much quicker. But you're almost never alone in a real work environment. Some of these exercises are measuring much more than just algorithmic competency.
[1] https://www.youtube.com/watch?v=0XGmcQPCSG4