Having been through the job search process for several months, I can give you my perspective on the job search process as it relates to me. First, some don'ts; these are all things that many employers are doing right now, and they shouldn't be doing them:
Don't ask people elaborate questions about things that they will never use on the job.
I'm not talking about FizzBuzz. FizzBuzz exists to weed out people who can't program at all. I'm talking about asking people to design and implement a binary tree, when that problem has already been solved decades ago. Instead, ask about complexity (Big O), and perhaps how to use recursion to walk a binary tree.
Don't ask people to write perfect code.
You're not going to get that in a coding interview, especially if it's via skype or over the phone. Most people use IDE's nowadays, and you've robbed them of that tool. If part of your job skill set requires people to code in Notepad, then by all means. I doubt that's true, though.
Don't ask people to travel clear across the country for a six month commitment.
This is just a variation on "the interview that never ends." Figure out how to find talented people to interview in the first or second contact to interview, and then make the interview relevant to your job.
Stop following the herd!
Some of the things that you are doing in your interviews you are doing because Google does them, or Facebook does them. Your best hiring process is not necessarily coding contests between whiskey shots (if the lore is true). Your best hiring process is the one that best fits your company, not the latest Google or Facebook fashion.
Finally, don't ask people about things you don't already know yourself.
If you're asking someone to improve performance on a string reversal algorithm when they've already written it in the most optimum way, you're just wasting everyone's time.
Now that that's out of the way....
For example, in a Java snippet I would use == instead of .equals(), duplicate some code...
This seems like a sensible approach.
I would expect every experienced developer to already know certain things about their language of choice. I would expect a reasonably competent C# programmer to know how
== differs from
equals(), why strings are an exception, what
IDisposable is and how it relates to
using, etc. I would personally favor crack skills in their language of choice over your preferred kitchen sink of desired technology flavors of the week, since someone with excellent coding skills can easily pick those up.
I found that this question gave me insight into several things. First, it was a red flag if a developer could not point out obvious issues with the code. Second, even if a developer could not find all the issues, I could point it out and they can say 'ah yeah' and talk about it in a meaningful way. It also allowed me hear them dig as deep as they wanted on certain things.
I personally find it intimidating to write code during an interview. I also find it strange when potential employees give you a 'homework' to complete at home and hand in before the actual interview. But then how else are you supposed to evaluate their programming potential?
By the time you grant someone an interview, you should already have a fair idea whether or not you're going to hire them. When I interviewed for the job I have now, I wasn't even asked any technical questions. The person who interviewed me spent most of his time selling me on his company. He said "I already know you can do the job, subject to your references confirming that you've done the things you say you've done in your resume."