4 ms·

> Google's brainteasers did not lead to quality candidates This is why we at Google don't (or shouldn't, at least - it's widely discouraged) ask brainteaser qu

> Google's brainteasers did not lead to quality candidates This is why we at Google don't (or shouldn't, at least - it's widely discouraged) ask brainteaser questions in interviews. I disagree on whiteboard coding though. I don't find it that easy, but I think it's reasonable to expect a demonstration of relevant skills before you hire a candidate. Any sensible interviewer won't expect syntax-perfect code on a whiteboard, but it's at least a way of seeing if the candidate can walk the walk rather than just talking for an hour. > I guess I do not see how you can lose if you take the contract-to-hire approach .. For the first month, the vast majority of people are relatively unproductive. After the next month, good candidates are generally still going through a significant learning curve. Contracting several candidates for a few months to pick one who seems good enough is expensive for relatively little output - apart from salaries, they need desks and computers etc, and you have to do some interviewing to pick them in the first place. It's not a worthless approach, but I don't see it as a panacea.

RogerL 13y ago
Well, the person that referred to the article used the wrong term. Certainly brainteasers don't work, and they have been prohibited at Google for awhile. But the recent article stated that there was no correlation between interviewers and job performance. That the beloved hash table, distributed computing, priority queue, red-black tree questions that you pepper people have nothing to do with the quality of the person you hire. Which I have argued many times on here, should be glaringly obvious. Measure what you want to measure. I have never said "I'm so happy we hired Jane, she just tore up that smart pointer implementation yesterday". I like and dislike colleagues based not on comp sci algorithms, but whether their code is readable, how many bugs are in it, how quickly they can produce production quality code, whether they are responsible and hit deadlines, if they ask for help when they need it, if they offer help when other need it, if they are creative, if they are doers and achievers, if they take baths (seriously), if they step out of their office and interact once in a while, if they are problem solvers, if they read and keep up with their field, if they are capable of learning, if they write good documentation, if the client likes them, if I like them, if younger people look up to them, if older people feel some pressure because here is somebody up and coming, if when I go to modify their code I only need to change it in one place, and my change fits in naturally without breaking 15 different things (because it is designed with extensibility in mind), and that my heart beats a little faster because their code is just so beautiful. And so on. Google doesn't try to measure any of that. At all. And then you (google, not you archangle_one) express mystification at why your interviews do no better than chance. There's a clue there, I'd say. If you don't measure job performance, why do you think your measure say anything about job performance?

RogerL 13y ago

Well, the person that referred to the article used the wrong term. Certainly brainteasers don't work, and they have been prohibited at Google for awhile. But the recent article stated that there was no correlation between interviewers and job performance. That the beloved hash table, distributed computing, priority queue, red-black tree questions that you pepper people have nothing to do with the quality of the person you hire. Which I have argued many times on here, should be glaringly obvious. Measure what you want to measure. I have never said "I'm so happy we hired Jane, she just tore up that smart pointer implementation yesterday". I like and dislike colleagues based not on comp sci algorithms, but whether their code is readable, how many bugs are in it, how quickly they can produce production quality code, whether they are responsible and hit deadlines, if they ask for help when they need it, if they offer help when other need it, if they are creative, if they are doers and achievers, if they take baths (seriously), if they step out of their office and interact once in a while, if they are problem solvers, if they read and keep up with their field, if they are capable of learning, if they write good documentation, if the client likes them, if I like them, if younger people look up to them, if older people feel some pressure because here is somebody up and coming, if when I go to modify their code I only need to change it in one place, and my change fits in naturally without breaking 15 different things (because it is designed with extensibility in mind), and that my heart beats a little faster because their code is just so beautiful. And so on. Google doesn't try to measure any of that. At all. And then you (google, not you archangle_one) express mystification at why your interviews do no better than chance. There's a clue there, I'd say. If you don't measure job performance, why do you think your measure say anything about job performance?