News

On hiring developers

• By Mike Gunderloy
• February 5, 2004

One of the mailing lists that I read has recently come round again to the perennial question of "how do I spot a good developer in an interview?" After a while someone proposed asking job candidates "how do you reverse a string?" At that point the fun began.

This list being oriented towards .NET developers, there were quickly half a dozen solutions floating around, as various people vied to prove their cleverness (or at least their ability to answer the question). These ranged from a simple call to Microsoft.VisualBasic.Strings.StrReverse (which I think is a great answer if performance isn't utterly critical) to elaborate schemes that involve walking pointers for each end of the string and using no-extra-storage swap code on the characters (which is too clever by half for my tastes, and unmaintainable to boot).

The interesting thing is that as people started picking at the proposed solutions it turned out that they were all wrong. Some failed for odd or even numbers of characters, others had problems with zero-length strings. Then there was the whole raft of problems brought up by ANSI vs Unicode and other formats. In some sense the problem is poorly posed; what are you to do with a composed diacritical character (where, for example, an accent and a vowel are stored separately but displayed on the screen as a single character)?

Despite the difficulty of writing a "correct" answer to the question, it's still a useful interview question for developers. The key is to pay attention, not to the code itself, but to the discussion behind the code. Next time you're faced with this sort of interview question, try to step back a level of abstraction and think about the messages you're sending as you struggle with a solution. As an interviewer, here are some of the things that I might look for:

Problem-solving approach. I'd personally give pretty high marks to the developer whose answer was "I'd look it up in the .NET Framework SDK help - surely there must be a built-in member for this." Using Google or the MSDN Library would also lead quickly to an acceptable answer. When I hire someone, I really don't want them inventing every bit of code from scratch. Nor do I really expect them to have memorized the entire base class library, or every tricky algorithm known to man.

Requirements elicitation. It's easy to assume that you know exactly what the interviewer is asking for, but in fact this simple question wraps up a host of assumptions. Bonus points to an interviewee who asks whether performance is important, whether Unicode needs to be handled, what the maximum expected length of the string is, or any other clarifying question. Even a simple "why on earthy would you want to do such a thing?" is a good question (though beware; the experienced interviewer will probably turn around and ask "well, why do you think a project might require this functionality?").

Testability. It's really easy to plop a solution to the question out. It's a lot harder to show that it's right. Does the job candidate mention boundary conditions? Does she have some sense of what a good set of test cases would be for the finished code? Does she start by writing the unit tests, demonstrating a firm commitment to test-driven development?

Culture. This one is hard to quantify, but I'm always looking for a good "fit" with my own development practices when I work with other developers. If your organization believes the squeezing the last bit of performance out is always important, you might look for the candidate who develops the tricky pointer solution, even though it's hard to get right and explain. On the other hand, if maintainability is your priority, you might prefer the VB.NET one-liner (or a well-commented algorithm of intermediate complexity.

That's not an exhaustive list, but you get the idea. Depending on the interviewer, a simple question can also test your familiarity with the tools they use in the shop, or your knowledge of language basics, or even your ability to design a solution before implementing it. If you're not aware of these issues, well, you might just be on your way to the next interview after someone else is hired.