C# 潜在面试题……太难了？

C# Potential Interview Question…Too hard?

提问by FlySwat

Without running this code, identify which Foomethod will be called:

在不运行此代码的情况下，确定Foo将调用哪个方法：

class A
{
   public void Foo( int n )
   {
      Console.WriteLine( "A::Foo" );
   }
}

class B : A
{
   /* note that A::Foo and B::Foo are not related at all */
   public void Foo( double n )
   {
      Console.WriteLine( "B::Foo" );
   }
}

static void Main( string[] args )
{
   B b = new B();
   /* which Foo is chosen? */
   b.Foo( 5 );
}

Which method? And why? No cheating by running the code.

哪种方法？为什么？不通过运行代码作弊。

I found this puzzle on the web; I like it and I think I'm going to use it as an interview question...Opinions?

我在网上找到了这个谜题；我喜欢它，我想我会把它用作面试问题......意见？

EDIT: I wouldn't judge a candidate on getting this wrong, I'd use it as a way to open a fuller discussion about the C# and CLR itself, so I can get a good understanding of the candidates abilities.

编辑：我不会判断候选人是否犯了这个错误，我会用它作为对 C# 和 CLR 本身进行更全面讨论的一种方式，这样我就可以很好地了解候选人的能力。

Source:http://netpl.blogspot.com/2008/06/c-puzzle-no8-beginner.html

来源：http : //netpl.blogspot.com/2008/06/c-puzzle-no8-beginner.html

回答by Patrick Desjardins

Console.WriteLine( "B::Foo");

Console.WriteLine("B::Foo");

Because it will cast automatictly and use the first without going further in the inheritance.

因为它会自动转换并使用第一个而不会在继承中进一步。

I do not think it's a good interview question but it can be funny to try to solve without compiling the code.

我不认为这是一个很好的面试问题，但是在不编译代码的情况下尝试解决它可能很有趣。

回答by Jon Skeet

I really wouldn't use this as an interview question. I know the answer and the reasoning behind it, but something like this should come up so rarely that it shouldn't be a problem. Knowing the answer really doesn't show much about a candidate's ability to code.

我真的不会用这个作为面试问题。我知道答案和背后的原因，但是这样的事情应该很少出现，所以它不应该是一个问题。知道答案并不能说明候选人的编码能力。

Note that you'll get the same behaviour even if A.Foo is virtual and B overrides it.

请注意，即使 A.Foo 是虚拟的并且 B 覆盖它，您也会得到相同的行为。

If you like C# puzzles and oddities, I've got a few too (including this one).

如果您喜欢 C# 谜题和古怪，我也有一些（包括这个）。

回答by Joel Coehoorn

Another vote against using it, but for a different reason.

另一个反对使用它的投票，但出于不同的原因。

When put on the spot like this, a lot of really good programmers would come up with the wrong answer, but not because they don't know the concepts or couldn't figure it out. What happens is that they'll see something like this and think, "Aha, trick question!", and then proceed to out-think themselves in the response. This is especially true in an interview setting where they don't have the benefit of the IDE or Google or any other of the other helps a programmer takes for granted in their day to day programming.

像这样放在现场，很多真正优秀的程序员都会想出错误的答案，但这并不是因为他们不知道概念或无法弄清楚。发生的事情是，他们会看到这样的事情并想，“啊哈，诡计问题！”，然后继续在回应中超越自己。在面试环境中尤其如此，他们没有 IDE 或 Google 或任何其他帮助程序员在日常编程中理所当然的帮助。

回答by plinth

Too hard? No, but what is your goal in the question? What are you expecting to get from your interviewee? That they know this particular syntactic quirk? That either means that they've studied the spec/language well (good for them) or that they've run into this problem (hopefully not from what they wrote, but if they did - yikes). Neither case really indicates that you've got a solid programmer/engineer/architect on your hand. I believe that what's important is not the question but the discussion surrounding the question.

太难？不，但是您在问题中的目标是什么？您希望从受访者那里得到什么？他们知道这种特殊的语法怪癖吗？这要么意味着他们已经很好地研究了规范/语言（对他们有好处）或者他们遇到了这个问题（希望不是他们写的，但如果他们这样做了 - 哎呀）。这两种情况都不能真正表明您手头上有一个可靠的程序员/工程师/架构师。我认为重要的不是问题，而是围绕问题的讨论。

