Now that I have a job and haven't started yet (won't until November 7th), I feel I can comment on the current interview process in the information technology industry. This is the same with all interviews I have been on. Maybe it's just my age, and that I'm still considered a "junior" developer, considering there are people that work at the places I've interviewed at that have 10+ years experience in the field of technology. I can give them respect for that, for being older, for being around more things, but I still really can't consider myself a "junior" developer. Experience-wise, yes, I have 4 years experience. But, knowledge-wise, I rank up there with at least an eight to ten year developer, just because I live and breath this stuff, and I'm writing software on my TIME OFF. Jeez :)

The interview process for every interview I've been on is the same. The interviewer mentions something in technology, perhaps a term used in Object Oriented Programming, or they ask you something about the language that you are being interviewed to program in, or whatever, and you are supposed to answer it in the best way you know how. Well, let me let those interviewers in on a little secret: Everyone asks the same questions. If you interview at one place and get something wrong, you're going to look it up and have an answer for the next place. Not that I ever mess up on any of their questions. I've always known the answer to "What's the difference between public, private, protected and internal?", but now it's more like I'm spitting it out from memory just from all the times I've been asked it. There are numerous other ones.

I agree, this is a quick way to weed out the people who have never done object oriented programming, and the other questions may weed out people inexperienced in other aspects of technology which are related to the question at hand, but how about this. Try to weed out people who haven't used those things and people who haven't developed anything even remotely difficult in their lives, on ONE question! My one professor in college said that most Computer Scientists, after working in the field for a number of years, couldn't write a working "Queue". Sure, it's no easy task, but we did it, learned the ins and outs, things to watch out for, etc. I have that extremely good memory, detailed in The Philosophy, Part I, so I'll never forget. Although, I did it in C++, now with fully object oriented languages, it should be a bit easier :) Not that you would ask someone to write a queue in an interview, but perhaps you would ask "You want to write a queue... which data structure would be easiest to use when writing a queue?" Somewhat open ended, yet extremely difficult, and you're really tapping the knowledge of your interviewee. You can use an array, keep the current positions as integers (beginning and end). A linked list would be simpler coding, as long as you have the linked list code already, although it's not an extremely difficult challenge to write a linked list (just give me a pad and a pencil, I'll code you a linked list!). Maybe you can ask "What can't you use?" on top of it. Surely, a tree based structure is useless. Easiest thing would be a linear list of some sort. That's a good question, and when I'm interviewing people in a few years, as long as writing code is still a profession, I'll remember that one. Other questions could be more pointed to the type of programming the interviewee might be undertaking if he or she were to be hired, like web programming, databases, web services, UI programming, etc.

I'm not here to tell interviewers how to do their jobs, but us interviewees who know what we're doing with the technology typically snicker under our breaths when asked "What is a dataset and how is it different from a data reader?" For those who don't know what they're doing, they can look up this answer and have it ready for their next interview. Even if their resume says they're the bomb but they're really not...

Another reason that I don't like this process is because I might not know everything that they ask at an interview (SHOCK!!). I might not know every single function that a "DataSet" has on it, every single type of constructor it has, or things of this nature. However, there is no need to ask a question like "You want to create a dataset from XML, how do you do this?" This also points back to The Philosophy, Part I. I explicitly point out that it doesn't matter if you know how to do something, it only matters if you know what something does. Or, in this case, if you know what something is capable of. Yes, you can create a DataSet from an XML document, but when have I ever needed to do this?! If I did ever need to do this, how in the world would I learn in the first place? By looking at a reference. If, for some reason, I never used that again, would it matter now that I don't remember the specific function to call, or would it matter more that I know that you can create a DataSet from an XML document, somehow? I certainly wouldn't think that I can create a Hashtable, or a bottle of beer, from an XML document.

I look forward to not going on any interviews again for a long time (crosses fingers after only having last job for 5 months).