As a follow-up to @GregoryCurrie's answer, his answer reminded me of something a supervisor of mine at an earlier job did during the interviews: During one stage or sub-stage - most likely done with one other person assisting him with the interview - he asked a series of back-to-back questions, that were loosely of the following form:
Would you use / do you prefer Thesis A, or would you use / do you prefer Anthitheses B? Why?
Now, A and B were sometimes technical constructs of some sort, such as:
- Abstract classes vs. Interfaces
- Classes vs. Structs
- Pointers vs. References
However, sometimes they were other types of things instead:
- Doing the job quickly vs. Doing the job carefully
- Scrum vs. Other implementations of Agile
- Keeping it simple vs. Creating an extensive, heavily-engineered codebase
This was over four years ago, so I don't recall now what the questions were specifically - the ones he was asking were probably better, on average, than the ones above. However one thing that he tended to do with every question on the list was this: Each question was designed to usually receive back an answer of some form of, "Well, it depends..."
Well...depends on what exactly? And that was a major part of the answer. You had to give a reason. About 99-100% of the question's score depended on you giving a halfway decent reason.
And guess what? If you totally disagreed with him, he didn't care. He'd still give you full credit, basically under the following conditions:
- You gave a reason.
- The reason itself was at least sensible, whether he agreed with you or not.
- The most important part: You had thus demonstrated to him that you were cognizant of such matters, that you had spent time personally thinking about and analyzing these things, and that you were not simply working like a brainwashed robot, just blindly following whatever Person X or Website Y says without knowing anything about it yourself.
Personally I found that it worked very well, and the people that this man hired were generally very good to work with, in terms of software development and in terms of general team cohesiveness. It was one of the best experiences I've ever had working with other people.
So again, this is kind of supplementing Gregory Currie's answer, which reminded me of this interviewing technique. As for your question about abstract classes vs. interfaces, you could potentially even skip the "What is the difference between..." question, and you could optionally choose to just jump straight into:
Would you use / do you prefer abstract classes, or would you use / do you prefer interfaces? Why?
If they just say, "Interfaces," but they can't explain why, something's wrong. And really, something's wrong if they abandon abstract classes altogether, with or without a reason. They should personally be open to both (even though they'll probably want to usually employ interfaces, when it makes sense to do so).
However, even if they do say, "Interfaces 100%" - a suboptimal answer - they need to at least be able to give you a reason why. It needs to be a reason that shows that they have thought about this themselves - that their decision at least makes some kind of sense, and that it is their own decision, not just what somebody else told them.
One type of person this kind of question will help you hire is one who is curious, open-minded, and willing to grow.