|
|
Did you hear about the computer programmer who drowned at the beach? There was a full complement of marines nearby, but none of them offered to help since they couldn't understand why the programmer was shouting "F1, F1!"
—Anonymous
One of my favorite technical interview questions is, "You're writing a compiler and somebody tells you an I/O library function (System.Console.WriteLine, cout, System.Out.Println, etc.) doesn't work. What do you do?" Watch out for anyone who answers, "Oh, I'd get out the debugger and start stepping into the code," because the person who would actually try that as a first approach is not someone you want on your team. Full-scale stepping through code in the debugger is too time consuming to be anything but a last resort.
But it's amazing how many developers would try stepping through the code as their first attempt to solve this bug. There are simply much better ways to approach the question. For instance, I'm always pleased to hear an interview candidate respond, "Well, first I'd ask for clarification on what is meant by ‘doesn't work.’ Does it crash, or does it give bad output, or what exactly? Does it happen consistently or only sporadically? Does it occur on all machines or just one machine in particular? Does it work with a certain type of input but fail with a certain other type?" After all, the first step to fixing a bug is to make sure you really understand it.
This is a book about debugging, with a special emphasis on applications written with Microsoft's .NET Framework. Before we get into specifics, let's examine a better way to answer that interview question.
|
|