Home » Interview » 7 C# Interview Questions [That Weed Out The Losers!]

7 C# Interview Questions [That Weed Out The Losers!]

image

So, once again, the place I am currently working has been interviewing for some more programmers and we’ve had to laugh at some of the answers we’ve received on some pretty simple question.

For example, in answer to “How do you create an object in JavaScript?”  One applicant responded, “I always use the WHERE keyword.”  What?!!!

And that naturally got us all talking about good interview questions.  How can we tell that the applicant is even worth interviewing?

The following questions are not meant to be THE interview.  The questions are meant to shorten the interview process by ensuring the applicant has a basic understanding of the language they will be expected to work with.

C# Interview Questions

1. What is the difference between an Object and a Class?

This is an object oriented 101 question.  So if you can’t answer this, I might try a few other questions for show, but you’ve probably already been counted out.  The way I always described the difference between the two is that the Class is like a cookie cutter and an Object is like the cookie.  The class defines what the object is going to do, but the object is the thing actually doing the work.

A more technical answer would be that the Class defines the object while the Object is the Class active in memory.

2. What is “Polymorphism”?

This is my first stab at making sure you understand the basics of object oriented programming.  Does your answer at least include the concept of virtual functions?  Here is how I explain polymorphism.

Polymorphism gets at the idea that you can have a method in a parent class and a method with the same name in a child class.  If the method in the parent class should be marked virtual and the method in the child class should be marked “overrides.”  At runtime, the decision as to which one is called is based on the type of the object that the method is called from.

Some might want to include other concepts

But historically, polymorphism has been limited to the basic idea of virtual functions and the applicants response should, at the very least, reflect this answer.

3. What is the difference between overload, overrides, and shadows?

Again, this is to get at your understanding of object oriented programming generally and the sometimes confusing keywords in the language.

– Overloading gets at the concept that you can have multiple methods with the same name hanging off a given class as long as the methods all have a different signature (parameter types), the code is legal.

– Overrides is how polymorphism is implemented.

– Shadows flips polymorphism on it’s head.  If you mark a method as shadowed using the “new” keyword, then instead of the method getting called based on the object type, the method gets called based on the variable type that is holding the reference to the object. So, give class A is a parent of class B and both have a method foo() and foo() is marked with the shadows keyword.  If you declare a variable of type A and point that variable to an object of type B, when you call foo off that object, A.foo() will be called.

4. What is the difference between the keyword  “String” and the keyword “string”?

I work with some pretty sharp guys and even they stumbled on this one.  Do YOU know?

When I was teaching C# for a training company, I would say, “The only difference is that ‘string’ turns blue in the editor.”  Of course now that you can configure the editor, that’s not really a good answer.  But you get the point.  Both keywords compile down to the same intermediate language.  Technically, “string” is an alias for “String”.  “String” is the proper class.

5. What is “int” an alias for?

Since we’ve already used the term alias by this point, I’m digging deep to find out just how much you know.  The proper answer is that “int” is an alias for the Int32 type.  I can forgive you if you say “class” but it really isn’t a class.  It is a type.

6. What is the difference between a value type and a reference type?

Once again, I’m trying to find out how well you know what is going on.  Do you just hack at your code until it seems to work, or do you really understand what is happening under the hood?

Again, when I was teaching this, the explanation always went something like this:

The value of a value type occupies memory on the stack and when you do an assignment from one value type to another the data is copied from one memory location to the other.  Each variable is changed in isolation to the other.

A reference type is a variable on the stack that points to memory in the heap that actually holds the value.  When you do an assignment from one reference type to another, only the pointer is copied.  In the end, both variables point to the same location on the heap.

If you change the value of a reference type from one variable, the other variable is impacted with the change because it is the same location in memory you are changing.

The key part of this answer is that the value of a value type occupies the memory the variable represents and that the value of a reference type is pointed to by the memory that the variable represents.  The stack vs heap issue is secondary and in fact gets clouded by the fact that once you put a value type in a reference type, either by boxing or by including it as a member of a class, the whole stack vs heap question gets quite murky.  But, using stack vs heap as a general way of discussing the main issue is a starting point at the very least.

