17 ms·
Depends what you're looking for. None of the prior methods are -bad- if they're what you're looking for. I don't even object to IQ tests masquerading as not-IQ
by lostcolony 12y ago
Depends what you're looking for. None of the prior methods are -bad- if they're what you're looking for. I don't even object to IQ tests masquerading as not-IQ tests; it serves as a warning to me I don't want to work for you.
Depending how many applicants you get, I'd start with a screener, a basic, customized problem that they get an hour to solve, that doesn't have a hard pass/fail, but is just a "Hey, let's see how they code when given a problem". If you have constraints you want to filter for, now is the time (you want speed, see above. You want production quality, give them more time than you think a basic implementation would take, and indicate you want the thing to be production quality; see what they do, what they ask, etc).
If they pass that, yes, what you describe sounds fine, if it's what you're looking for in a hire.
If you want to favor false positives, ask a variety of fairly trivial questions; you're trying to make sure you ask questions they may not have solved before, but which any reasonably competent dev can solve. Bonus points if the person scopes them beforehand.
If you want to favor false negatives, ask harder questions, but make sure they actually are ones you deal with. If you're writing basic business CRUD apps, and your challenges are really in deployment, reliability, gathering and responding to user needs, etc, asking them to implement something from Cracking the Coding Interview is counter to your purposes. Ask them instead what it takes to build a reliable system. Are they familiar with doing that? What are some of the considerations? If they suggest distribution, are they familiar with CAP? Etc.
Really, it all depends what you're looking for. If you want someone who is keen to learn about the domain you work in, ask them if they know about things they have no reason to know about, and indicating that "it's okay if you don't"; see if they admit it. See if they respond with enthusiasm when you start to explain it, "Oh, that's cool!" when confronted with a new idea is probably someone you want, "Huh, okay", maybe not. Etc.
I readily admit, hiring is hard, extremely hit or miss, but a lot of companies seem confused about how it's supposed to work; don't borrow the interview practices of another company in a completely different industry. Google asks those questions? Google -can- ask those questions; they're trying to filter out people. You don't get 1000 applications for every job opening, you can't afford that. You also aren't dealing with the same problems; someone who fails those questions may still be a great hire for you.