Я провалил FizzBuzz, вы бы меня наняли? [закрыто]

Я разработчик со степенью CS и имею опыт работы на нескольких языках почти 3 года.

Сегодня у меня было интервью, в целом оно прошло довольно хорошо, я подготовился к большинству вопросов и чувствовал себя готовым ко всему. В конце интервью они задали мне ОДИН программный вопрос ... такую ​​проблему, как FizzBuzz (без печати номера части). Я считаю, что допустил слишком много ошибок и поэтому «провалил» это. Вся надежда потеряна для меня?

Вот мой код:

  void FizzBuzz()
  {
    for(int i = 0; i <= 100; i++)
    {
      bool isThree = i % 3;
      bool isFive = i % 5;

     if (isThree)
     {
         print "Fizz\n";
     }
     else if(isFive)
     {
         print "Buzz\n";
     }
     else
     {
         print "FizzBuzz\n";
     }
  }
 }

Как вы можете видеть, я испортил bool, который должен иметь синтаксис i% 3 == 0; Если я правильно помню вопрос, я также добавляю else вместо elseif с помощью isThree && isFive. Я был очень взволнован, но это не оправдание для пропущенной простой проблемы.

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

Смысл FizzBuzz в том, чтобы показать, что вы действительно знаете, как программировать , а не то, что вы запомнили все более тонкие синтаксические правила языка, на котором вас просили программировать (хотя это имеет значение, если они хотят знать, насколько опытный ты на языке).

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

да

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

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

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

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

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

[Править] Как указал Алекс, есть также реакция и хладнокровие. Лично я пытаюсь избавиться от этого, прежде чем приступать к практическим упражнениям, пытаясь загнать собеседника в замешательство на что-то, немного выходящее за рамки его опыта, но некоторые могут решить объединить их. Время от времени я сталкиваюсь с кем-то, у кого есть только знания в учебниках, и они разбираются в теоретических и базовых вопросах, но серьезно зацикливаются на том, с чего начать практическое упражнение. Некоторые даже не могут понять, с чего начать.

Эти люди именно то, что я хочу отсеять с помощью этого упражнения.

Таким образом, если вы не потратили 20 минут на разъяснение интервьюеру требования, я полагаю, что ваше решение было более или менее первой вашей попыткой, возможно, с несколькими исправлениями по ходу дела. Если вы получили то, что поставили выше, менее чем за 5 минут, вы показали, что можете думать достаточно для моих стандартов.

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

Меня сбивает с толку то, что интервьюер не спрашивал вас об этом коде. Хороший интервьюер видел достаточно своего собственного кода, чтобы знать, что люди делают ошибки - особенно когда спешат. Обычно они говорят: «Теперь вы видите что-то не так с этим кодом?» «Нет? Хорошо, давайте проверим это». Вы получаете несколько наборов результатов и затем запускаете их через функцию. Тогда вы говорите: «О, дерьмо, это не сработало». «Хорошо, как бы вы это исправить ...» и так далее. Если вы выживете в этом диалоге, он действительно впечатляет и демонстрирует способность критически мыслить, придумывать тестовые примеры и отлаживать собственный код.

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

Кроме того, это может вас удивить, но вы конкурируете со многими людьми, которые даже не могут начать fizzbuzz. Мы склонны полагать, что все остальные обходят деревья b + во сне ... но в действительности они даже не могут вычислить кратные 3 и 5 и использовать оператор модуля. Вы можете быть удивлены тем, насколько лучше вы сделали, чем другие кандидаты.

