Link Details

Voted down: This article misses the point of the original, which is:
"Not only is the chosen implementation interesting as an answer, but also does the candidate reuse the JDK or not or does he tell you at least “there has to be something in the JDK”. Which is quite as good, because googling in reality will help him find the JDK solution. You don’t want developers to implement everything themselves."

Showing that a developer knows how something works behind the scenes and knows how things fit together demonstrates a key difference between someone who implements something without thinking and someone who engages their brain. It also shows that they have an interest in how things work.

I know who I'd rather work with; problems that arise through an enterprise software release cycle often involve implementation subtleties and it's always best to have someone who engages their brain and has an interest in how things work.

I too think it is good to be interested in how things work behind the interface. However I don't think we have to argue here on the many benefits of leveraging existing SDK code, and I would prefer to work with someone who understands that, than someone who tries to reinvent the wheel for every problem (Looking back...I was like that once)

I think the point of both of them is, make candidates write code during interviews.

Even simple problems will filter out 90% of the people you don't want. The trick then is to have a problem sufficiently hard to filter more but, not so out there that you might filter out a good dev who isn't well versed in the problem space.

It's just one person's experience and way to deal with interviewing. What "sad state"? How could you generalize from one sample?

that there are bosses out there that use that technique and after that article more people could use it.

i agree that writing code is good, but i am always in shock when someone makes me write code during interview, its just wierd thing to do (90% of interviews dont require knowledge of how to write code, just the teorii). However i think that writing trivial stuff is like spitting in developers face ("i dont think that you could reverse a string, did you ever use java?"), i think better idea would be to write simple program (yes, its harder to review that code, but at least developer doesnt feel that the boss thinks that writing string reversal is a big challange). As far as writing code, i saw on one interview great technique, writing code as UML diagrams.

Personally, I wouldn't hire someone without making them write code. There are too many people who talk a really good game but, can't implement HelloWorld.
Hell, making HelloWorld the programming problem would filter out at least 50% of the candidates

Check out my follow up article on if you must make someone whiteboard:

http://www.dzone.com/links/whiteboarding_code_during_interviews_part_duex.html

If you make me reinvent the wheel during an interview, it'll make me think twice about wanting to work for you.
Apparently you don't know about the existence of the standard APIs to do such things, which doesn't bode well for the work you're going to present me with if and when you would hire me.

It's all well and good to want to see if someone knows his stuff, but don't make yourself look stupid or otherwise incapable in the process or you end up hiring only people who have no experience at a level higher than those simple "tests" because those guys that do turn down your offers.

Did you even read the article? I am decidedly against evaluating a individuals performance by making him write a small snippet of code.