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