The programming question (in a previous blog - Quick BrainSharpener #4) was designed to get people thinking about an overall design of a problem. Besides simply coming up with a solution, this question also aims to give insight to the candidate's thinking patterns. When you are given a technical challenge, do you directly tackle the problem? Are you more forward thinking? Do you start to get curious about the context of the problem? Do you ask questions? Do you ask the right questions?
What type of developer are you? What types of traits* does your interviewer want you to exemplify? Perhaps this is always a good question to ask your interviewer before approaching a problem.
*Should I be thinking about extensibility? If you are asked to write a function, ask how often it would get called in his/her hypothetical program? Does it have to be designed to be highly performant? So much so that it may impede maintainability and readability? Given a Memory vs. performance: which gets the nod for the particular scenario presented?
If this is an open ended problem (and a language agnostic challenge), do you carefully choose the right tool (language) or do you start coding with your favorite language? Should you opt for a dynamic loosely-typed language or a strongly-typed language. And are you conscious of your choice and can point out the pros/cons of your language (i.e. compiled vs. interpreted)?
As much as an interviewee is stressed out, it must be a stressful experience for the interviewer. Whether your interview process is a few hours or an entire day or two, generally, one interviewer will only have an hour of the candidate's time. During that time, he/she has to assess your technical abilities and make a decision. First, they have to determine that your personality (or the guise that you put on for the interview =P - this may be non-intentional as nerves/stress can play a huge factor on someone's behavior and performance) will fit with the rest of the team. Then, they have to judge your technical skills. I imagine coming up with programming problems isn't too difficult. And even if you run out of ideas, you can just take an existing problem and twist it a little (see Quick BrainSharpener #4). You just need to be aware of what it is your particular problem is testing? And the challenge is actually in determining how to evaluate a candidate's response to your question. You have to come up with a series of possible solutions and then rate each one. In fact, to put it in human terms, you need to get intimate with the problem. Having become intimate with the problem, you also need to resist being biased and judge the person's performance based on the time allotted. That's one of the beauties of programming and time. Given more time on a problem, you can usually come up with a more elegant/faster solution or at least refactor it in some way.
On another note, the interviewer also needs to ensure that the problem is explained to you in a clear and concise fashion.
I would also like to bring up the challenges of asking the perfect interview question regarding design patterns. It is somewhat of a challenge to ask such a question without actually directly asking, for instance, how to implement a singleton? The challenge is incorporating these problems into a real-world situation and still keeping it fairly technical. Sure, you can ask them when they would use a singleton. But in such a case, you wouldn't be presenting them with a programming problem that they are getting their hands dirty on. So what to do? Well, perhaps another approach is to actually give someone an isolated piece of code that exists in your current system/service and have them run with it. This may already be code complete and a scenario with an obvious design pattern that you removed to see if he/she tackled using a structured approach or perhaps completely refactored to something better. In scenarios where you are actually giving them completely hands-on tasks (with IDE and compiler in hand), you would lose touch with being able to gauge the person's thought process and it would also be more time consuming than a whiteboard problem. Before I digress any further from the topic of good design pattern questions and into the general challenge of developing a good measurement for technical skill, I will stop myself right there.
So, while I must say that candidates have more stress since their professional livelihood is on the line, it is no cakewalk for the interviewer either.
DISCLAIMER:
I have never been fortunate enough to attend interviewer training. The previous company I worked at did not have such a structure set up. I do, however, wish I had such an opportunity since it would directly or indirectly make you a better interviewee. It's like the old saying goes, you only really understand someone's perspective after you've walked in his/her shoes. Being deprived of such experiences, I use the poor man's methodology; I let my imagination act as a substitute for experience. And the above was a peek at the results.