|
"The trouble with "Be reasonable" is that's it's the advice equivalent of a tautology. Of course we should be reasonable when interviewing. But I don't think there's widespread agreement about how to operationalize that. I'd be curious for more detail about how you would do it---you seem to have strong, well-informed feelings on this issue." I think my primary argument is that it's basically impossible to assess "intelligence" at a 30-minute white-board session. There are too many other factors: thinking style, nerves, fear of speaking, etc. But most interviewers will flip the idiot bit if you don't answer their pet algorithm question quickly enough; it can be very difficult to come back from that kind of deficit. It's usually pretty easy to tell if someone can't code -- you give them a straightforward problem (no "aha" moment required), and make them write the code. If you're really worried about it, give them a phone-screen problem that requires coding, then make them write a variant of the solution during the interview. For "intelligence" testing, I like to give design problems, since they're far more representative of what will happen on the job. For these, I usually reach back into the grab-bag of recently-solved problems, and ask them to sketch out a solution, then iterate. If their solution is better than my own, that's a win. If it's the same, that's good too. If they just can't come up with something reasonable...well, we have a problem. But note what you don't see here: there are no situations where I ask a question that requires a moment of algorithmic brilliance. That's just too random. Google can get away with that kind of stuff, because they get thousands of resumes a day, and can't possibly hire every good engineer that applies. For the rest of us, we have to be a bit more intelligent. |