Read many of the books on this list. I highly recommend Clean Code: A Handbook of Agile Software Craftmanship by Robert C. Martin. It reminded me a bit of Fowler's Refactoring, but with more than just refactoring in mind. If I managed in a Java Shop I would give this out to all of the developers post-haste.

Of course it is not too much to ask a candidate a FizzBuzz or LCM or question. I still stand by the fact that it isn't all that useful. We (hopefully) don't write procedural code like that all day long in our Java, C#, or C++ jobs. We write OO code and as such we need to ask questions that force the applicants to write OO code. If we don't then we haven't tested whether or not they can do our job. Bottom line: It is an interview FAIL if you don't force the applicant to code in the language and style that they will be coding in the job for which they are applying.

It is interesting to me that most of the interview questions are write a quick program to do solve some silly math problem. It shows math skills, not software engineering skills. It does not show you how well someone will do OO analysis and design or OO programming. You need to present a problem that forces the applicant to use the features of the language that you use in your daily programming (e.g., inheritance, polymorphism, etc.). It is much harder to piece together solid interview questions than it is to simply say write some code that generates primes or reverses a string, but is necessary if you really want to find out if the applicant can do the job. You may end up hiring someone who is good at math, but writes procedural spaghetti code.