Thanks for your reply. I'm actually co-interviewing people these days, so I'm
quite interested in opinions on the subject...
yes. Jeff Atwood from codinghorror.com started the meme a while
ago: http://www.codinghorror.com/blog/archives/000781.html
Speaking of uberpopular blogs: I've seen the claim about having to check if a
candidate is fluent with pointers & recursion at least 3 times on those. I tend
to agree, since the moment when I "got it" myself was one of the relatively few
times when I really fealt that I learnt a big new thing about programming
("insight", so to speak).
Do you think that a trivial question of that kind (like printing the elements of
a sorted binary tree) is not really helpful/is harmful? There seem to be no
subtleties (in FizzBuzz, it's easy to start obsessing with newlines or
whatever). Does there seem to be a good chance for false negative?
The other half is that it’s hard to devise a problem that doesn’t
just *look* simple, but also actually *is* simple. Even a trivial
task almost inevitably has subtle edge cases that aren’t apparent
in its description.
I considered the FizzBuzz-style problems a great improvement over two styles of
questions I've seen:
* Riddles ("sort an array with your hands tied behind your back")
* Language lawyer questions ("does const_cast cast away volatile?")
Personally I can deal with the first kind reasonably and with second kind quite
well, but both are idiotic. So the "do something very simple" approach sounded
very good to me, compared to these other ways. But your points strengthen my
doubts. When someone solves these things quickly, it's a good sign, but there's
umpteen other things you have to check out; when people fail, it's very hard to
tell how much "points" they should lose for each kind of error. So the data is
not very useful after all.
Plus, I don’t think programmers are interchangable code output
machines. There are many more ways a programmer can contribute
positively to the project he’s on than just being a competent
code monkey who sticks to his job title role. So I want to learn
about the person. They might have an aptitude that might help
make the other members of their team more effective in general,
f.ex., even if their own work doesn’t look that impressive.
I agree completely; I have a pretty vague job title myself... I think that
asking people about their previous projects is the best way to interview, and
that's what the people I trust most in hiring issues do. What didn't occur to me
is to ask for actual code listings and/or asking people to write code before the
interview. Sounds perfectly reasonable now that I think of it; I'd prefer that
kind of employer over a riddler or a language lawyer or a fizz-buzzer.
I'm in a relatively young company, and we don't really have a stable hiring
procedure yet. I think I'm going to seriously talk about it with the people who
interview candidates.
