С# Потенциальный вопрос для интервью... Слишком сложно?

Без запуска этого кода определите, какой метод 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 );
}

Какой метод? И почему? Не обманывайте, запустив код.

Я нашел эту головоломку в Интернете; Мне нравится, и я думаю, что буду использовать его в качестве интервью... Мнения?

EDIT: Я бы не стал судить кандидата по поводу этого неправильно, я бы использовал его как способ открыть более полную дискуссию о С# и CLR, поэтому я могу хорошо понять возможности кандидатов.

Источник: http://netpl.blogspot.com/2008/06/c-puzzle-no8-beginner.html

Ответ 1

Я бы не стал использовать это как вопрос для интервью. Я знаю ответ и рассуждения позади него, но что-то вроде этого должно появляться так редко, что это не должно быть проблемой. Знание ответа на самом деле мало говорит о способности кандидата к кодированию.

Обратите внимание, что вы получите такое же поведение, даже если A.Foo является виртуальным, а B отменяет его.

Если вам нравятся головоломки и причуды С#, У меня тоже есть (включая этот).

Ответ 2

Слишком сложно? Нет, но какова ваша цель в вопросе? Что вы ожидаете получить от своего собеседника? Что они знают эту особую синтаксическую причуду? Это означает, что они хорошо изучили спецификацию/язык (хорошо для них) или что они столкнулись с этой проблемой (надеюсь, что не из того, что они написали, но если они это сделали - yikes). Ни один из случаев на самом деле не указывает, что у вас есть солидный программист/инженер/архитектор. Я считаю, что важно не вопрос, а обсуждение вопроса.

Когда я беру интервью у кандидатов, я обычно задаю один обманчиво простой вопрос, основанный на языковой семантической причуде, - но мне все равно, знает ли мой собеседник, потому что эта семантическая причуда позволяет мне открыть много возможностей, которые позволяют мне узнать, является ли мой кандидат методичным, стиль общения, если они хотят сказать "я не знаю", способны ли они думать на ногах, понимают ли они язык и архитектуру машин, понимают ли они платформу и проблемы с переносимостью - короче говоря, я ищу много ингредиентов, которые все добавляют к "они их получают?". Этот процесс занимает час или больше.

В конце концов, я действительно не забочусь о том, знают ли они ответ на мой вопрос - вопрос - это уловка, позволяющая мне получить всю остальную часть этой информации косвенно, даже не спрашивая. Если у вас нет ценного скрытия в этом вопросе, не беспокойтесь даже об этом - вы теряете время и время вашего кандидата.

Ответ 3

Не могу согласиться с Джоэлем. У меня 20+ лет опыта проектирования и кодирования, и первое, что я думал о том, когда я увидел это было: он даже не будет компилироваться.

Я сделал это предположение, потому что я стараюсь избегать перегрузок, которые отличаются только одним типом данных, и, глядя на код, даже не набирал двойную разницу; Я предположил, что для нового переопределения в B должен быть новый оператор.

Фактически я использовал библиотеку программиста-программиста, созданного для обработки некоторого генерации текстовых файлов, который был немного запутанным, потому что один из методов имел 8 разных перегрузок, а два из них отличались только по типу данных последнего аргумента. Один из них был строкой, а один - char. Вероятность того, что значение, необходимое для строковой версии параметра, было одним символом, было довольно хорошим, поэтому, надеюсь, вы можете видеть, куда это направляется. У нас был дьявол проблем с отладкой времени, потому что потребитель библиотеки непреднамеренно вызвал неправильный вызов из-за цитирования различий, один против двух.

Мораль истории, будьте благодарны, что кандидат не знает ответа, потому что это может указывать на хорошие привычки кодирования.

Ответ 4

Еще один голос против использования этого, но по другой причине.

Когда на месте, как это, многие действительно хорошие программисты придумали неправильный ответ, но не потому, что они не знают понятий или не могут понять это. Что происходит, так это то, что они увидят что-то подобное и подумают: "Ага, трюк вопрос!", А затем приступить к выходу из себя в ответ. Это особенно справедливо в настройке интервью, где они не имеют преимущества IDE или Google или любого другого другого, что помогает программисту принимать само собой разумеющееся в повседневном программировании.

