I think some employers just want to trip up otherwise good candidates up on purpose by asking tricky questions that they already know the answer to and them privately snickering at them when they thrash with it.

Employers should think about what they are trying to learn about a candidate and ask reasonable questions that are designed to expose that skill. For example:

Question 1: Translate a known algorithm into working code

They give you the algorithm, so its not a question to see if you can solve a puzzle on the spot. It's a question designed to see how well the candidate can translate a requirement with a known algorithm into working code. This kind of work is typical in the life of a working software engineer. This should be a single function of code, and we're looking to see how well they structure their loops, if statements, data structures, etc. Should be able to be written in 30 lines of code or less on a whiteboard. Follow up question to discuss runtime order. As a slightly harder alternative, give them two algorithms of the same problem, one an O(n^2) and one an O(n log[n]), ask them to write out each one and compare and contrast the runtime and space complexity of each algorithm.

Question 2: Flesh out a multi-function solution with working code

Similar to Question 1, they give you the algoirthm, but its more complex and requires breaking it up into multiple functions to solve it. They give you the names of the functions, and they expect you to flesh out the code for each function. This tests the candidate's ability to work with more complex coding scenarios and provides an opportunity to discuss separation of concerns. Ask follow up questions about other ways to divide up the functionality. Discuss runtime and space complexity of the solution.

Question 3: Object Oriented Class Decomposition or Functional Decomposition

This question is the reverse of Question 2. They still give you the algorithm, but the overall question is more complex and we're looking for the candidate to decompose the problem into separate classes. This time we're only looking for the names of classes and methods, not the code inside them, just a brief description of what each method would do. If the project uses functional programming, ask the same type of question for a functional decomposition (looking for curry's, closures, etc.). Discuss runtime and space complexity, as well as any other built-in data structures that would be used. This purpose of the question is to test the candidate's understanding of object oriented design.

Question 4: Education Level Appropriate Algorithm Design

Give them a problem without the algorithm. Make sure the question is appropriate to their education level. Choose a problem that has known O(n^2) , O(n log n), and O(n) or O(1) solutions. Ask the candidate to talk through how they would design the algorithm. They don't need to code it necessarily if they don't want to. We're looking to test the candidate's problem solving process and knowledge of algorithm design. Do they ask clarifying questions? Do they verify the behavior for certain input data, etc. Be purposely vague about the question and see how they proceed with it. Let them try to design the algorithm without assistance. If they get stuck, tell them that there is an O(n^2) solution and ask them to solve that. Then proceed to the two faster solutions. Discuss space and runtime complexity. Here we are looking to test the candidate's skill in algorithm design, but focus on basic algorithms that are appropriate and typical of the life of a software engineer, not ask them to solve tricky puzzles.

Question N: Hybrid questions of the above, as needed and appropriate

Be sure to have an idea of what you are expecting to see in a candidate with each question.