When I interview candidates, I usually ask one deceptively simple question which is based on a language semantic quirk - but I don't care if my interviewee knows it because that semantic quirk allows me to open up a lot of avenues that allow me to find out if my candidate is methodical, their communication style, if they're willing to say "I don't know", are they capable of thinking on their feet, do they understand language design and machine architecture, do they understand platform and portability issues - in short, I'm looking for a lot of ingredients that all add up to "do they get it?". This process takes an hour or more.

当我面试候选人时，我通常会问一个基于语言语义怪癖的看似简单的问题——但我不在乎我的面试者是否知道它，因为这种语义怪癖让我开辟了很多途径，让我找到我的候选人是否有条理，他们的沟通方式，他们是否愿意说“我不知道”，他们是否能够独立思考，他们是否了解语言设计和机器架构，他们是否了解平台和可移植性问题 - 简而言之，我正在寻找很多成分，这些成分加起来就是“他们明白了吗？”。这个过程需要一个小时或更长时间。

In the end, I don't actually care about whether they know the answer to my question - the question is a ruse to let me get all the rest of that information indirectly without ever having to ask. If you don't have a valuable ulterior in this question, don't bother even asking it - you're wasting your time and your candidate's time.

最后，我实际上并不关心他们是否知道我的问题的答案——这个问题是一种诡计，让我无需询问就可以间接获得所有其余信息。如果你在这个问题上没有一个有价值的别有用心的人，那就别问了——你在浪费你的时间和你的候选人的时间。

回答by Bill

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.

完全同意乔尔的看法。我有 20 多年的设计和编码经验，当我看到它时，我想到的第一件事是：它甚至不会编译。

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.

我做出这个假设是因为我试图避免仅存在单一数据类型不同的重载，并且在查看代码时甚至没有发现 int/double 差异；我认为需要一个新的运算符来允许在 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.

事实上，我使用了一个程序员同事创建的库来处理一些文本文件生成，这有点令人困惑，因为其中一个方法有 8 个不同的重载，其中两个仅在最后一个参数的数据类型上有所不同。一种是字符串，一种是字符。参数的字符串版本所需的值是一个字符长的可能性非常好，所以希望你能看到它的走向。我们在调试问题时遇到了麻烦，因为库的使用者由于引用差异（单对双）而无意中触发了错误的调用。

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

故事寓意，感谢候选人不知道答案，因为这可能表明良好的编码习惯。

回答by Mark Ransom

This smacks of a trick question to me. If you've been using the language for long enough, you've probably run into the problem and know the answer; but how long is long enough?

这对我来说是一个棘手的问题。如果您使用该语言的时间足够长，您可能已经遇到问题并知道答案；但多久才够长？

It's also a question where your background might work against you. I know in C++ the definition in B would hide the definition in A, but I have no idea if it works the same in C#. In real life, I'd know it was a questionable area and try to look it up. In an interview I might try to guess, having been put on the spot. And I'd probably get it wrong.

这也是你的背景可能对你不利的问题。我知道在 C++ 中，B 中的定义会隐藏 A 中的定义，但我不知道它在 C# 中是否相同。在现实生活中，我知道这是一个有问题的领域，并尝试查找它。在接受采访时，我可能会尝试猜测，因为我已经被当场了。我可能会弄错。

回答by gbjbaanb

use it as a question only as long as you expect the candidate to tell you his thought processes as he describes what he thinks should be happening. Who cares about the right and wrongness of actual code in question - in the real world, the candidate would find code like this, find it not working and debug it with a combination of debugger and writeline calls, so its a useless question if you want candidates who know (or guess) the right answer.

仅当您希望候选人在描述他认为应该发生的事情时告诉您他的思维过程时才将其用作问题。谁在乎实际代码的对错 - 在现实世界中，候选人会发现这样的代码，发现它不起作用并使用调试器和 writeline 调用的组合对其进行调试，因此如果您愿意，这是一个无用的问题知道（或猜测）正确答案的候选人。

