Are questions on theory useful in interviews?

Question

Our company have been interviewing for a C# position recently. One of the questions we ask is "can you explain the difference between an abstract class and an interface". I've been to many interviews myself where this has been asked, and it feels to me like it should be an easy 30 second answer before moving on to something more interesting

However, all of our recent candidates responses have been "I don't know, I only use interfaces because they're better," which you could argue the case for but doesn't really answer the question adequately.

Are questions like this useful to determine a candidate's skill in an interview?

If not, what would be some better questions to ask?

Answer 1

You are demonstrating the value of these questions yourself.

Nobody who understands anything about object oriented programming can fail to know the difference between an abstract class and an interface. It's not a case of spending thirty seconds googling it, everybody should know it.

In my mind anybody who says "I use interfaces because they are better" and can't explain why (which would involve knowing the difference) has simply read a blog saying "interfaces are better" and is repeating that statement without understanding why. Your mileage may vary, but I don't want programmers like that. I would be prepared to change my mind if they could explain when they might use an abstract class, or why interfaces are "better", and I would ask those as follow-up questions. If they don't understand that they are just "rote" programmers. (Some people make a good living out of being a "rote" programmer, and many companies hire them for jobs that are well-defined and straightforward, so nothing in itself wrong with that. But many companies prefer people with the potential to one day be a senior developer, or even an architect.)

In general understanding the theory enables a developer to make informed decisions. If you don't understand the theory you are reduced to just doing what the internet tells you, which may be entirely wrong if your situation is different from everybody else's. On the other hand if you are looking for code monkeys low initiative programmers then go ahead.

I would reject anybody who is using object oriented tools and can't answer your question. That makes it a useful question, because I can reduce the time spent with candidates who I will never hire.

Answer 2

When I interview people, I find that theoretical questions have outlived their usefulness, especially since someone can go online and find that out in 10 seconds.

A better approach is to ask them questions on their problem solving, provide them with coding tests, or to inquire about projects they've worked on, what interesting solutions they've managed to come up with, and how they attack problems.

The only time I hit someone with a barrage of technical questions was when I wanted the answer to be "I don't know". This was for a newspaper, where your mistakes would be very public, so I was actually screening out people who would try to hide their lack of knowledge. The person we hired said "I don't know" to every tech question and was hired on my recommendation.

The theoretical question still has it's place. For example, if you throw that one out and they respond as they have, you can ask them why they prefer the interface, or ask them if they could use an abstract class if needed.

Another good follow-up would be:

You are tasked with maintaining some code, and see that your predecessor has made liberal use of abstract classes. How would you approach this task?

Answer 3

Yes. There is value in asking theory questions.

Some questions will provide better insights than others.

Ideally you'd have a series of different topics. And rather than asking them to recite facts, you should ask questions that probe the practical application of the theory. So rather just asking, "What is X?" you follow up with "When would you use X?", "What are the pitfalls of X?" etc.

If you can't answer those questions, or have trouble answering them, they are probably not worth asking.

You have a variety of topics so that if they don't know what "X" is, you just move onto "Y".

Answer 4

Are questions like this useful to determine a candidate's skill in an interview?

They're useful in determining your candidate has good understanding of OOP concepts, which is important. Someone who cannot answer OOP theory questions isn't going to be a good C# coder. Be sure to ask several theory questions, and I wouldn't worry too much about a candidate missing a few of them.

You'll need to ask enough questions lack of familiarity with one or two OOP concepts won't take someone out. Remember, you can google the answer, you're weeding out people who have little to no OOP knowledge.

Answer 5

Well, "geek that I am," I understand the question ... but it's really not a great question. "Yes, there is a difference," but in practice it's a bit of an edge case. You're fairly likely to use interfaces, but you might never encounter a production application which contains a truly abstract class.

I really don't like to subject candidates to "technical quizzes." I really want to know what sort of software (s)he's done, and especially what was the work-flow that surrounded the candidate and how (s)he responded to it and blended with it.

Any programmer worth their salt can find anything that they need to know very quickly. And, I know, they're going to have to come up to speed in any new position. So, I really don't feel that I need to inventory what's now in their head. I might therefore ask them things like, "how would you prepare yourself to be productive here, during your first few days on the job?" It's really not too difficult to sniff-out a candidate who's bluffing – and almost none of them actually are.

Answer 6

I like theoretical questions for interviews less for the subject matter of the response as much as observing the response and the formulation of it. It's easy to regurgitate some response found online, and when a conversation on the topic starts it allows for areas to dig into actual knowledge and understanding.

The keys I look for are how "practiced" the answer sounds. Then I dig into areas of preference and understanding related to it. If they don't provide a lead-in like saying one is better than the other, I'll create that lead-in and generate the conversation. These kinds of questions are good for gauging communication skills, teaching skills, and things of that nature. It's also good to gain an understanding of the candidates ability to absorb high level concepts and be able to explain them effectively (which are qualities typically required of a senior software engineer).

If the question really is just along the lines of "answer the question, check the box" then it's effectively useless as an interview question. The observation of a response to that question really needs to go much deeper than the factual answer to it.

