Hi Yossi, sorry it took me a while to get back to this. So much to respond to, so little time…
* Yossi Kreinin <[email protected]> [2007-06-15 14:00]: > 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? I think it’s a good thing to ask about; but I’d ask in the abstract, not have them write code. F.ex., come up with a problem that is best solved with recursion, eg. some sort of tree traversal, and tell them you expect a recursive solution; then ask specific questions like what parameters they’d pass and what conditions they’d recurse on, what ones they’d use to bottom out the recursion, and such. I think. I’m not really sure. The danger is of course that this sort of question is easy to prepare for, assuming the candidate learns about the sort of questions that will get asked. The subtleties in FizzBuzz and other such coding question go beyond trivialities like newlines; I don’t remember the specifics, but I know several people got their first cuts wrong (as in outright buggy) despite being decent programmers. > >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. Exactly. And yeah, FizzBuzz is much better than those sort of questions, but that doesn’t mean it’s good so much as it means those sorts of questions are terribly stupid. > >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. Cool. I’d be interested in hearing about experiences with this approach if and when you employ it. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
