When interviewing developers and analysts I have a series of practical exercises that I run them through.

One of the exercises is a debugging exercise in winforms and vb.net. Internally we actually use ASP.NET/C# for all our development, but a good .NET developer should be able to handle any language thrown at them.

In any case, the exercise involves cleaning out 8 bugs designed in such a way as to be hard to work around and some bugs don't appear until others have cleared. A great developer will complete the exercise in about 5 minutes, and par is about 20 minutes. Any longer than that and I won't continue on.

The very first bug to solve is a simple one to give the applicant a little bit of confidence and is simply to define an undeclared variable.

This poor applicant shows up today and proceeds to fix the compiler error, although it took 5 minutes for them to work up the courage to change the code. By this time I obviously had made up my mind and I knew they were no good, but I didn't want to be too rude so I let them continue on for a bit longer.

So the applicant compiles the program, runs it and nothing happens (one of the bugs causes the program to stop without errors before displaying anything on screen). They then look at me with a perplexed look and tell me quite sincerely that they "can't understand why the program doesn't work. It compiles so it should be OK now.". It makes me wonder what some people think debugging is all about!! Needless to say the interview ended at that point.

I think I'll need to post a "tips on debugging" article to help explain to developers the things they should be learning in their programming courses.