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.
About the Author
Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.