Brings up a very good point. When I was working for the government, we had to be VERY careful of what questions we asked during an interview process. Every single question and exercise had to fall within state and federal laws. The restrictions are amazing. That includes assumptions that can be made based on the questions - even technical questions. Small businesses get away with much more, but that doesn't make it legal. Once a complaint or a suit is filed (and they are more frequent than you would think) you have to be able to reconstruct the entire interview because in that case, the govt really is assumed guilty until proven innocent instead of the other way around. I have seen unqualified people hired because they refused to answer specific questions and the govt was afraid of a suit if they selected someone else. Some individuals would not answer a question they didn't know - even technical questions and claim religious or ethnic reasons, and if they were a minority - be careful. In small businesses though, you would not be hired and the small business will just make up a different reason as to why they didn't chose you.



>>The psycholofy of the question is this: sometimes a card is just a card and has nothing to do with programming. The ability to abstract, that is, to apply aspects of object-oriented programming to the image of a deck of cards, well it is not programming.
>>
>>Programming is a left-brain exercise; the use of an illustration such as a deck of cards involves the right brain.
>>
>>One doesn't necessarily have anything whatsoever to do with the other.
>>
>>I am of the opinion that, if you want to ask a question about OOP, ask a question about OOP, not about something abstract like how it relates to a deck of cards. That way, you will actually determine the candidate's knowledge of OOP.
>
>I beg to differ, unless we're looking for a simple coder - then we really don't need to know whether he's capable of abstract thinking. He's supposed to do what he's given, and to code it as the specs say. For anything above that, I'd expect my programmers to be capable of abstract thinking. Or else how would he know what can be generalized in a class? Even in procedural programming, I've seen people who couldn't grasp the idea of writing modular code, of reusable routines. They'd just copy any old routine and change a few lines in it to suit the new requirements.
>
>Besides, it's very hard to talk about the project with someone incapable of abstraction - just getting the same mental image to the point where we need to decide which way to go is burdensome.
>
>I've worked in all sorts of environments, from gang-of-mathematicians to the other end of spectrum, and believe me, the first case is much faster, because we could always build a case in the air and discuss it, without any need to build a test app, a mockup or anything. In some other cases, I've seen hours of work dedicated to try whether something would work or not, thrown away in the end.
>
>Now I see you meant to see applicant's knowledge of OOP. Beg to differ again - to me, knowledge is not as important as mastering the OOP way of thinking. It's a mindset, then a skill, and then a set of facts to know.
>
>>Besides, in this day and age, it might be politically incorrect to ask about cards, because cards could be either gambling or prognostication, and potentially in violation of the applicant's religion.
>
>Um... gives me some ideas. I may find some things in violation of my non-religion. Actually did once, there was some sociometric testing inside the office, and I simply refused to answer several questions, because they were either culturally biased or didn't apply to unbelievers.