It's the method, not the answer

Typically in an interview most employers are looking for smart people. There are some who care about specific knowledge and specific skills, but some of the smartest managers want to hire the most intelligent people because they realize that any job will involve a learning curve and smart people will typically be able to adapt, learn quickly and add more value long term. So how do you determine if someone is smart?Obviously knowledge is one part of being smart. What did they learn from their experience? Are they able to explain and teach things to you in the interview (after all, it is said that one truly knows material when they are able to teach it to someone else)? The other key thing is how they think. How does the candidate approach problems? When given something they do not know how do they think through it and put the pieces together? These are the sorts of questions the interviewer is trying to figure out.To dissect a person's thought process you have to ask them something they don't know. That is why you hear so much about brain teaser questions--like How Would You Move Mount Fuji? A person probably hasn't though about how to move a mountain, or count the number of gas stations in the united states, or relocate the golden gate bridge. The purpose of these questions is to analyze the way a candidate thinks about the problem. What resources do they use? How do they break up the problem? In these sorts of questions the interviewer is trying to determine how the candidate thinks about things.So what determines a good answer to a question that has no right answer? Well that is more difficult to pin point, as it is a way of thinking. The key to solving these sorts of problems is to be methodical and follow a simple pattern:

1. Ask clarifying questions and make sure the problem statement is clear. For example, where are you moving Mount Fuji? How accurate does the gas station count need to be?
2. Once you can restate the problem and you have identified the key parts, the next step is to break it down. Write down what you know. Use induction. What is your base case? If you had to move an ant hill how would you do it? How about a mound of dirt? How would you determine how many gas stations are in a town? A city? A state?
3. Once you have expanded the problem and come up with a general algorithm, make sure it works. Once you have done an example, work on optimizations. There are almost always better ways. Say things like "I am sure there must be a better way"...then don't talk. Let there be silence since the interviewer may offer a hint--they may also be happy with your answer. Pay attention to their body language and responses as that will help you proceed.
4. Once you have reached a point where you are confident in your solution and feel it is optimized as best as you can in the time alloted, tell the interviewer any underlying assumptions you made. For example, that the gas stations will change over time as new ones open and close and how you will keep track (or not keep track as the case may be). Let them know you are thinking about the usability and extendability of your solution. You should also make sure to check boundary cases (this is more important for coding problems, but could also apply here).

There are a lot of different "right" ways for doing these sorts of problems, but this method has been successful for me and I tend to find it useful in everyday work--not just interviews. Induction and being able to break a problem down can be very useful for all kinds of problems. And always remember that in these interviews, it is typically better to start with a solution that works--even if it is not elegant, and then iterate to the optimal solution. Do not be afraid to state the obvious--sometimes it ends up being the best answer--especially if you aren't able to come up with the optimum choice in time.