I have recently been emailing back and forth with an HR department that is interested in hiring me for some contract programming work. They had their lead programmer build an online "test" to test my programming skills. I had been waiting for this in great anticipation to see what kind of crazy things they might ask and to see how much it might test programming logic skills and how much would be nothing more than checking syntax.

Unfortunately their test did not work at all. On the very first question their web application crashed with a bogus SQL statement. Perhaps that was the test? They wanted to see if I could correct the SQL statement? Or maybe I was supposed to try to get hold of the PHP and fix the actual test engine?

It now makes me want to send a test back their way to test their programmer. Before their test crashed it said it was going to ask me 50 C++ questions. Sigh. Sounds like it would have been all about syntax and obscure language nomenclature and not a real test of logic and creativity.

A couple of years ago at Warm Floors I was asked to come up with a test for the hiring process for a new CAD person. The CAD software they use isn't AutoCAD, it's VectorWorks and they needed someone that was going to be able to think a little to do layout and drawing on a program that they had most likely never used before.

The test I came up with was I made a very simple drawing of a house and a tree and a sun (sort of like a child's drawing) printed on a piece of paper. They were asked to sit in front of the computer with VectorWorks already running and to draw as much of the picture as they could in 15 minutes. I sat behind them to watch what they were doing, which no doubt made them nervous. I didn't care how much of the drawing they finished or what parts, it was how they did it. Seeing whether they could pick through the program and see how it works and apply general knowledge of CAD programs and look for tools they think should be there was what was important.

The reason I bring that up is because when I went searching for programming interview questions there were two schools of thought: trick questions, and letting someone write actual code. I feel the test I came up with for CAD was much more of a skill test rather than a trivia test.

In the case of writing actual code there was no consensus on whether the applicant should be forced to write code in the language that the company expected to be using, or in the language that the programmer felt most confident in. I personally would probably ask for the programmer to use pseudo-code if possible, otherwise their language of choice. The argument for using the company's preferred language was mostly, "Well he'll be working for you writing in that code, don't you want to see if they know it?" The reason I don't go along with that is because I know a ridiculous number of languages, and logic is logic. If you understand basic logic and programming concepts, picking up another language is trivial. In fact, it's fairly easy to learn a new programming language just by examining some source code, I have done this many many times, and so have my sister and other programmers I know.

The only trick question I know to put on the test would be the "fence post problem." I don't really consider it a trick question, if you've never encountered it all it takes is thinking about it a bit and you can come up with the answer. But I know I want to put it on there to see if people can get it easily, which sort of makes me think maybe it is a trick question.

As to writing a sample program, I'm not sure what would be a good test of that. I wouldn't want to come up with anything that was going to be a full application. It needs to be something that can be completed within an interview. It also needs to be able to demonstrate logic skills and not require extensive "debugging" to see if the concepts would work or not. On a test my uncle said he took once years ago, the company asked him to come up with the routine for a standard C library function. Short and easy and definitely demonstrates logic skills when you're essentially asked to figure out how things work inside a "black box" that you've used many times.

Another thing that I saw mentioned was a concern for debugging skills. In my experience people often have a much harder time debugging their own software than coming up with code to do a particular task. And if that person is going to be debugging other people's code, it can be even harder for them. It requires good analytical skills and persistent detective work. If you have any experience with compiling and porting open source software, I'm sure you know what I'm talking about. :-)

Have you been through a recent interview process? What sort of tests were you subjected to? What kind of tests did you present? What kind of questions did you ask? Did it turn out to really apply to the position?