Quote:
It gives the interviewer a way to see how you respond.
Exactly. Having just gone through the process myself (and now giving interviews for my replacement), I can definitely say most of the questions had no "correct" answer.

Some examples:
Your project has been developed and tested and is in the middle of deployment. It will go live in one week. The client comes to you and requests additional features, yet says the origional timeline must hold. What do you do?
Impossible situation of course- I responded that we could make the changes and miss the date or save the changes for a second release, recommending the latter. I also said that OT would not accomplish the goal. Of course, this wouldn't make the customer happy, but sometimes it's just an impossible task.

Another question I had was this one:
You have a task you know can be accomplished in a month and a half with two resources, but you only have one resource available. You are required to finish within a month and a half, so what do you do
To this one I responded either hire a contract help to augment the team or miss the date. OT would not do it. One person cannot do the work of two by putting in more hours.

In either case (and there were many more questions like these), it wasn't so much the answers she was interested as my demostration of understading software development issues. To give the answer "that's impossible" and not follow up would have been a poor answer, even if correct.

The really funny thing about these interviews was when they actually brought the users in and locked me in a room with them for an hour. I don't think they gave the users any clue as to what was going on- and in fact it seemed like they thought I was already on the job. I was informed that one modification should take, "about 30 mins" by one of the ladies! I carefully explained that without seeing the code I had no idea how long it would take, and that if it required an change to the way the data was stored then it could take months to implement if we wanted to make sure nothing else broke. This actually resonated with them because they've gone through a number of modifications that break other, semmingly unrelated things. The fact that I turned a somewhat negative group of users toward a positive discussion by the end really impressed the managers, so it was one of the more useful aspects to the whole process, even if it was a bit strange.

The big myth about interviewing is that people really put a lot of value into it. The truth is, you cannot make a solid, rational judgement after meeting with someone for an hour. Those who are charismatic and outgoing are always going to come off better, even though good IT people tend to have neither trait. I think the most important trait a software developer can have is creative ability, yet how in the world can you judge that in 60 minutes? Instead we get left being questioned about how well we know C# or Java- really useless since good development principles cross language boundries and new software languages are not hard to pick up.

Not that there's any real solution to the limitation of interviews- an interview is better than not meeting the person at all. I guess I just feel like people put too much stock into them and would do better to be more aware of the limitations.
_________________________
-Jeff
Rome did not create a great empire by having meetings; they did it by killing all those who opposed them.