A lot of interviewers will have a prospective developer do a code writing exercise in which the candidate is given a series of increasingly difficult small problems to solve in code. Often, this exercise is done on a white board, although with projectors and desktop sharing widely available now, many companies are moving to having the candidate compose at the keyboard.

I participated in this back when I was interviewing programmers, because it was expected. I always found the practice uncomfortable (more so when I was the interviewer rather than when I was the interviewee), and referred to it as “the white board inquisition.” Over the years, I’ve questioned the effectiveness of this interview technique.

We would typically start with something simple. For example, we’d ask a candidate to write the equivalent to the C strlen function. This was kind of a warm up to get him accustomed to writing code on the board, to explain the rules of the test, and to see if he had even the slightest idea about programming. The code itself is very simple:

    int strlen(char *s)
    {
        int count = 0;
        char *p;
        for (p = s; *p != '\0'; ++p)
        {
            ++count;
        }
        return count;
    }

I found it surprising how many programmers couldn’t just whip that out, although I’m not sure where they had difficulty. It was obvious to me, even 15 years ago, that many of the candidates were very uncomfortable writing code on the white board, and I can understand why. I code by typing. The output of my “coding brain” is wired to my typing ability. I don’t write code, and I certainly don’t do it on the white board. I type code into my IDE. Furthermore, I’m highly dependent on my tools. Things like automatic indentation, Intellisense or other types of autocompletion, edit-time compilation to show errors, and other productivity enhancing features are essential for me to code effectively and efficiently. Even something as simple as strlen is painful to type without an IDE, and excruciating on a white board.

After strlen, we’d give a few more difficult problems. As I recall, reversing a string, determining if a string is a palindrome (which is really just the string reversal with a little twist), binary search, and a simple sort were among the exercises we’d give.

One of the more interesting things I found was that younger programmers would try to solve the binary search recursively, and the older programmers would supply an iterative solution. Almost every recursive attempt failed.

Of all the candidates I interviewed, one aced the white board inquisition. That person knew his computer science and could regurgitate code on the white board at an astounding rate. I’m pretty sure he could have reproduced a working balanced binary tree implementation in a few minutes. He couldn’t write a working program from a design specification, though, as we found out after we hired him. He knew how to implement common algorithms and data structures, but he had no concept of how to put those pieces together to create a useful program.

We also hired a few people who couldn’t do much more than strlen, but who did very well in other aspects of the interview. With one exception, those people turned out to be much better programmers than the ones who did well on the inquisition. The reason, I think, is because although they couldn’t write a binary search on the white board, they knew how and when to use the library-supplied binary search function. They could interpret a design specification and come up with a working program. They knew the libraries and how to use them.

In my experience, anything beyond a few very simple exercises is a waste of time. The white board inquisition could tell me if the candidate understood the fundamental mechanics of writing code, but beyond that didn’t give any indication if he could write a real, working program.

So absolutely do something like FizzBuzz on the white board to weed out the candidates who can’t write code at all, but if you want to get an idea of a programmer’s real abilities, come up with a more complete exercise (something that can be done in an hour or so), sit the programmer down at a computer that has Visual Studio or whatever development environment you expect him to be working in, and ask him to solve the problem. That will tell you if he can use the tools, if he understands the libraries, and if he can solve a real problem rather than provide a solution to some annoyingly tedious puzzle.