You know, the more I read suggested interview practices and the responses they elicit, the more I think that the best interview question would be to get the candidate to critique a few interview questions.

The point here is not whether this is good practice, or whether the candidate knows the answer, or whether they would write it themselves, or whether they get the right answer immediately, or whether they automatically know the darkest corners of the C++ spec (of which this isn't one).

The point is whether they can reason through, with the interviewer, and then potentially change their mind if they find that they're wrong.

Part of being a good programmer is finding the good ideas among the dross, finding the right implementation technique among the many at their fingertips, and finding the right design among the myriad plausible constructions.

If you can't find the good ideas in these sorts of interview questions, if you can't read carefully enough to see that the whole point was to uncover whether of not the candidate can reason through then potentially change their mind, or if you think that to do so isn't an important characteristic to test for, then that tells me something.

Yes, it's important to see why things don't work, or are broken, or are a bad idea, but the ability to find good ideas is infinitely more important.

I like this interview question, and if you don't, then we're not a good fit. It doesn't mean you're a bad programmer, it doesn't mean (necessarily (I hope)) that I'm a bad employer/manager/programmer/interviewer - but it doesn mean we probably won't work well together.

But I could change my mind if you provide better arguments than the ones I've seen so far.