Ответ 5

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

Потому что он будет автоматически запускаться и использовать первый, не идя дальше в наследовании.

Я не думаю, что это хороший вопрос для интервью, но может быть смешно попытаться решить без компиляции кода.

Ответ 6

Это действительно трюк.

Ответ неоднозначен относительно того, что должно произойти. Конечно, компилятор С# выводит его из области двусмысленности в конкретный; однако, поскольку эти методы перегружают друг друга и не являются ни переопределяющими, ни затенением, разумно предположить, что здесь должен применяться "лучший аргумент", и поэтому заключаем, что это A:: Foo (int n), который должен быть вызывается, когда в качестве аргумента предоставляется целое число.

Чтобы доказать, что "должно произойти" неясно, тот же самый код при запуске в 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

Я понимаю, что я открываю возможность для программистов С# "bash" VB.NET для несоблюдения С#. Но я думаю, что можно было бы очень аргументировать, что именно VB.NET делает правильную интерпретацию здесь.

Кроме того, IntelliSense внутри С# IDE предполагает наличие двух перегрузок для класса B (поскольку они есть или, по крайней мере, должны быть!), но фактически не может быть вызвана версия B.Foo(int n) не без первого явного приведения в класс А). В результате С# IDE не синхронизируется с компилятором С#.

Другим способом взглянуть на это является то, что компилятор С# принимает заданные перегрузки и превращает его в теневой метод. (Это, кажется, не правильный выбор для меня, но это, очевидно, просто мнение.)

Как вопрос интервью, я думаю, что это может быть хорошо, если вы заинтересованы в обсуждении проблем здесь. Что касается того, чтобы получить это "правильно" или "неправильно", я думаю, что вопрос граничит с трюком, который можно легко упустить или даже получить правильно, по неправильным причинам. Фактически, ответ на вопрос "должен быть" на самом деле очень спорный.

Ответ 7

Не очень справедливо, как вопрос интервью, так как это немного сложный вопрос. Хороший ответ, который я хотел бы получить у собеседника, будет более похож на "Требуется рефакторинг".

Если вы не хотите нанимать кого-то для работы с компиляторами, я не уверен, что вам нужно углубиться в CLR.

Для вопросов интервью я ищу вещи, которые показывают уровень понимания кодера в их ответе. Это скорее странность/головоломка.

Ответ 8

Я думаю, это ужасный вопрос. Я думаю, что любой вопрос - это страшный вопрос, когда реальный ответ: "Запустите его и посмотрите!"

Если бы мне нужно было знать это в реальной жизни, это именно то, что я сделал бы: Создайте тестовый проект, включите его и узнайте. Тогда мне не нужно беспокоиться об абстрактных рассуждениях или точках в спецификации С#.

Только сегодня я столкнулся с таким вопросом: если я заполню тот же типизированный DataTable дважды той же строкой, что произойдет? Один экземпляр строки или два? И перепишет ли он первую строку, даже если я ее изменил? Я подумал о том, чтобы спросить кого-то, но я понял, что могу легко запустить тестовый проект, который у меня уже был с использованием DataSets, написать небольшой метод и проверить его.

Ответ:

... ах, но если я скажу вам, вы пропустите момент.:) Дело в том, что в программировании вам не нужно оставлять эти вещи гипотетическими, и вы не должны, если их можно разумно протестировать.

Итак, я думаю, это ужасный вопрос. Разве вы не предпочли бы нанять разработчика, который попробует его, а затем узнает, что произойдет, а не разработчика, который попытается вытащить его из своей исчезающей памяти или кто попросит кого-нибудь еще и примет ответ, может быть неправильным?

Ответ 9

Это смешной вопрос - я мог бы ответить на него, 60 секунд с помощью компилятора Snippet, и если я когда-либо работал в базе кода, которая зависела от функциональности, она бы быстро реорганизовалась из существования.