But those who can explain what they think would happen, that's a different matter. Hire them even if they get it wrong.

但是那些能够解释他们认为会发生什么的人，那是另一回事。即使他们弄错了，也要雇用他们。

回答by Ryan Lundy

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.

如果我需要在现实生活中知道这一点，这正是我要做的：创建一个测试项目，输入它，然后找出答案。然后我不必担心抽象推理或 C# 规范中的细节。

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.

就在今天，我遇到了这样一个问题：如果我用同一行填充相同类型的DataTable两次，会发生什么？行的一份还是两份？即使我更改了它，它也会覆盖第一行吗？我想问问别人，但我意识到我可以很容易地启动一个我已经拥有的使用 DataSet 的测试项目，编写一个小方法并对其进行测试。

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'tif 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 knowwhat 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?

所以我认为这是一个可怕的问题。您是否更愿意雇用一个会尝试一下然后知道会发生什么的开发人员，而不是一个会尝试从他逐渐消失的记忆中挖掘出来的开发人员，或者会询问其他人并接受答案的开发人员可能是错的？

回答by Mike Rosenblum

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.

关于“应该”发生什么，答案是模棱两可的。当然，C# 编译器将它从模糊的领域带到了具体的领域；然而，由于这些方法相互重载，既不是覆盖也不是遮蔽，可以合理地假设“最佳参数拟合”应该适用于这里，因此得出结论应该是 A::Foo(int n)当提供一个整数作为参数时调用。

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

为了证明“应该”发生什么尚不清楚，在 VB.NET 中运行时完全相同的代码具有相反的结果：

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.

我意识到我正在为 C# 程序员“抨击”不遵守 C# 的 VB.NET 创造机会。但我认为人们可以提出一个非常有力的论点，即 VB.NET 在这里做出了正确的解释。

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.

此外，C# IDE 中的 IntelliSense 建议 B 类有两个重载（因为有，或者至少应该有！），但实际上无法调用 B.Foo(int n) 版本（不是没有第一个显式转换为 A 类）。结果是 C# IDE 实际上与 C# 编译器不同步。

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

另一种看待这个问题的方式是 C# 编译器正在执行预期的重载并将其转换为一个隐藏的方法。（这对我来说似乎不是正确的选择，但这显然只是一种意见。）

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.

作为一个面试问题，我认为如果您有兴趣在这里讨论这些问题，那就可以了。至于让它“正确”或“错误”，我认为这个问题接近于一个技巧问题，很容易因为错误的原因而被遗漏，甚至是正确的。事实上，“应该”这个问题的答案其实是很有争议的。

回答by Mark Brackett

That's a ridiculous question to ask - I could answer it in < 60 seconds with Snippet Compiler, and if I ever worked in a code base that depended on the functionality - it'd be quickly refactored out of existence.

这是一个荒谬的问题——我可以在 < 60 秒内用 Snippet Compiler 回答它，如果我曾经在依赖于功能的代码库中工作过——它会很快被重构而消失。

The best answer is "that's a stupid design, don't do that and you won't have to parse the language spec to know what it's going to do".

最好的答案是“这是一个愚蠢的设计，不要那样做，你不必解析语言规范就知道它要做什么”。

If I was the interviewee, I'd think very highly of your geek trivia cred, and would perhaps invite you to the next game of Geek Trivial Pursuit. But, I'm not so sure I'd want to work with/for you. If that's your goal, by all means ask away.

如果我是受访者，我会非常看好你的极客琐事信誉，也许会邀请你参加下一场极客琐事追寻。但是，我不太确定我是否愿意与您合作/为您工作。如果那是您的目标，请务必提出要求。

• Note that in an informal situation, geek trivia like this can be fun and entertaining. But, to an interviewee, an interview is anything but fun or informal - why further agitate it with trivial questions that the interviewee doesn't know if you take seriously or not?

• 请注意，在非正式情况下，像这样的极客琐事可能很有趣。但是，对于受访者来说，采访既不有趣也不非正式——为什么还要用一些琐碎的问题来进一步激怒它，而受访者不知道你是否认真对待？