|
> Is there any proof that this gets better employees? I haven't seen a shred of real scientific evidence. Is it anything more than corporate hazing? Hiring is super hard, and anyone who tells you they have a surefire, simply-articulable description of what interview characteristics guarantee a good employee is lying to you. So given that unrealistically high bar, sure, there's no guarantee that this "works". But it definitely extends beyond "corporate hazing". I've done hiring both within Google (interview + HCs) and outside of Google, and while I had to drastically (_drastically_) lower my standards for some of the post-Google hiring (due to crappy candidate pools, usually), the general principle remained the same: these kind of questions provide me valuable info about the intelligence of the hire and this has been _incredibly_ predictive of their productivity in the medium- and long-term. Note that I'm not talking about by-rote memorization of drop-in solutions: when I get the sense that the candidate knows the solution by heart, I mentally "drop the data point". Though I usually have fairly complex, multi-part algorithms/whiteboard coding questions and seeing how people react to mistakes being pointed out, changes in the structure, etc has been very useful. I've told this story before on HN, but there was a company I was employee #1 at where our next two hires were 1) a guy with no engineering experience (he know how to program) but who I could tell was smart and good at creative problem-solving, and 2) a guy with 10 years of engineering experience, good references, and an interview that gave me the impression that he was dumb as a brick. We hired #1 with my recommendation and #2 against my strong negative recommendation. #1 needed a month or two of onboarding guidance by me to learn most of the basic conscientious habits of being a good engineer; he ended up by far our best employee (excluding me, the senior engineer). With a tiny fraction of the engineering experience of the other two, he was (after me), the go-to guy to understand any part of the system or investigate any breakage. By contrast, my founder bounced #2 around from task to task, trying to find somewhere he could be productive without horribly breaking things (legends say he's still searching...). I literally can't think of a single task that he handled even competently, let alone impressively. I had a similar experience at Google with a math PhD reportee who struggled really hard upon joining Google, but after a couple months of my mentorship, was IMO one of the better engineers on the team (it was a research/engineering team, so creative problem-solving counted for even more). It's simply not that difficult to learn the habits and discipline required for good engineering: ability to manipulate logical structures easily, think critically, and problem-solve creatively is IMO infinitely more valuable and infinitely harder to create out of thing air. As much as people gnash their teeth about how algorithms interview questions don't resemble day-to-day work, I've found them to provide a LOT of predictive power for eventual productivity and quality of employee. |