Answer 7

It is certainly worthwhile to find out if the candidate knows theory. Every so often, there are problems in practice which get the programmer/software engineer into fundamental issues.

• What is a turing machine?
  Being unable to answer means the candidate is a practical programmer with little academic basis.

• What is your personal opinion on P=NP?
  It almost doesn't matter what the opinion is as long as the candidate understands the question. It goes into questions of what can be solved exactly by a computer and what can only be approximated, if that.

• Are there situations where using bubblesort makes sense?
  Yes, there are. It might be that you cannot use an existing library for some reason and you know that there are only a dozen entries. Then ease of implementation beats runtime performance (which would matter with tens of thousands of entries).

• Have you used static code analysis tools? What are the issues?
  These tools are great to spot some common errors, but for theoretical reasons they cannot be perfect. There is even a scientific proof that they cannot be perfect. A tool is better than a hurried programmer, but not better than a programmer who takes time to think about a problem ...

Not knowing the answers on any (or all) of these doesn't mean the candidate failed, it just gives a little more insight into the skillset.

Answer 8

The thing that annoys me about questions like this is people treat them like general OOP theory, when usually they are more about a specific language's implementation of OOP.

In some languages, what they call an interface behaves very differently. In many OOP languages, one or the other construct doesn't even exist. In some languages that do have a difference, those differences are slowly being erased. Language designers are figuring out how to avoid the pitfalls of abstract classes without the restrictions of interfaces. For example, Java now supports default implementations in interfaces. Scala's closest thing to an interface, which they call a trait, can now have constructor arguments in the new Scala 3 version.

In other words, there is no universal, language-agnostic, set in stone difference between an abstract class and an interface.

However, talking about such nuances in an interview comes across as dissembling, whereas someone who understands none of that nuance, but who rattles off a memorized list of C#-specific restrictions on interfaces, will come across as confident. You're doing yourself a big disservice if you accidentally disqualify the person who has a broader understanding of the topic.

Answer 9

Do questions like this useful to determine a candidate's skill in an interview?

_{(Brief, zen-like answer this time):}

Questions like that don't measure skill, they measure (theoretical) knowledge.

In fact, it's impossible really hard to measure skill during an interview, and solely by asking questions. That's why coding tests and challenges exist (to gauge a bit their skill).

Answer 10

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
• Etc.

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
• Etc.

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:

1. You gave a reason.
2. The reason itself was at least sensible, whether he agreed with you or not.
3. 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.

Answer 11

TL;DR

Is it a problem if I don't know where to use abstract/interface?

Junior Developer - No

