No, I've been the victim of these clueless types as well. It seems to be the latest business fad to ask these sorts of questions during interviews. Fortunately, the next fad will be just around the corner and we'll probably be assessed on our personality traits by the color of our socks.
Or something equally nonsensical.

The really sad thing is that technical people who really ought to know better are asking these nitwit questions - not just the PHBs.

When I interview candidates for coding positions, I *always* include at least one or two simple coding problems in the interview. They aren't the main focus, and I don't expect people to write code that's very complicated, and I don't expect that the code will be perfect enough to compile. It does seem to me to be a reasonable way to verify someone's claims about how much coding experience they have. I don't expect people to know every nook and cranny of the language, but I do expect that someone will know how to iterate over an ArrayList.

Are you running into interviews where they are expecting you to code something a bit more substantial? Can you recall an example problem that you were given to design and code?

It only happened to me once, for a job at a hotshot MS spin-off shop starting up in the Seattle area. He not only asked me to write about a dozen lines of C on the blackboard (IIRC, to insert an item into an array, showing that I knew from which end to copy ... or something), but he also asked me for a complete list of test conditions that would be necessary to show that the code was correct. (I did what he wanted, but not before asking him why his shop didn't already have libraries in place for that kind of thing.)

I'm glad he did that at the interview. Otherwise, I might have wound up taking the job or something. It was obvious that I was dealing with a group of disgruntled former Microsofties who were convinced they knew how to do it right. (In which case they didn't need me, now did they.)

I have been on both sides of this situation, and in the past 3 years I have noticed that techinical questions that require coding have become more common for me. I personally don't mind them, and it doesn't seem fair to say that code questions are not fair to ask because it is a stressful situation. I mean the entire interview is a stressful situation. It is equally hard to explain different strategies for web server failover in 10 minutes. I look at it as a chance to show that if I have recently been coding.
On the flip side when I interview people I do ask them a simple coding question. One I like to use lately (because I work for a web company) is let's design and then write a servlet to record unique visitors to a web site. The candidate can solve the problem however he wants and he get bonus points with me if he ask questions about requirements. Then as he codes the solution we can see if he has written much Java lately.
If he doesn't know the syntax of JDBC or servlets I don't care, but I have had atleast a quarter of candidates not be able to use Vectors or say File IO despite the fact that their resume says otherwise. And references are good, but "taking someone elses word for it" can be a bad business practice.
Bottom line for me is we are hiring you to design AND code so in the interview I think it's fair for you to show you can do both.

I've had my share of both "write code to do X" and "design an object model for Y". The other I'd get is to be shown some code, and asked, "what's wrong with this picture?"

The "code on the blackboard" questions are pretty stupid, because they really don't tell you anything other than if that candidate has memorized syntax and APIs.

Simple design problems are useful if you want to hire a programmer who can think fast on their feet. You don't necessarily want to hire someone who will spend endless weeks trying to design the perfect solution when you don't have that time. There is no such thing as perfect design. And in my job, I am often asked to come up with practical design solutions very quickly.

But the best way to gauge a candidate, in my opinion, is to ask detailed questions about a project on their resume, and play devil's advocate. I can pretty quickly figure out what their role really was, and to what extent they understood what they are building.

I have only had a few interviews that asked for code examples. Most of the coding that they asked for was kind of trivial stuff. You know, questions that verify that you have at least a basic knowledge of the subject. I do remember one time that was quite memorable.

I was working for a Sillicon Alley company. We had a new VP of Software Engineering come in and he was supposed to run the department. At that time it was before the great dotcom bust and they were eager to expand. So they were trying to hire developers like mad, they even had a bounty on their heads. At that time I didn't think that he had too much reguard for me. Many people came in and none of them were hired. I imagined at the time that if I were to come in and try to interview under him I wouldn't have been hired; I had graduated from a cheasy university w/ a BS of CS and the VP had a doctorate from Harvard. One day he asks me to look at the questions. One of them was, "if java didn't have a String Class, how would you design one? What type of constructors would you include." Of course I easily answered the question: he wanted them to tell them that they would use a char or byte array to store the contents and a String constructor that would take a String as it's arguments. I also told him that I had already done little excercises like this in C++ (trying to really learn it) and also had taken a peak at the java.lang.String source file. He told me that alot of people couldn't answer. At that point I started to have alot more self confidence in myself as a developer.

The thing though that I saw which seemed really unfair was when the VP let fellow developers do interviews. I don't know if it was a sadistic streak in them or if they were trying to make sure that no one was hired so one of their buddies would get the position but they would come up with these brain teasers that had absolutely nothing to do with programming, software design or anything else. In fact the questions seemed more suited for entry into mensa than a position as a software developer. I remember one question was to decrypt a series of dots and dashes into some phrase. Maybe that would be a good test if you were supposed to be WWII/Early Cold War code breaker but a developer?

I think maybe the biggest problem is that in development there is such a broad domain of knowledge necessary needed to create applications. Now compound this situation with the fact that pretty much each shop using it a unique set of tools to create and maintain these applications and finding a candidate through a fair systematic means becomes very difficult task (if not impossible). As a result I believe that many hiring managers (not all of them mind you) have fallen on arbitrary means of selecting candidates. Some of them are quite whimsical: one guy I know who is a unix sys admin confessed that once when he was hiring he threw out all resumes that had any MS certifications on them. All the way to illegal: a friend told me that his manager wouldn't hire a female developer for his department because it would interfere with his porn downloading habits. I can even remember in college people from my college asking me how did I get beat out for an internship by the class dunce (I believe that we had at least a 2 point difference in GPA and no he wasn't just really skilled but bad at class).