[JimboOmega]

I personally think the "CS curriculum" style problems are a bit ridiculous. How often have I implemented a tree as a professional? Especially in a sense where I need to think about the difference between the types? (Is it a red-black tree? A binary search tree? A b-tree? Which ones are sub-types of others? etc.)

The result being that before the usual technical interview I dust off the old CS textbooks and try to hit all the high points.

I like the idea of a small program - especially a business-relevant one like you mention. But if you limit it to 30 minutes, often that 30 minutes could easily be eaten up by setup of environment... which can be a huge timesink.

[bokglobule]

You're right about making sure the problem is gauged to the time available for the interview. I had my senior and lead developers work through the problem individually to see how long it took them. Typically, 10-15 minutes. And they didn't see the problem ahead of time. Wasn't meant to be tricky, but rather do they understand a basic data structure we use all the time in the context of a simple problem.

Personally, I don't buy the complaint that asking a candidate to write some code is unfair although I've had a few tell me so. For onsite interviews, I have them spend a couple of nights ahead of time working on a small web app with a few moving parts (UX, DB, validations) to see how they approach writing larger, more real-world code. They demo the app, then show me the code. Some people take real pains with what they do, fully understand what they used and why, and can talk about how they'd improve it if they had more time. Unfortunately, many don't do that for one reason or another. But this tells me what I/we need to know before thinking about hiring someone as a developer.