53

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?

5
  • 1
    @JoeStrazzere we (over)use both. Perhaps I should have mentioned, but I actually don't care for a textbook answer, it's just a point where we can say "great you understand it, now what's the best choice of them to solve this more interesting problem", but if they lack understanding of the theory we can't ask the follow up question.
    – Chris
    Mar 10 at 17:08
  • 8
    Could you edit your post to indicate whether you're hiring for medior/senior roles or for something entry level where testing theory is often more common? /// Fair warning: with a specific example like this, a large amount of the answers you're going to get will be picking apart that specific example and whether it's theoretical vs useful. I'd have advised you to reword this to focus on something more abstract but with 8 answers here I guess that ship has sailed. It's not necessarily a bad thing but while the question is in our scope I expect some of these answers are not.
    – Lilienthal
    Mar 10 at 20:37
  • 21
    Do you then follow up with "Why are the better? Can you elaborate?" If they can't answer, it shows that a) they don't understand the theory and b) they have a tendency to accept things they're told without really understanding. B could be good or bad depending on what you qualities you're looking for. Mar 11 at 3:01
  • Are you looking only for candidates who already know C#, or for candidates who know how to program but not necessarily in C# or a similar OOP language? (For the record, you could do OOP even in C if you wanted to, so I could imagine someone who's been doing C or C++ expertly nevertheless not having a clue what you're talking about. Or someone who's been doing FP, etc. their whole life. It's not likely, but it's quite possible.)
    – user541686
    Mar 12 at 11:54
  • 1
    Additional background to try to address a couple of points raised: 1. It's a small company, so we don't have capacity to answer lots of questions all the time. We take more junior people on, but not people who only code exactly what they're told. Because we don't have capacity to hand hold too much, C# is a hard requirement for us 2. No, this is not the only sort of question we ask, it's one of many. 3. Yes, I follow up with things like multiple inheritance, extension methods, default interface implementations, but there's no point if they can't answer the first easy question.
    – Chris
    Mar 30 at 9:31

19 Answers 19

111

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.

1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Lilienthal
    Mar 14 at 21:03
28

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?

7
  • 12
    I disagree partially. You're right that not knowing the answer to a theoretical question isn't inherently proof of not having any practical skills, but knowing the answer to a theoretical question (actual knowledge, not parroting) is a great marker for technical skill. Theoretical questions allow you to very quickly identify whether you need to bother with more detailed questions. If an applicant can eloquently explain key concepts of OOP, I'll be more inclined to not press further and believe their aptitude, so I can focus my interview on other things.
    – Flater
    Mar 11 at 15:50
  • 3
    @Flater Here's something to consider. I was once asked if I had any ETL experience. I never heard the term. It turns out, I had been doing it before the term existed. If you're interviewing people who are older, they may have been doing something before the term existed. Mar 11 at 15:55
  • 7
    @Old_Lamplighter: Precisely my point. If they answer correctly, you don't need to investigate further. If they can't answer, that suggests you should investigate deeper. I had a similar experience when asked about string immutability. I had only worked as a solo dev and I understood concepts, but not the names for them. I had no idea about what "immutability" was, but when asked why string+string is a bad idea, I could comprehensively answer the memory impact of repeatedly doing + operations. So I very much get your point, but that doesn't mean you shouldn't ask that first question.
    – Flater
    Mar 11 at 15:58
  • 1
    Practical questions are great for finding out what they can already do, a theoretical question helps you find out if they understand enough to do something they haven't done. Solid background knowledge helps you understand options on how to solve a problem.
    – Issel
    Mar 12 at 14:59
  • 1
    @Issel If you had a choice between two candidates, one of whom had plenty of practical experience, but wasn't very aware of theory, and another who was heavy on theory, but little real experience, which one would you hire? Mar 12 at 15:12
22

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".

11

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.

6

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.

13
  • 4
    Bit of a nit, but isn't abstract classes in C# quite clear cut? In other words, there isn't a "degree" of being an abstract class. Mar 11 at 4:53
  • 3
    "Any programmer worth their salt can find anything that they need to know very quickly." that would be true but they need some basis. If somebody never did OOP, their search would be hampered by not even knowing the keywords to use. If they can give a basic outline of a concept, they can find a lot more about it and understand it deeper very quickly.
    – VLAZ
    Mar 11 at 13:13
  • @GregoryCurrie: The distinction is a lot less clear cut in C# 8 and onwards. See jeremybytes.blogspot.com/2020/10/… .
    – Brian
    Mar 11 at 13:52
  • 1
    @Brian Thank you. That's very interesting. Now I'm beginning to wonder if the OP is aware of the changes on C# 8, which would be a bit ironic if they didn't. Mar 11 at 13:55
  • 1
    @Davor: No-one claimed it's about "what you want" - how do you get that idea? Anyway, I'd argue that in a decent company, your PC is ready from day one, and any accounts the company provides are already set up and ready for you to use. Yes, of course you'll be introduced to colleagues and get product demos - and, depending on the product, you may well have some extended amount of time to explore the product and the underlying development setup. I think it would be exaggerated to call this an "onboarding process", but all of those activities would be good answers to the question. Mar 13 at 11:13
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.

1
  • Definitely agree with your idea on this one, Joel ... "what are their human communication skills," if they actually have any. 😉 How well can they explain? If they are "caught off-guard," how well do they recover? Some folks out there are fabulous at dealing with computers, but they absolutely suck when dealing with people. Mar 10 at 19:33
5

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.

13
  • 4
    In that situation, Insertion Sort should be preferred over bubble sort. Just as easy to implement and better real world performance. Mar 11 at 8:18
  • 2
    @JackAidley, you're assuming a list and not an array, right?
    – o.m.
    Mar 11 at 9:24
  • 1
    No, it's true for an array as well. Bubble sort is just plain bad. Mar 11 at 9:43
  • 6
    Apart from number 4, what job are you hiring for that needs those things? I have been a developer for 25 years, but none of the first three points ever played a role in my work. I'm sure there are development jobs that need that kind of rather academic knowledge, but I would say they are a minority. I say academic for point 3 because that constraint is very artificial, I prefer candidates to use a build-in mechanism, and if it's not optimized for lists of 4 entries, than the gains from an optimized algorithm are not noticeable in applications I wrote so far.
    – nvoigt
    Mar 11 at 11:25
  • 3
    As a beginner, everytime I was asked these types of questions I thought : what are they programming here that they have to ask these types of questions? For me, these are trick questions. Maybe they do or do not have anything relalated to the job. It doesn't make sense to ask them everytime. Mar 11 at 15:33
5

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.

1
  • 1
    I think the key to this question is understanding the multiple inheritance limitations of C#, not the theoretical differences between the two constructs.
    – throx
    Mar 11 at 22:19
4

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).

4

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.

2

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.

1
  • 1
    Communication skills are important for a developer. You need to communicate with other developers every single day. Someone who can't communicate technical concept is a bad fit for development in a company.
    – Davor
    Mar 13 at 11:05
2

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.

1
  • "Not knowing difference is no go for senior C# role" - really? Because I would say it's a no-go for junior role. I wouldn't even bother with something that's OOP 101 first semester lesson for seniors.
    – Davor
    Mar 13 at 11:07
1

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 :)

1

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.

1

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.

0

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).

1
  • Kids these days would go nuts trying to use the Borland compiler for C. Mar 11 at 21:19
0

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.

0

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”)

0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .