Whilst it may be true that some very experienced developers would find it an insult to be asked to perform such a simple task in an interview. I personally would find it more of an insult if my full coding ability could be proven by any question in an hour long interview.

The point of the interview is to gain insight into the candidate and the company. This is all based on the types of questions asked, the way they are asked and the way they are answered. The good candidate will be the one that thought the questions were great and that answered them the way the interviewer wanted them to. This will provide a candidate who is on the same level as the interviewer which is far more important than defining any level of coding ability.

One thing to remember however, I don’t care if you have 2 years experience or 20 years, one day, you might just have to reverse a string.

Robin

http://www.codinghorror.com/blog/archives/001008.html

Most (all?) people would write a shuffle on their own instead of reusing the JDK version.

To explain my comments about developers reading blogs and reading articles. Several people share my experience and opinion.

See for example

http://www.codinghorror.com/blog/archives/001002.html

and

http://blog.red-bean.com/sussman/?p=79

“There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%. The 20% folks are what many would call “alpha” programmers [...] The 80% folks make up the bulk of the software development industry.”

“BTW, if you want to work for a financial software company in Tokyo just ping me!” Ah, Tokoyo :-)

Let me add a (peaceful) comment about my own practice.

I did the string reversal interview too and really what I appreciated the most was coding with someone during the interview. If you hire someone to do some development, it’s hard no to see him develop. But Reginald says it better than me: http://weblog.raganwald.com/2006/07/hiring-juggler_02.html,...

Right now, I have switched to another simple exercise, which I took from “daily life”. Write a function which will return a list of pairs of currencies from a list of currencies (financial software,…).
And I give examples:

List() -> List()
List(”EUR”, “USD”) -> List(”EUR/USD”)
List(”EUR”, “USD”, “JPY”) -> List(”EUR/USD”, “EUR/JPY”, “USD/JPY”)

And I ask people to develop that using JUnit in a TDD fashion: first we write the test, then the code. If they don’t know JUnit, I provide examples and they fill in the blanks.

Here are my observations so far, which are aligned with yours, Stephan:

-it is the only way to know if someone is really a programmer or not. I have been very badly surprised by people who should have a good development experience based on their resume and who were not able to produce some working code in a reasonable time. For example, they can talk about the difference between an interface and an abstract class during the interview and not know how to use the List interface in Java.

-very few people I’ve met (since we’ve began the interviews two months ago in Tokyo) can develop the last case. We usually have to stop after the second test case because of time

-this shows a lot about programming habits: naming conventions, exception handling, code layout, data structures, knowledge of the language (java: imports, generics,…), etc. I am also astonished by the number of people using Eclipse every day (that’s what they say,…) and not knowing shortcuts or refactorings

-I would also be very happy to see someone come up with a recursive solution because I personally find it quite elegant. Never happened before,… Let alone talk about tail-recursion! Even though, you can be a good developer without this (but I suspect that excellent developers would at least mention the option)

-This is a very time-consuming exercise in the recruitment process. I would like people to do the exercise and perform better. Watch them agonizing over a List interface is not my greatest pleasure in life. So right now we resorted to a silly java questionnaire to try to bring more relevant candidates to the table. If you have better ideas?

-Even if they don’t perform so well, the candidates always learn something out the exercise and I try to share with them as much as I can. We’ve had very good feedbacks about the interviews so far.

So my conclusion is: please, let me code during my next interview! I may not know if StringBuffers are really optimized by the JVM under specific circumstances but I will just have the opportunity to do something I love. And I hope it will show!

Eric

PS: BTW, if you want to work for a financial software company in Tokyo just ping me! You can come up with a perfect solution coded during a one-week break, I’ll be happy to discuss it. And the fact that you read this blog is your first “good point” on my list!