Archive for November, 2008
I received the following question a couple of days ago from a programmer using the “Ask a Question” form which you can access from the menu of this blog:
Given the following table:
How do I select names of persons who know both Hindi and English?
In this table, that query should return Nikhil and Kisu.
Have you ever written some code and named something one thing only to realize that it should be named something else?
If you haven’t you haven’t been programming for very long. Maybe you started a new job and you spent two weeks writing code using your previous employer’s naming conventions only to find out that this employer expects things to be named slightly differently.
So now you not only have the item named incorrectly, but you’ve referenced it from other files, so it isn’t a simple matter of just giving it a new name. No, the code that is referencing it has to be changed as well. So what are you going to do?
It has always struck me as an odd practice to give a written test to an interviewee during the hiring process. I’ve been on both sides of the hiring process. I’ve had to take a few of these tests. My general perception is that all a test shows is that the person taking it knows how to take a test.
I’m going to approach this topic from the hiring manager’s perspective since that is the only perspective that really matters. I could go on about how it is unfair to me as a potential employee, but that wouldn’t convince those who need to be convinced. So here are some points to consider when considering testing as part of the process:
One of the new tools that showed up in Visual Studio 2005 that I don’t see many people taking much advantage of is the Class Diagram.
The class diagram displays the classes you drag onto it in a visual representation much like a UML class diagram does. It also lets you see relationships between your classes. But the greatest power in the Class Diagram is that it will write a lot of your code for you.