John Kador, who's written a number of books about interviewing and a new one coming out, has an article about brainteaser and riddle interviews on Darwin. Kador gives pointers on how to answer the questions, and if you're a candidate, you should read his suggestions. They will help you in the interview.
I have a problem with the belief that these questions are useful for determining anything useful about a candidate. Brainteasers discriminate for people who like word problems. Do your technical staff need to be excellent at word problems? Since there's a lot more to work than word problems, my answer is no.
What your candidates need is the ability detect problems and access to enough techniques to solve them. When inexperienced interviewers (or inexperienced managers) use brainteasers, they expect one right answer (even when there is no right answer). Well, guess what. In almost every organization I've worked, we never had one right answer. We had choices to make about possible right answers, and the best people were those who managed the ambiguities of work while continuing to work towards a right answer. Even though many brainteaser questions purport to be listening for thought processes (the way interviewers listen to hypothetical question answers), my experience is that too many interviewers think the questions deserve one and only answer. What a bogus way to discriminate against candidates.
If you really want to know about a candidate's thought and problem-solving processes, ask the candidate to perform an audition. Take your product, explain a bit about a part of it, and ask a developer to design an add-on. Let the developer work for a while, and then come back and have the developer explain what he or she was thinking. What made the developer choose that design? What could go wrong with the design? If you already thought of this and rejected it, explain that to the developer. Does the developer have other options up his or her sleeve?
When you ask a candidate to audition like this, you're asking the candidate to perform work in a close-to-real work context. An audition helps you understand how the candidate approaches solving problems.
Here are some possible audition-kinds of questions, in addition to the design question above:
Context: Workflow application. Explain the application to your candidate. Your manager says speed up the application. What do you do? Interviewers: listen for some of these techniques: elicit requirements (the whys around speeding up and how things need to work), interim deliverables, selling speed/changes to customers, and specific design issues the candidate has seen before.
Context: Transaction processing with web front end. Explain application to the candidate. How would you test this? Interviewers: listen for evaluation of risk, how to tear apart the problem, combinatorial testing to deal with proliferation of browsers.
Context: Real-time embedded control system. Explain application to the candidate. You have a problem with intermittent crashes. How do you find the problem and fix it? Interviewers, listen for: gathering all data that already exists, reading the code, inspecting the code, partitioning the code with output to gather data.
Since these are your applications, you'll know more about what to listen for. These are real applications and real problems. Suitable candidates can answer these questions. Unsuitable candidates can't.If you're a hiring manager or part of an interview team to hire candidates, think about the, qualities, preferences, and skills you require in a candidate. Then create an audition, test it on yourselves to verify it's a good audition, and then use it as part of the way you evaluate candidates.
Forget the brainteasers. They only make the interviewer and the company look stupid.