Brent Simmons (@brentsimmons) muses over the value of coding questions for software interviews here:

I mostly agree with his take, but as someone who has done a lot of interviewing, I actually love the coding problem he cites:

You need to add two numbers and get a sum. But, importantly, 
the digits of those numbers are stored in arrays, and they’re backwards.

The return value also needs to be in a backwards array.

If inputs are [4,2,6] and [3,8,0,8], the function should 
return [7,0,7,8] — because 624 + 8083 == 8707.

I know plenty of interviewers who would have the same shortsighted approach Brent laments in his post:  that there’s a mindset that coding questions are all about efficient solutions and applying the right techniques to get to “optimized” code.  And in that context, there’s a “best” answer that an interviewer might want an interviewee to discover and implement.

Of course, that’s wrong.  There is no best answer.  The approach Brent describes as his first instinct — to optimize for understandable, readable and simple code — is my first instinct, too, but that doesn’t mean that it is “right” — just optimized for something else.  As an interviewer, I’m happy with any answer as long as the interviewee can explain why they took the approach they did. And so many details of an implementation of the code for a problem like this shows off the instincts and the “comfort zone” of an candidate.

Did they write one long function or break the solution up into smaller parts?  Did they give variables and functions intelligible names?  Did they lean on their chosen language’s standard library or libraries?  Did they ask why, or even theorize why such a function was needed in the first place?  Did they write test code first, or perhaps at least consider a few test cases?  Did their function prototypes make sense?  Did they show they were comfortable using pointers?  Did they use pointer math in unsafe ways, or perhaps they used a language which didn’t allow unsafe pointer math?  

Then, knowing where the candidate comfort zone is, I’d try to venture outside of it.  I might ask “under what circumstances does your code not work as expected” if there’s integer overflow issues.  I might ask “can you write a unit test to verify that your code works” if it is structured in a way that makes unit testing awkward.  I might ask “can you you write code comments about what each parameter does?” if I think the interviewee doesn’t quite know how their own code works.  

I might even pose a question like 

 what do you expect that the result should be if the 
 inputs are  [-4,2,-6] and [-3,8,0,-8] ?"

if they wrote a function where those were possible inputs.

My ideal coding interview question is simple enough that the candidate can show me their talents in their comfort zone, and complicated enough that it is easy to extend the question beyond their comfort zone - a strategy which lets me figure out exactly what kind of developer I’d get if I hired them.

I have a feeling that anyone using this method with Brent would come out of it knowing exactly what kind of developer they’d get if they hired him.  And of course it would be a mistake if they didn’t.