> Taking up hours of a candidate's time is excessive, but it seems reasonable to ask for some demonstration of your ability, when so many candidates simply cannot code.
So why not simply ask technical questions during an interview? I'd think you'd be able to determine whether or not someone know what he is talking about by simply asking him a few questions on the matter.
How do you know what level to pitch the interview at if you don't know what language features someone understands and how they code?
Where I work we now set a small simple test which is very representative of what colleagues do because we've had so many time wasters. I'm looking to see their style, the fact that they can actually read a simple spec (apparently over half can't), and that they can explain why they approached the solution how they did. If their test is no good, we don't waste each others' time.
If someone has a decent GH account I'll look at that too - if it's sufficiently comprehensive (very rare to see anyone with a GH account at all, let alone their own projects in it) they won't need to do the homework (should take about an hour, less if they're good). This just saves us wasted time.
Remember - you might know you're good. How do you expect strangers to?
Because there are plenty of people who can regurgitate things but not be able to do much with it. I've seen it with CS grads from good schools, its disconcerting and confusing.
Why are you asking "fact regurgitation"-type technical questions? I prefer to ask open-ended ones, questions that start a discussion that will quickly determine if the candidate really understands what they are saying. It also reveals correct but rigid thinking, something I would like to generally avoid but that doesn't always come up in a coding exercise.
That's why you drill down when a statement sounds like it came from a blog/book/screencast.
While I agree it's frustrating dealing with someone like this, often times it's easy to pick out the statements/topics that the person is regurgitating.
Agreed, but for people who have to justify hire/nohire/fire decisions to their bosses or other parts of an organization an objective metric is very useful.
A quick coding problem doesn't have to take that long either. I agree that asking for a (relatively) huge project is the wrong way to go about it, but it doesn't have to be huge.
Because technical questions are pretty bad indicators. Just because someone doesn't remember how to reverse a binary tree off the top of their heads doesn't mean they're not a competent developer.
So why not simply ask technical questions during an interview? I'd think you'd be able to determine whether or not someone know what he is talking about by simply asking him a few questions on the matter.