I think there are those easy questions fizzbuzz, reverse a string, etc., and then there are certain questions whereas if you have not seen them before it is tough to get the intended optimal solution with the additional pressure of the interview and the short time constraints. The worst part is that sometimes recruiters with no technical knowledge ask some of these questions and they are looking for a very specific answer.... If you do not give the optimal answer they think you are an absolute idiot. Even if your answer works, solves the problem, and while it may not be optimal it is not too inefficient....
Some Examples:
How would you shuffle a deck of cards? They are looking for the Fisher-Yates method http://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle other answers are "wrong"..... This is not something that you are likely to know unless you wanted to shuffle cards before and specifically looked it up. You might stumble upon it in the course of doing the answer, but from what I have seen they expect you to know this cold so it is doubtful there will be much time given to allow finding the solution. Another less efficient (but maybe more obvious) way is to create a new array with a pointer to the original array and a number which is a random number then sort the array by the random number. Then use the sorted array to construct a new array of cards. In any case, I got 0 credit for presenting that to a recruiter.
Another example is the question about how you would detect a duplicate number in a list of n numbers all from 1 to n-1. The obvious answer (which is relatively efficient in a time perspective) is to use a hash table to insert each element and if you find one already inserted then you found the duplicate. The optimal answer is because the numbers are between 1 and n if there are no duplicates, you can get the expected sum as n(n+1)/n. Then if you sum up the array you get the actual sum which is n-d less than the expected sum. So basically n - (Expected Sum - Actual Sum) = duplicate number... It's a pretty special case.... I actually saw something before in some online post on interview problems ages ago about a related one with the same trick, so I was okay....
Another one, reverse all the words in a string without using any additional space. I had to think about it and the recruiter was pretty impatient in the 5 minutes I thought (splitting and re-joining the string in reverse, or going word by word into a new array are both very easy). I came up with finding the border of the last word, finding the end of the first word, and constantly shifting the entire list down by 1 and then inserting the appropriate letter. Then repeating until you've reached the end of the list. This method worked and the interviewer agreed (he was a bit technical), but it is pretty inefficient. When I got home I searched for the optimal answer, and it is to just reverse the list, then reverse each individual word. Some people might come up with that, but in five minutes with the pressure of an interview and never having seen the question before, I think it would be difficult....
Now it's true once you have seen some of these problems you can solve them easier. Because there are some similar questions with some of the same tricks. I know especially the n(n-1)/2 formula and number list has several variations. But still I don't know what these questions test. A FizzBuzz is something that everyone should be able to do (although i have seen variations that are not so simple in which case I start to question if even that is realistic for an interview situation without being able to type in/debug the code). Some of these questions are obvious once you see them, but if you haven't seen them they are not obvious. After all someone mentioned it took years for the first correct implementation of binary search to appear... Right now binary search is so obvious because everyone can read about it. But earlier it was a challenge to discover/implement it.
Nevertheless, I think the worst part is when non technical people are asking the questions because they cannot appreciate your solution is correct although not optimal. They just know your solution is not the one presented and hence it is all wrong, you get no credit for the attempt. Even non optimal solutions often show a knowledge of programming constructs. Unless I am programming poker games, I do not care how well someone can shuffle a deck of cards. And even if I was, after showing them the efficient algorithm I'm sure anyone halfway decent could follow it.
Template questions appear to just give an advantage to candidates who have been interviewing longer as they are more likely to have seen more of the template questions. Even FizzBuzz, the first time you see it you might freak out, but as you see it over and over again you become more used to it. The best thing you could do is give some coding challenge that requires custom business logic. E.g. create some dataset (array of objects/records) and then create some business rules to apply to each object and return an answer.. e.g. an some type of rating, etc. but very custom rules). While they have probably seen loop through records and apply logic a zillion times, your rules will be unique, so at the very least they would have to understand and successfully implement the rules you created.
Let's say projected Salary and a list of candidates and their top 3 video favorite video games, and perhaps a starting salary. Candidates who like Zelda get a 300 penalty, candidates who like the little mermaid get a 200 bonus. Candidates who like Donkey Kong and Super Mario Brothers but not Dr. Mario get a 300 bonus. Candidates who like Metroid or Kid Icarus get a 200 bonus, etc.... It seems a bit insane but it would show you their ability to translate business rules into logical program constructs and test their understand of boolean logic as well. Overall not much different than fizzbuzz except not using modulus and loops. You could of course give them the list and have them loop through it and print the results to the screen using specific output criteria as well.
