4 ms·

> 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 cann

by orng 11y ago

> 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.

st3v3r 11y ago
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.
dpeck 11y ago
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.
- vonmoltke 11y ago
  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.
- dandersh 11y ago
  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.
  - dpeck 11y ago
    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.
- mamoswined 11y ago
  And some people who aren't going to do well on verbal questions but who can code.
mikeash 11y ago
Why ask technical questions about the skill you want to see, when you could just ask for a demonstration of that skill?
- orng 11y ago
  Because asking a few quick questions doesn't waste 8 hours of your candidates time.
  - mikeash 11y ago
    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.
estefan 11y ago
A picture paints a thousand words. 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?

by orng 11y ago

st3v3r 11y ago

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.

dpeck 11y ago

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.

vonmoltke 11y ago
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.
dandersh 11y ago
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.
- dpeck 11y ago
  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.
mamoswined 11y ago
And some people who aren't going to do well on verbal questions but who can code.

mikeash 11y ago

Why ask technical questions about the skill you want to see, when you could just ask for a demonstration of that skill?

orng 11y ago
Because asking a few quick questions doesn't waste 8 hours of your candidates time.
- mikeash 11y ago
  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.

estefan 11y ago

A picture paints a thousand words. 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?