Programmer Interviews
Posted by Daryl on 01/20/2010
It is interesting to me how people evaluate programmers. I have applied for many programming jobs over my life time and I usually run into one of three scenarios:
1) I’ll start with my favorite, they have me write code.
This is my absolute favorite type of interview, every time I get this one I always get the job offer. They give me a problem and ask me to write code to solve it. Not on a white board, or in pseudo code, but on a PC with Visual Studio installed. The last one I did like this they wanted me to connect through a web service to a SQL database, download some information, save it locally on the PC, modify it, and send it back via the web service to be recored with the new value.
So not only did I write code to do it, I also wrote a design document, added complex error handling, and I did it on a PC without internet access (no help form the web). They hired me and later told me that none of the other applicants even finished the code.
2) The Programmer Talk Interview.
I like this one too, I sit down with one of the other developers on the team and we talk about design best practices, software development methodology, and applications that I have worked on before. This type of interview I usually do good with as well, but other times it has gone poorly when I’m not on the same page.
3) The Computer Class Questions. (Ugh!)
This is the type I hate. They ask you to write a linked list optimizer or an anagram solver while your on the phone or on a white board. This may be great for those of you out there that got a 4.0 in all your computer classes (which actually I did get a 4.0 in programming II), but I don’t see how it says anything about your actual ability to solve problems. When I write code, I solve problems. I have written code that connects to a semi-truck over a serial port found under the dash with no documentation on the communication protocol which 4 other programmers had tried and failed. I did it, and I even had to re-write a C++ driver in .NET and my .NET driver ran faster. I bet if the company I was working at at the time had given me a question about linked lists they would have never figured out how to get it to work.
When I interview programmers, I use method 1 above.
