Hans F. [email protected] writes:
I feel compelled to point out that it was Microsoft who started this
whole mess, and they quickly figured out it was selecting the wrong
people and they don’t do it anymore. But the cat’s out of the bag, and
now every wannabe shop thinks that’s the way to find smart
people. It’s not, it’s the way to find people who are good at solving
puzzles under pressure, and in the worst case to find people who are
good at finding ridiculously clever (but unreadable/unmaintainable)
answers to puzzles under pressure.
I think the usefulness of this interview technique depends on what
problem is used and what it is used for. Namely, if the problem is
one that can be solved quickly, and while on autopilot, by pretty much
any decent programmer, and if it is being used simply as a straight
yes/no screen to block people who can’t program their way out of a wet
paper bag, then I see “write code for this” as a useful interviewing
tool. Maybe it isn’t a problem where you are, but we’ve had people
claiming five years of programming experience who were unclear on how
two nested loops would execute.
For example, one question we frequently use is “write a function that
takes a two dimensional array and returns the sum of the minimum value
in each row”. Now, we understand that people are nervous in
interviews, and we’ll occasionally give hints such as “this line here
throws a NullPointerException when you run it”, or “that works, unless
the array contains a negative number”, and give the candidate a chance
to revise their answer. However, we have honestly had people
interview who couldn’t write a doubly nested loop, or even explain
coherently how a sample solution worked. Maybe it’d be easier if we
were interviewing for ruby programmers instead of java programmers.
I’ll also point out that there’s a quite prestigious shop located in
Mountain View, CA that handed me a whole bunch of “write code in
language X that does this” problems when I interviewed there. (and
they still didn’t take me - http://xkcd.com/c192.html )
On penalizing ridiculous cleverness:
When my (now current) boss gave me that question above, she said
initially “in any language”. I scribbled something really short down,
and asked “you probably meant any imperative language, right?”, after
which I gave a completely unimaginative imperative solution in
perl. (The language I was most familiar with at the time)
I don’t go for the overly clever bizarre stuff at work - that’s what
Ruby Q. is for. Well, okay, I have been known to write bizarre perl
one-liners at the shell prompt, but not for anything that’s going to
be run more than once. I have however been known to occasionally use
techniques that some people might call obscure in production code if
the code overall becomes more elegant or easier to read. I’d much
rather build a parser that can read the description of a data record
as provided by a vendor than have fifty lines of mostly cut-and-paste
but conceptually “simple” code that doesn’t tell me at a glance
whether we’re parsing the latest version of the format.
The point is, yes, maintainability is important, but I really don’t
understand the animosity towards “cleverness” that seems to be showing
up here. That sounds to me dangerously close to the same attitude
that keeps ruby and many other non-mainstream languages out of many
production environments on the grounds that “we’ll never be able to
find anyone to maintain it”.
Also, as a practical matter, I haven’t seen this “cleverness” in any
of the subsequent interviews I’ve conducted from the other side of the
desk. Frankly, I’d love some evidence that incoming candidates had
been exposed to something other than the industry standard languages
and platforms. Exposure to functional programming and the thought
patterns that go with it is a good thing. Being able to look at a
problem from multiple angles is a good thing. Mental agility?
We’re supposed to like that in a candidate.
Incidentally, my initial answer was:
(Plus @@(Min /@ #))&
Anyone care to identify the language?
