Interviewing to me is definitely a trained skill that you have to practice with. Your goal is to extract as much information from the candidate so that you can make a useful recommendation. If you get too little information then your recommendation will contain more of a risk.
Each candidate that is interviewed is a different person and thus each interview is slightly different. For example: A candidate directly out of college will be asked different questions then a person with 10 years in the industry.
Regardless of the person, if they are wanting work as a professional programmer then they need to know a few of the basics. For the most part, it comes down to communication. When you interact with other programmers you have a basic vocabulary that is used. If the candidate doesn't have that vocabulary, then communication between the candidate and the other developers will be hindered.
I also am a strong believer that if you are going to work in the industry, you should at least have a basic understand of the underlying workings of a computer. Thus my questions are more general, yet still technical.
So this is my personal interviewing technique. One thing to note is that I try very hard to not ask trivia questions. These questions are things like "What does transient mean?". Guess what, I can look it up if I need it. I'm much more interested in if the candidate has a good solid base to grow with.
The first thing I hit on is what is a bit and a byte. From there I ask the primative types in Java and their sizes. The sizes question shouldn't be difficult if the candidate understands basic memory storage. Simply start with byte and work your way up, increasing the power of two each time.
Directly following this is a discussion about Data Structures. Remember your old friends (Map,Set,List,Array,Tree,Graph,Stack,Queue)? Hopefully you can name a couple of these, explain what makes each of them special, and have an example of when to use them. Oh, and a good side discussion regarding the equals() and hashcode() methods is good here as well.
Next is basic OO terminology. This is that vocabulary I discussed above. Polymorphism, encapsulation, interface, inheritance, overloading, overriding, pass by referrence, object, class, abstract class. If you don't know these then how can you a)communicate with your co-workers and b)create object-oriented software?
After OO I look at the resume and determine if they have database experience and if they are comfortable answering database questions. If yes then I would discuss primary keys, relationships, common database problems, and joins.
To round off the technical portion of the interview I discuss software designing. Things like coupling, cohesion, design patterns, tiered architecture. Usually I also go through a modelling question as well to see what types of behavior and attributes the candidate can come up with. The modelling question has been an item of hot debate with the team and we have yet to find a question that we are happy with.
My final technical interviewing requirement is asking the candidate to code. What? Code at an interview for a job that requires coding? That's crazy! The sad fact is that I have never been asked to code at any interview I've gone through. Would you hire a knife throwing juggler without seeing him or her juggle? NO! So why do we allow people to code without seeing them, well, code?
It doesn't take long to come up with some sort of coding exercise that can be written on the board or a piece of paper. Yikes! No IDE for help? Well, yeah, see the idea is that the exercise shouldn't really need an IDE. It should be simple enough to finish in 5 min, yet hard enough to get some sort of information from it. Currently the question has been working well.
If the candidate passes the technical portion of the interview, then it is onto Step 2, the soft skills interview.
-- From Aaron Korver