[aDemoUzer]

In my view the interviewer has made biased assumption: IF someone who cannot give concise and clear questions about the concept THEN they don't know about it.

You can consider it a shortcoming on my part or reality for most programmers, but I don't tend to memorize names of concepts, I just know how to use them. i.e. I may be using inheritance or polymorphism in my code, but my brain does not every time thinks about what these terms mean and am I applying them as they are defined. I have been programming for years and OOP has become second nature to me; I know how to apply OOP, but have long forgotten most of the terms.

In my view, when interviewing, the questions should be practical problem so it tests user's ability to program a solution, not about being able to churn out the definition. Example: If you want to test someone's OOP expertise, give the person a list of classes and ask them to create a UML or how they would structure their classes. Example 2: Give them a problem like, create 2 classes: Animal and Dog. All animals have a name and a dog can bark. Test to see if the programmer would extend Animal class from Dog class, or maybe he decides to make an Abstract class out of Animal class.

The only downside of these questions is that you would need to have interviews who are competent in the OOP concepts themselves. Continuing to ask dictionary questions is a cop-out solution to not having technical interviewers and it is easier for someone to check if interviewee is able to mention some of the keywords that are in the definition you found on wikipedia.

Unfortunately, you will continue to reject most developer job applications and miss out on lot of great candidates.