C# Potential Interview Question…Too hard? [closed]

Answer 1

I think it's a terrible question. I think any question is a terrible question when the real answer is "Run it and see!"

If I needed to know this in real life, that's exactly what I'd do: Create a test project, key it in, and find out. Then I don't have to worry about abstract reasoning or the finer points in the C# spec.

Just today I ran into such a question: If I fill the same typed DataTable twice with the same row, what will happen? One copy of the row, or two? And will it overwrite the first row even if I've changed it? I thought about asking someone, but I realized I could easily fire up a test project I already had that used DataSets, write a small method, and test it out.

Answer:

...ah, but if I tell you, you'll miss the point. :) The point is, in programming you don't have to leave these things as hypotheticals, and you shouldn't if they can be reasonably tested.

So I think it's a terrible question. Wouldn't you prefer to hire a developer who'll try it out and then know what happens, rather than a developer who'll try to dredge it up from his fading memory, or who'll ask someone else and accept an answer that might be wrong?

Answer 2

It takes all of 5 seconds in a real work situation to figure out what went wrong. Compile, test, oops.

I'm far more concerned on if someone can build good and maintainable code. Ask questions like

• How would you design for this, write simple abstract design, no code.
• Here's an object design. The customer came and said they wanted this. Formulate a new design -or- discuss reasons why the requirements don't fulfill actual customer needs.

Answer 3

As many have already stated, when I interview someone I want to find out if the candidate is capable of communicating, capable of writing code which makes sense and it can be easily understood by others, code which can be maintained and so forth. I personally don't like to spend time in exercises like the one proposed. Instead I'd rather give an exercise where the candidate will write code him/herself - even in a regular text editor - and from there opening a discussion based on code review, improvements as so forth. No need the code to compile: compiler will do its job, eventually. I know many people may disagree on this approach, but so far I have found this the best way of finding good candidates.

Answer 4

Code given in question will print B::Foo.

Answer 5

Couldn't agree more with Joel there. I have 20+ years experience design and coding, and the first thing I thought of when I saw that was: It won't even compile.

I made that assumption because I try to avoid overloads that differ by only a single datatype, and in looking at the code didn't even pick up on the int/double difference; I assumed there needed to be a new operator to allow a redefinition in B.

In point of fact I had used a library a fellow programmer created for handling some text file generation that was a bit confusing because one of the methods had 8 different overloads and two of them differed only by datatype on the last argument. One was string and one was char. The likelihood that the value needed for the string version of the parameter was one character long was pretty good so hopefully you can see where this is headed. We had a devil of a time debugging problems because the consumer of the library inadvertently triggered the wrong call because of quoting differences, single versus double.

Moral of the story, be grateful that the candidate doesn't know the answer because it may indicate good coding habits.

Answer 6

This actually is a trick question.

The answer is ambiguous as to what "should" happen. Sure, the C# compiler takes it out of the realm of ambiguity to the concrete; however, since these methods are overloading one another, and are neither overriding nor shadowing, it is reasonable to assume that the "best argument fit" should apply here, and therefore conclude that it is A::Foo(int n) that should be called when provided an integer as an argument.

To prove that what "should" happen is unclear, the exact same code when run in VB.NET has the opposite result:

Public Class Form1
    Private Sub Button1_Click(ByVal sender As System.Object, _
                              ByVal e As System.EventArgs) _
                              Handles Button1.Click
        Dim b As New B
        b.Foo(5)   ' A::Foo
        b.Foo(5.0) ' B::Foo
    End Sub
End Class

Class A
    Sub Foo(ByVal n As Integer)
        MessageBox.Show("A::Foo")
    End Sub
End Class

Class B
    Inherits A

    Overloads Sub Foo(ByVal n As Double)
        MessageBox.Show("B::Foo")
    End Sub
End Class

I realize that I am opening up the opportunity for the C# programmers to "bash" VB.NET for not complying with C# . But I think one could make a very strong argument that it is VB.NET that is making the proper interpretation here.

Further, IntelliSense within the C# IDE suggests that there are two overloads for the class B (because there are, or at least should be!), but the B.Foo(int n) version actually can't be called (not without first explicitly casting to a class A). The result is that the C# IDE is not actually in synch with the C# compiler.

Another way of looking at this is that the C# compiler is taking an intended overloads and turning it into a shadowed method. (This doesn't seem to be the right choice to me, but this is obviously just an opinion.)

As an interview question, I think that it can be ok if you are interested in getting a discussion about the issues here. As for getting it "right" or "wrong", I think that the question verges on a trick question that could be easily missed, or even gotten right, for the wrong reasons. In fact, what the answer to the question "should be" is actually very debatable.