Insightful slashpost on the /. technical interviews story. Basically those asking about why riddles at all in a software interview are missing the point. The point is not riddles for the sake of riddles; the point is to, in the brief span of time that an interview lasts, get some insight into the interviewees’ mental processes — especially when s/he’s faced with a (possibly stressful) situation unfamiliar to him before. Does he approach the problem with enthusiasm? Does he try to think through? Or does he tune out? (Tuning out is often a sign of jadedness — something most product companies cannot afford). I’d be more inclined to take a guy who gets things wrong but explores the problem space than a guy who clams up.

And oh, what works for me probably won’t work very well for you — there are at least five worlds in software development, and I think industry veterans can easily think up more.