Senior Developer - Maybe (I'll be concerned)

TL or Architect - Thank you for wasting my time.

---

Long answer

It feel like a silly question at first since with a quick search you can find out how an abstract class and an interface work. You need to look for the practical knowledge instead of theoretical knowledge.

For a junior role it's fine. He/she will be doing most of his/her work on structures already implemented by the seniors. If he/she need anything complex they can just raise it to the seniors and they will take care of it.

For a senior role, he/she will need to know the structure, how it works and what they can and can't do with it. They need to know exactly where to use an abstract class and an interface. Blindly using an interface everywhere will be a disaster.

It determine a candidate's skill?

No, it just says he/she is weak in basics. But it depend a lot on the position.

Better questions to ask?

There are no silver bullets. You need to mix up different types of questions to check if he is good for the project. I'll use the following types of questions,

1. Communication skill (If he need to interact with the client)
2. DB and UI skills, In my case these are handled by other interviewers.
3. Questions to check theoretical knowledge.
4. Questions to check practical knowledge.
5. Questions to check knowledge in latest technologies.
6. Questions or written program to check logic.
7. (For senior Dev or above) Give a situation and see how he react. Something like, The production server show 404 after a couple of logins, development & staging works fine. What will you do?

PS: There are amazing developers who lack communication skills. It's your skill as an interviewer to gently pry out their skills.

Answer 12

They are useful. Not to find out whether they know that particular thing, but to find out more about the candidate.

I ask questions where i don't actually care whether he/she knows correct answer, but I will find out more about how he/she thinks.

But specifically about interface vs abstract class. Not knowing difference is no go for senior C# role (unless i know candidate is transferring from different language and is needed for other skills).

If someone mention other languages (eg. Pascal with reference counting interfaces) then it shows broader horizons.

And more importantly, it allows to continue to other questions (even if I need to "remind" the candidate what is the difference) about their use.

Answer 13

It depends on the role you're interviewing for and the specific question, but theoretical questions generally can be useful to try and understand if someone "gets it", although that mostly applies to the answers they answer correctly. The way they explain the concept can give you an idea of whether someone knows the difference or understands the difference.

For a reasonably low-level question like your example, I'd be okay with a Junior not knowing it, but if a senior can't answer this one, I'd be unlikely to consider them positively. But if they can answer it, listening to how they explain it to you will show you A) if they understand the theory and B) how well they can explain technical concepts to others. Both are useful skills for a software developer, unless you expect them to work entirely on their own.

Also, if someone gives me the answer "I don't know, I only use interfaces because they're better" then my follow up question would be "If you don't know the difference, how do you know interfaces are better?" because I'm sure the answer to that will enlighten me about the way this candidate thinks quite a bit :)

Answer 14

No, I don't think so, but if you have to give the Test before the exam than it is mandatory for you to read the basic information or the basics of the books but the interviewer will never ask the questions from the book he/she will ask the question about your knowledge on there products or the basics of the making of their products or if you had a experience in working in their line than they will ask what did you learn untill now. Or atleast they will ask you the logical questions if they satisfy with answer you will get call back. I my self working as software developer in one of the IT company. I do remember my technical interview they never asked me the theoritical questions but they sure did ask few basics things which we practically use everytime in C#. So if you don't have a theoritical knowledge that much but you are powerful in developing tools,forms and application than that should be enough for you to get selected.

Answer 15

Yes, theory questions are useful questions in an interview. In fact, theory questions are the most useful, as with sound theory one can usually fill the missing gaps in knowledge; but, without theory, one has a much greater difficulty filling those gaps.

For example:

I = (1/2)M*R^2

Is the formula for the moment of inertia of a solid cylinder. It is derived by evaluating the cylinder for all points of density through the rotating axis using the formula

I = ∫ r^2*d*m

A person who knows the "solid cylinder" formula can do calculations for solid cylinders; but, a person who knows the theory behind the formula can derive the solid cylinder formula, a hollow cylinder formula, a spherical formula, an irregular shape formula, and many other formulas for inertia.

Today you might not need these extra skills, but if the position is long term, you want someone who comes with this flexibility; as it is likely that future shapes won't all be solid cylinders.

"I don't know, I only use interfaces because they're better,"

That tells you some things immediately.

• These people don't know when / how to use abstract classes.
• These people have learned the language; but, not all of the type theory.
• These people might have issues communicating with your team, if your team communicates using theory-oriented language.
• There is a chance that these people also glossed over other items, focusing on the practical without learning the theory.

They may be right (in many people's opinions) that interfaces are better; but, they will be somewhat unprepared for scenarios where interfaces aren't used or where abstract classes are used as a convenience to avoid duplicating many methods.

More importantly, can the justify their position? If you ask them "Why are interfaces better than abstract classes?" You might find they really know the theory, but can't express it in formal language; as they only know it "in their own words". If they can't answer that question, it will be clear that they don't know why they have chosen their approach, which can be a dangerous thing in a programmer.

Answer 16

Depends but I think you should be asking questions specific to your organization. For example, if you organization does a lot of web-API work, it might be a good idea to make sure they understand basic response codes and what they might mean.

C# makes it really easy to use a wizard or wrapper class to do the work that just 10 years ago you had to write yourself. Just go into NuGet and search for a term and most likely someone already did it for you. No need to understand the underlying issue but in situations where you uncover a bug, such as if the API is not following expected results to the letter, then you're going to find your developers being unable to diagnose and fix the issue in a timely manner.

I think theoretical questions are good to understand the concept but I think everyone who passed a basic 101 course could answer those sort of questions. Plus the difference in speed is so small it might not really matter what you use unless the system is so critical that a fraction of a second makes a difference (thinking car software or medical sort of software).

Answer 17

Are theoretical questions the only metric?

When going to school, does been weaker in one subject, make the person a weak overall student?

It's complicated.

Of course the best candidate will give the best answer to every question.

People going to interviews in many cases are going to a stressful "test", not a discussion.

I have many times answered that I don't know, to get to answers I was sure of. I had a short time to show my best.

So paddle back and ask more "lead in" questions, and let the candidate feel more at ease to take time to think.

Answer 18

Ask yourself if being able to answer the question is a requirement for the job. There are things where you want one developer who can do something, but you don’t need two. With this question, someone can do an excellent job without knowing the answer. And if they don’t know it and need it, I can easily teach them.

(And if you hire an excellent Swift developer, they would have no idea what you mean with “abstract class”, and if you are lucky they know you meant “protocol” when you said “interface”)

Answer 19

It depends

1. Do you only hire people who have worked in C# for a C# position? I usually am comfortable with hiring a C++ programmer for any other object oriented language work - be it Java or C# or something else? A C++ programmer may not know the difference between an abstract class and an interface because there is no such thing as an interface in C++. In C++, one uses an abstract class (a class with a pure virtual function) to implement an interface. There isn't even an abstract keyword in C++, any class with a pure virtual function is called as an abstract class. And you use a class with pure virtual functions to implement an interface.

2. What position is it for? For someone with up to 3-4 years of experience, I don't ask any theory questions at all in the actual interview. In the telephone screen, I may ask some theory questions like your question. But in the face-to-face interview, all I do is to ask them to write code. Lots of code. Ask them do string manipulation, implement some data structures, do manipulations with data structures, recursion, pointers (last one only for C & C++ guys) etc. All I am looking for is fluency in code. With more senior people I also add some design questions, design pattern questions etc.