7. What is the primary factor in making code testable?

OK.  You knew I had to stick this one in here, right?  I doubt most programmers have given this much thought so it is OK if they have to spend some time thinking of the answer.

What I’m hoping to hear is that dependencies make code untestable.

Simplistic answer?  Maybe.  But the answer to this question, regardless of if it agrees with mine or not, will tell me if they’ve had any experience writing unit tests.

 

Other post in Interview

Related Post

  • 7 JavaScript Interview Questions [To Weed Out Imposters]7 JavaScript Interview Questions [To Weed Out Imposters] Last week, I posted 7 interview questions for C# programmers.  I guess I forgot that people can’t see in my brain.  So, let me be very explicit this time.  The “weed out the losers” […]
  • Revisiting The Technical InterviewRevisiting The Technical Interview I’ve written about the technical interview before.  I’ve written both for and against code interviews.  And I’ve provided both C# and JavaScript questions to weed out fake programmers. But […]
  • 3 Reasons Responding To Useless Interview Questions Makes You Happier3 Reasons Responding To Useless Interview Questions Makes You Happier I’ve noticed a trend recently.  Someone will write a post about some technical interview question and someone will write a comment about how that’s such a dumb question that they wouldn’t […]
  • Cracking the Programmer’s Interview CodeCracking the Programmer’s Interview Code Several comments this week contribute to this week’s post. The first, and the one that pushed me to write this post, is a discussion over at Simple Programmer on a post called “Cracking […]
  • Your Programming Resume is GarbageYour Programming Resume is Garbage Over the last several years, I’ve had a chance to read a few Programming Resumes.  Or, I should say, TRY to read a few resumes.  But frankly, if the Programming Resume I typically see is […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS. Does your team need additional help in any of the above? Contact Dave today.

3 Pingbacks/Trackbacks

  • Mark Mennell

    I am afraid I would have got the first question wrong despite being a C# .NET developer for 10 years. The Class vs. Object question is a terrible in C# one because “an object is an instance of class” is not the only answer. Indeed Anders Heljsberg says: “everything in C# is an object” in this case meaning everything automatically inherits for the C# Type: Object… My I suggest you make the question less ambiguous or drop it all together since it is covered by the reference vs. value type one.

    • thedarkfreak

      I’m afraid I must disagree with this. As the author stated, this is going to the basics of object-oriented programming. Class and Object have two very specific, yet slightly different, definitions.

      The Object is the actual running code that gets created.

      The Class is what defines the behavior of the Object.

      (A Class determines what an Object does; an Object is an instantiated version of a Class).

      The C# Type: Object is defined by the System.Object class.

      So, “an object is an instance of a class” IS the answer.

      • Jim Brown

        Still, some of these questions feel like trivia. And to nearly rule out a candidate on a question of semantics seems silly.

        I think the intent of the question is to understand that a class is defined and then executed in memory. When I think of that intent, the word “Object” isn’t the first thing that comes to mind, and I’ve been programming for 10 years as well.

        When I think of “Object”, I think of a type in C#, which is used to define other classes. That’s a completely different meaning than what the author is after. A poorly stated interview question to put so much emphasis on.

        • thedarkfreak

          Being able to keep separate the ideas of the contact, the definition, the Class, and the…thing created from that definition, the instance of the class, the Object, is still useful to be able to do. Most experienced programmers do it natively, just like all of the other abstraction they can do by heart.

          As I said to hairlessOrphan, the semantic issue seems to have been caused by OOO-based languages, like C# and Java, that try to apply the idiom “everything is an Object”.

          The definitions of Class and Object I gave have been the definitions of those words since the idea of OOO came into play.

          These languages, however, have all classes be a subclass of one, master, superclass – Object. That way, they can say “everything is an object”.

          And then things get confused.

          • Jim Brown

            Agreed that for an entry-level developer, being able to distinguish a class from an instantiated object is important. The criticism is that Object might not immediately make you think of the instance of a class in memory and could have different meanings depending on the context. And this is a C# interview…so that makes it more confusing by using “Object”.

            Maybe in the textbooks that’s the definition of Object but who cares? I don’t care if they can give me a definition. I want to know if the candidate knows that you can have one or more instances of a class running in memory, each with their own state.

            For such a weighted question in an interview it should be crystal clear what you’re looking for. Maybe it should be “what happens when you call the constructor of a class” or something?

            Definitions are for the classroom. Examples and explanations are for the interview.

          • Good conversation guys.

      • hairlessOrphan

        Yeah, Object is a class definition for the Object class. What’s the difference between a Class and the Object class? Well, do you mean object or Object?

        It’s a bad question.

        That’s why using the term “instance” is much better. What’s the difference between a Class and an instance of a Class? Once you word it like that, the question is unambiguous… and not very useful.

        Which makes it a bad question.

        • thedarkfreak

          I can see where you’re coming from. (Although, having people able to separate classes from instances can still be useful, as it should be a basic skill)

          However, the semantic confusion, in my opinion, seems to stem from definitions within C# itself. The terms Class and Object have been used, as defined, since the beginning of Object-Oriented Programming. Class referring to the definition, Object referring to the instance.

          To help the idiom of “everything is an object”, OOO languages like Java and C# have ALL classes as subclasses of one master class – Object.(Java is java.lang.Object, C# is System.Object) And then that messes with everyone’s heads.

      • sv

        Except that in C# (and Java, and probably other languages as well), an object is an instance of a class, which is also an object that is and instance of a class, that is ….

      • Mark Mennell

        I agree it is important to be able to distinguish between an instance and its definition. (I would be surprised if someone got the interview stage and could not).

        I am saying *Object* is not used by everyone to refer to an instance! It is not common terminology esp. in academic fields to refer to an instance as an *Object*. Morever it is correct to think the question is talking about the Type Object – which is the terminology the creator of C# uses! So an interviewee could get the question wrong thinking “Object” was referring to something else…

  • Mark Mennell

    Another terminology issue: I have not heard of “Shadowing” but I do know about hiding an inherited member using the new keyword, what if your interviewee has not heard the term either? I do not believe it is even mentioned in the documentation.

    • Rangoric

      shadows is the VB version of the “new” keyword.

      • HotN

        Yeah, I’d give the author partial credit for that answer. Had the article been titled “.NET interview questions” instead of “C# interview questions”, I’d call it correct.

        • The concept is called “shadowing” The keyword for it in C# is “new”. The problem with writing an article is that, unless I write like a lawyer and cover ever possible interpretation, someone is going to complain that I didn’t cover it “right” whatever the definition of “right” is in their book. 😉

          In an actual interview, this would look a lot more like a conversation where the obvious follow up question would be, “have you ever used the ‘new’ keyword in front of a method?”

  • Guenhwyvar

    Always nice to get them old nuggins working again. 😀

  • Earl Owens

    I just sent this to my son who is job hunting. Like most programmers I spend most of my time down in the code and have too little time to think about anything outside of getting the job done. I need to look at more of this too. As Mr. Mennell said I have never heard of Shadowing.

    • shadowing hardly ever gets used and is something I would personally avoid. In C#, the concept is implemented with the new keyword in front of the method.

  • illremember thistime

    Answer to Question 2 is only partially correct, you forgot ad-hoc polymorphism (function overriding) and parametric polymorphism (generics).

  • djlucas

    You might want to check your post for typos.

  • bbrown127

    So in response to question 7 you said you were looking for the answer, “What I’m hoping to hear is that dependencies make code untestable.” To a question of what makes code testable. So you are saying code being uncoupled from dependencies makes the code testable?

    Thanks for the insights!

    • I’m saying that code being uncoupled from dependencies is, in my opinion, the single biggest factor in making the code testable by unit tests. Not the only factor. And any answer that indicates that the applicant has has experience testing is a good answer

      • bbrown127

        Thanks for clarifying for me.

  • It’s-a-fact

    Nothing on Structures? Singletons? Interfaces? I’ve had all three of those in recent interviews. I’ve even had “What’s an assembly?” and I didn’t know how to answer it.

    • If we got past these questions, yeah, I’d have these as advanced topics.

  • Wouldn’t you want to ask some questions about programming? Something like: “What does this do, given integer variables?: a^=b; b^=a; a^=b;” (it swaps the values in the variables). You can follow it up with, “In C, you can write that as “a^=b^=a^=b;” but that doesn’t work in C#. Why not? (because in C#, variables are actually pointers to values, and when you change a variable’s value, the runtime actually produces a new pointer to a new value; meanwhile, the expression parser deals with the initial pointers all the way through, whereas in C, there would be no pointers involved in this example: the variables are primitives, which is something C# doesn’t have).

    Or how about something algorithmic: “produce an array which contains the numbers 1 to 20, in random order” or “Create a tree structure, populate it and read it back in sorted order”…?

    • Yeah. If we got that far. These questions are for weeding out people who wouldn’t be able to answer that anyhow.

      • Ah… yes. You can also do that with a keychain laser. You say “polymorphism” and then see how much laser light reflects off their eyeballs, as they glaze over…

  • theraot

    2: Inheritance is no the only way to archive polimorphism. Overloading and Generics are also forms of polymorphism.

    4: “String” is not a keyword in C#.

    6: Value types can be in the heap when they are boxed.

    7:
    There is unit testing and there is integration testing – and both can
    be automated. Strong dependencies will not harm integration testing. The
    notion of getting rid of dependencies only belongs to unit testings.
    So, from the get go, even if you cannot do unit testing, the code is
    still testable (by integration testing*).

    *: And don’t pretend
    unit tests will cover all, there are properties that emerge from the
    interaction of the parts (don’t forget System theory). For intance, unit
    testing will never get most threading issues.

    On the other hand,
    with dependency injection and the right tools (moq) you can avoid all
    those interfaces that the only thing they do is bring is bloating the
    namespace, increasing the repository size and making hard navigation and
    debugging.

    I’m not saying that interfaces are a bad thing, I’m saying that if you have them just for testing then they are not necesary.

    Consider
    the worst case: A is an static class, many other classes depend on A,
    and there is no way to create an interface or use dependency injection
    with A. You can unit test A! So when other tests fails, you know it is
    not A’s fault – if in doubt, it means you need more tests for A. What if
    A is not public? then make it internal friend of the testing assembly
    (And reevaluate its desing, it probably has poor encapsulation). What if
    many classes uses A* to share information? You may move A to singleton
    and make an internal friend method to set it, so the testing assembly
    can mock it. You may also want to minimize system logic in A. You may
    also consider moving to integration testing… there maybe racing
    conditions to spot there!

    *: For example A represents user configuration.

    • 2: No, but if the answer didn’t at least including my answer, it would be cause for concern. See the edited answer for mor.
      4: Technically, you are correct. You knew what I was trying to communicate though. Right?
      6: Extra points for knowing that.
      7: Yeah, yeah. But I want an answer that tells me they’ve done unit testing. The subsequent conversation would give me that.

  • Julian Hall

    Your suggested answer for question 6 is actually completely wrong. Value types can be allocated on the heap (e.g. if they are used inside a reference type), and reference types can be allocated on the stack (e.g. if the compiler detects that no reference can survive beyond the lifetime of the current function invocation). The real difference is how function calls using them as a parameter or assignments from them are handled: value types are copied (“call by value”) while reference types are shared (“call by reference”).

    • I think you are confusing pass by reference and pass by value with reference types and values types.

  • truth_machine

    I wouldn’t hire someone who gave such appallingly stupid and ignorant answers. A class is a type, and an object is a value of some type. Polymorphism refers to being able to apply operations to objects of different types. “as long as the methods all return the same type” — Bzzt! Wrong!

    And so on. It’s a waste of time to address the rest of the errors of someone so clueless.

  • swampwiz0

    I don’t believe “shadows” is used in C#. it seems to only be used in VB. The keyword ‘new” in C# seems to be the equivalent of “shadows”.

    • you are correct, shadows as a keyword does not exist. Shadows is a concept.

    • You are correct. The “new” keyword implements the “shadowing” concept. I’ve edited the answer to be more clear.

  • Peter Schulz

    These questions and answers do not point out bad programmers. This is a question-and-answer style employed by universities in examinations. And universities never turn out anybody who can actually do any work, just professors which do some hairsplitting word games as the above.

    And as noted by @truth_machine:disqus , most of it is wrong anyway.

    • I felt the same way until I started interviewing and found that most of the applicants could neither answer these question nor program, while the ones who CAN answer these questions (with answers similar to what I’ve given) are a lot more likely to be able to use the language.

      • I.V. Baker

        Actually these are fairly basic concepts but since I do not articulate them very often I sat for a second on some of them going… Well crap I do this all the time, but how do I explain it.

        Some of them I almost never use. Shadow, honestly I think I have used it a dozen times in the 12 years I have worked in .Net

        Override – yes
        Overloading – of course but Shadow… hardly ever and only in VB…

        As for thinking about the heap and the stack I only really do this when I start working on things that actually impact either in a meaningful way ( usually if my code blows up on me ) Then my old C++ skills boil up, but to be honest in an interview I would probably give you a blank stare and then the moment you start talking about it go… Oh yeah, and then proceed to give examples and detailed explanations on it. And i have been coding for over 25 years…

        Just saying that as far as questions go they are good fundamental questions but I can see where even I, not having thought about these things in academic terms in quite a while, would draw a blank for a moment and then given an example could provide ample explanation and ways of using these concepts.

  • Extra points for knowing more than the basics.

  • You ask what the point of the questions are. It tells me how much the applicant knows about they language they are using. Are they a hack that can get stuff done but they don’t really know why? Or do they have some basic understanding of how the language works.

  • Pingback: Automate the Planet()

  • Jay French

    I think the distinction would be that value-type “variables” would be on the stack, but value-type “properties” may not be.

  • Tommy Long

    You don’t have to have the same return type to overload a method, it’s simply that return type doesn’t constitute to the distinctness of an overload. For example:

    private int Foo() { return 1; }

    private void Foo(string a) { }

    I’ve overloaded the Foo method, for better or for worse, with a different return type.

    Personally, I’d have no problem answering any of the questions you’ve listed, but I would think poorly of a company that considered the above “good” interview questions. I suppose that is a matter of interview technique, and perhaps subject to how the questions were asked, but presented the above list as early/opening questions I’d likely thank you for your time, and leave.

    • We all have our thresholds for interview techniques we will tolerate. I just did a series of interviews (4 separate interviews) where each interview was nearly the same set of questions each time. Now, THAT was a waste of time.

      But I am curious how you’d weed out applicants who have no business applying for the job in the first place? You can’t do it from their resume because nine times out of ten, the resume misrepresents what they have done.

      • Tommy Long

        As an example, I’d ask if the applicant could talk to me about Dependency Injection. This is a high level pattern which demonstrates the implementation of several OOP fundamentals in a practical manner, likely opening or providing the opportunity for the candidate to express additional factors such as Unit Testing, which is what I need in most developers. I’m not so interested in being told the wiki definition of DI, but more the candidates thoughts. This will reveal experience, knowledge, enthusiasm, and ability to communicate.

        The ability to reverberate textbook descriptions (particularly those related to shadowing for which I’d prefer NO developer knew of), is maybe useful in more senior developers for teaching others, but is by no means a good way to “weed out” developers (in my opinion, of course).

        • I’d ask something similar once they got past the basics.

          These really are “prove to me in 10 minutes that I should interview you” questions.

          You may not like them, but you can blame the applicants who have resumes that misrepresent them for their necessity.

          Most of the places I’ve interviewed in the last year have asked similar questions.

  • A someAVar = new B();

    • ?????? ???????

      Got it, thought about vise versa variant, thank you.

  • Pingback: 7 JavaScript Interview Questions [To Weed Out Imposters]()

  • Pingback: Learning Terminology Increases Your Effectiveness()

  • swampwiz0

    It’s questions like these that make software development a poor field for a career. OK, so for this job, expertise in C# is needed, but when that becomes obsolete, expertise in the next k3wl field is needed. A good career field is one in which the knowledge is timeless, and not subject to whatever minutiae of the day is.

    • And what job do you have that has this timeless knowledge you speak of?