Лучшим ответом является "то, что глупый дизайн, не делайте этого, и вам не придется анализировать спецификацию языка, чтобы знать, что он собирается делать".

Если бы я был собеседником, я бы очень сильно подумал о твоих мелочах и, возможно, пригласил бы тебя в следующую игру Geek Trivial Pursuit. Но я не уверен, что хочу работать с вами/для вас. Если ваша цель, непременно просите прочь.

Обратите внимание, что в неформальной ситуации подобные мелочи, подобные этому, могут быть интересными и интересными. Но, интервьюируемому, интервью - это не что иное, как забавное или неформальное, - зачем дальше волновать его тривиальными вопросами, которые собеседник не знает, серьезно ли вы относитесь или нет?

Ответ 10

Мне это нравится. Если вы используете язык достаточно долго, вы, вероятно, столкнулись с проблемой и знаете ответ; но как долго это достаточно долго?

Это также вопрос, где ваш фон может работать против вас. Я знаю, что в С++ определение в B скроет определение в A, но я понятия не имею, работает ли оно на С#. В реальной жизни я бы знал, что это сомнительная область и попытаться ее найти. В интервью я мог бы попытаться угадать, будучи на месте. И я, вероятно, ошибаюсь.

Ответ 11

используйте его как вопрос только до тех пор, пока вы ожидаете, что кандидат скажет вам свои мыслительные процессы, поскольку он описывает то, что, по его мнению, должно происходить. Кто заботится о правильности и неправильности фактического кода, о котором идет речь - в реальном мире кандидат найдет такой код, найдет его неработоспособным и отлаживает его с помощью комбинации отладчиков и писем, поэтому его бесполезный вопрос, если вы хотите кандидаты, которые знают (или предполагают) правильный ответ.

Но те, кто может объяснить, что они думают, будут иметь другое дело. Нанимайте их, даже если они ошибаются.

Ответ 12

В реальной рабочей ситуации требуется 5 секунд, чтобы выяснить, что пошло не так. Компиляция, тестирование, oops.

Я гораздо больше обеспокоен, если кто-то может создать хороший и удобный код. Задавайте такие вопросы, как

Как бы вы это разработали, написать простой абстрактный дизайн, без кода.
Здесь дизайн объекта. Пришел клиент и сказал, что они этого хотят. Сформулируйте новый дизайн или обсудите причины, по которым требования не отвечают фактическим потребностям клиентов.

Ответ 13

Попробуйте приведенный ниже пример:

class Program
{
    class P
    {}
    class Q : P
    {}

    class A 
    { 
        public void Fee(Q q)
        {
            Console.WriteLine("A::Fee");
        }
    }

    class B : A 
    {   
        public void Fee(P p)
        {
            Console.WriteLine("B::Fee");
        }
    }

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

        b.Fee(new Q());
        Console.ReadKey();
    }
}

Компилятор предпочитает привязывать вызов "b.Fee()" к доступному методу типа, а не унаследованному методу (методу базового типа), если этот параметр может быть неявно передан для соответствия любому такому методу. То есть неявное литье параметра имеет приоритет по сравнению с привязкой метода базового класса.

Хотя, честно говоря, я считаю наоборот более интуитивным, потому что для меня унаследованный метод так же хорош, как непосредственно введенный метод.

Ответ 14

Приведенный код будет печатать B::Foo.

Ответ 15

Как уже было сказано, когда я беру интервью у кого-то, я хочу узнать, способен ли кандидат на общение, способный писать код, который имеет смысл, и может быть легко понят другим, код, который можно сохранить и т.д., Я лично не люблю проводить время в упражнениях, подобных предложенным. Вместо этого я предпочел бы провести упражнение, когда кандидат будет писать код сам - даже в обычном текстовом редакторе - и оттуда открывается дискуссия, основанная на обзоре кода, улучшения, как и так далее. Не нужно компилировать код: компилятор выполнит свою работу, в конце концов. Я знаю, что многие люди могут не согласиться с этим подходом, но до сих пор я нашел это лучшим способом найти хороших кандидатов.