On 6/1/07, Daniel Martin <martin / snowplow.org> wrote:
> Hans Fugal <fugalh / zianet.com> 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 Quiz 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?
>
> --
> s=%q(  Daniel Martin -- martin / snowplow.org
>        puts "s=%q(#{s})",s.to_a.last       )
>        puts "s=%q(#{s})",s.to_a.last
>
>


I worked with a lead in a java shop that liked to ask this question:

"Write a function that reverses the *words* in a string" (in java)

Firstly, it would reveal if the candidate listens to the problem and
then goes about logically solving what was communicated to them (i.e.
its not reversing the string character by character).  If they get
crafty with the problem then kudos to them, but if they get stuck
she'll say that its ok to use java util classes to help solve the
problem.  Secondly if stuck since they claim to be java programmers
then they should know about the StringTokenizer combined with Stack
classes that makes this problem trivial to solve.

At first I thought this question was too simplistic (much like
FizzBuzz), but it really does fletch out the Heros from the Zeros.