Мой совет, просто отмахнись. Недавно я брал интервью у крупных компаний-разработчиков программного обеспечения (Microsoft, Amazon и т. Д.), И я впервые прошел такой тщательный процесс собеседования. Я одурачил себя на собеседовании с Microsoft на месте во многом из-за нервов, но я просто не знал, чего ожидать или что именно они искали. Я прибил проблему кратчайшего пути только для того, чтобы взорвать некоторые действительно простые проблемы. Я вытолкнул значения из неправильного конца стека, забыл в int atoi(char* value)реализации, чтоint val = value[i] - '0';дал бы мне целочисленное значение символа и несколько других глупых ошибок. Я был счастлив по большей части интервью, но все еще понимал, почему я не получил предложение. Я должен был понять, что это было не столько отражением моих способностей, сколько индикатором того, что мне просто нужно было продолжать пробовать это, пока я не смогу справиться со своими нервами. В конце концов я собрал несколько интервью с более сложными вопросами и получил работу своей мечты. Это действительно - для большинства людей, которые действительно знают, что они делают, - просто выяснить, что хотят интервьюеры, быть уверенным в себе и дать им это. Это займет некоторое время.

Я бы сказал «нет», но не по той причине, которую вы указали, а по тому, что вы поместили раздел FizzBuzz последним. При том, как работает ваш код, он никогда не будет печатать FizzBuzz, когда вы этого ожидаете. Как прокомментировал Ли, он напечатает его для каждого значения, не делимого на 3 или 5.

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

Нет. Цель FizzBuzz - посмотреть, сможете ли вы выработать базовую условную логику, которая охватывает все случаи. Вопреки мнению некоторых людей, FizzBuzz не об операторе модуля, зная троичные операции или логические операнды. Это простое упражнение в условных выражениях, и вы провалили его.

Проблема структурирована таким образом, что весь «элегантный» код не может охватить хотя бы один случай.

Приемлемые ответы:

if div3 print fizz
if div5 print buzz
if !div3 && !div5 print x


if div3 {
    print fizz;
    if div5 {
        print buzz;
    }
} else {
    if div5 {
        print buzz;
    } else {
        print x;
    }
}

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

Я более подробно остановлюсь на «тестировании» доски во время интервью: законный способ резервного копирования кода (доски)?

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

Если бы я оценивал это, я бы искал следующие вещи:

1. Пытается ли кандидат получить четкое представление о требованиях, прежде чем перейти к реализации? Кандидат пытается решить мою проблему или использовать свои любимые инструменты в своем наборе инструментов программирования? Как кандидат решает проблемы?
2. Владеет ли кандидат хотя бы одним языком программирования?
3. Имеет ли кандидат понимание логической логики?
4. Что делает кандидат, чтобы обеспечить качество своих решений?
5. Как кандидат отвечает на отзывы о своем коде?

-

Сложно сказать о # 1. В вашем вопросе говорится, что ваша проблема не включала часть «номер печати», а ваше решение фактически не включает это. У меня нет другого выбора, кроме как поверить на слово, но если на самом деле это была классическая проблема FizzBuzz, которая включала печать чисел, которые не делятся ни на одну из них, то звучит так, будто вы перешли к решению, прежде чем полностью поняли требования, которые будет отметкой.

Я бы отдал вам частичную оценку за № 2 и № 3. Вы знали, что нужно использовать оператор модуля, и у вас была структура рабочего решения, но вы пропустили обе части.

Похоже, вы не делали # 4, что отметит вас. В будущем я бы порекомендовал сделать шаг назад от доски и просмотреть свое решение, прежде чем называть его выполненным. Я бы также (без подсказки) прошёл пару юнит-тестов для вашего решения, которые бы быстро продемонстрировали, где вы ошиблись.

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

-

Так что, если бы я оценивал это в одиночку, я бы проголосовал «Нет найма». Подобные вещи являются своего рода измерением искусства производительности, а не умением программировать , но овладение им может все же помочь вашей карьере. Итак, мои рекомендации для будущих технических интервью:

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

2. Задайте вопросы о проблеме, чтобы подтвердить свои предположения.

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

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

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

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

Если бы они предоставили вам среду модульного тестирования или выполнения, сделанные вами ошибки были бы менее простительными.