The most important job interview question to ask an R&D candidate

Just a few hours before, I commented on few bloggers linking their own blogs with anything/everything. They almost treat HN like their auto-post to everywhere.<p>perspective: <a href="http://news.ycombinator.com/submitted?id=techdog" rel="nofollow">http://news.ycombinator.com/submitted?id=techdog</a> <i>(the submitter)</i><p>The content may be(or not!) worth reading, but I'd rather have 'discovered content' please!

I think this post seriously misses the mark. For R&#38;D (actually, I think lumping R and D together like that is a serious mistake, but that's another issue) I don't think coding matters very much at all. What matters more is raw problem-solving ability, understanding of core mathematical concepts, etc.<p>Project Euler is a good source of questions for R&#38;D candidates.

<i>If the talk turns immediately to formatting issues, that's not good.</i><p>Amusingly, however, I've noticed that bad/newbie coders tend to indent stuff all over the place and have no consistency in the whitespace (this is C++ so the compiler doesn't care). Often you can tell the code is bad because it literally looks bad.<p>I prefer the suggestion commenter 'John' gave rather than the OP's: "Can you draw me the architecture of your most complex project?"

I was asked if I had any hobby projects and would like to explain their architecture on a whiteboard. In addition to the benefits of seeing into the candidate's mind, it eases the nervousness quite a bit to talk about something you definitely know more about than anyone else.<p>I was then asked if I drank beer. Then I was hired.

That's really his one question he'd ask to someone working in R&#38;D, and writing code?<p>How about asking somebody about the problem domain he'll be addressing? Past experiences on that field, or related fields?<p>Recognising bad code might be nice, but I'd pick someone with 20 years of real and relevant experience over someone just new that can say "whoa, that looks like bad code!"

The "special extra credit" makes me think this question is fishing to see whether the candidate can step back and look at the big picture. That's part of the job of being in R&#38;D, no matter where you stand on the research to development spectrum. One of the reasons companies keep R&#38;D departments is to have people around who are technically knowledgeable _and_ who have the vision to think ahead about where the company should go next.<p>The fact that it's about code quality is an artifact. Yes, as others have pointed out, a question about code may not be so relevant if your candidate is a theorist or will have a role with no development. Still, because most or all candidates will have experience with bad code, and because fewer will have intimate knowledge of the business at hand, it's a better question than "so, where do you think our company should go in three to five years?"

&#62;What about evidence of design patterns? Does it look like the person who wrote the code doesn't know about things like Observer, Visitor, and Decorator patterns?<p>This is his criterion for a <i>research</i> position? Understanding of the unsolved problems in a domain? "Irrelevant."<p>Mathematical sophistication needed to abstractly model complicated-seeming scenarios? "A dime a dozen."<p>Know the decorator pattern? "omg, you're hired!"

A spin on this that I do is give them a piece of code that I know has some major flaws (a very small piece of code) and ask them to tell me why it sucks.