Вопрос № 11 теста Джоэл : «Пишут ли новые кандидаты код во время собеседования?». Какие аргументы за и против, чтобы попросить новых кандидатов написать код во время собеседования и принять решение по нему?
Ответы:
Я не вижу минусов. Интервью состоит из множества частей, и кандидат должен быть несколько раз одобрен «по цепочке».
Я беру интервью около 10 человек в неделю. Я действительно, действительно, очень ценю тот факт, что HR проделал всю фоновую работу и подарил мне множество заметок. К тому времени, когда они доберутся до меня, пришло время забивать их тесты.
Тесты полностью зависят от позиции. Вообще, я пытаюсь исследовать:
Общий навык программирования. Вы можете эффективно использовать операторов? Можете ли вы представить числовую систему, у которой ось не равна 10?
Вы знаете, как делать то, что мы вас нанимаем?
Оценка вашего вклада в любые проекты с открытым исходным кодом, которые вы перечислили
Я стараюсь быть коротким и веселым. Когда я захожу в офис, я беру ответы, просматриваю их, а затем провожу дополнительное собеседование. Чтобы получить работу, вам обычно нужно пройти три собеседования.
Я также оцениваю, насколько хорошо вы будете сочетаться с командой, которая будет вас принимать. Эта команда рассчитывает, что я сделаю это эффективно.
Одно дело отвечать на вопросы в мета-форме, другое - фактически создавать код. Если я собираюсь нанять вас, мне действительно нужно, чтобы вы создали код.
С извинениями Скотту Уитлоку:
Минусы:
Плюсы:
Если бы вы собирались нанять жонглера, вы бы с ума сошли, если бы он не жонглировал для вас. Или музыкант, у тебя будет прослушивание. В противном случае вы получите такие вещи, как удивительный йо-йо "мастер" К-страсс .
Прогулка по чему-то на доске - это программист, эквивалентный быстрому демонстрационному жонглированию.
Я думаю, что это супер полезно, и я всегда делаю это, но так как преимущества были покрыты так хорошо, я собираюсь обсудить только (очевидные) недостатки.
Я думаю, что тесты кода вряд ли дадут вам ложные срабатывания: маловероятно, что кто-то, кто на самом деле не сможет написать код, сможет подделать его во время интервью, по крайней мере, если у вас возникнут вопросы возрастающей сложности. (Возможно, наиболее вероятный сценарий - они обманывают, спрашивая друга, если это не личное собеседование.)
Проблема скорее в ложно-отрицательной стороне: приведут ли тесты кода к отклонению человека, который на самом деле лучший кандидат?
Боязнь сцены
У вас может быть кто-то, кто на самом деле действительно хороший разработчик, но который очень нервничает по поводу этого интервью, и они, по сути, боятся сцены. Выступление под давлением важно в некоторой степени, но борьба со сценой не является ключевой частью работы программиста (по сравнению с другими профессиями), и было бы прискорбно отвергать кого-то, кто сильно страдает от этого. Это может усугубить ситуацию: если человек не может ответить на вопрос, который, как он знает, ему следует ответить, он может стать более напряженным. Или, как в этом вопросе , они чувствуют, что не могут говорить и кодировать одновременно.
Смягчение: Начните с ознакомительных вопросов об их прошлом, целях и т. д., прежде чем переходить к техническим вопросам. Возможно, начните с более простых технических вопросов, чтобы они набирали обороты. Не будь членом во время собеседования (спор о точках с запятой и т. Д.).
Это шумная мера
Интересные вопросы кода могут иметь более одного правильного ответа. Если один человек пишет правильный ответ, а другой пишет правильный и более эффективный ответ, какой вес вы должны придать этому?
В некоторой степени это похоже на проблему с некоторыми «загадочными» вопросами: у человека либо есть понимание, либо нет, и вы получаете почти двоичный результат. Интеллект, вероятно, влияет на вероятность такого понимания, но выборка только несколько раз дает грубую оценку.
Это беспокоит меня о вопросах кода (хотя я все еще использую их). Лучшее, что я могу придумать, - это максимально возможное количество возможных решений: человек может, по крайней мере, написать грубый грубый ответ или ответ для часть проблемы. Понимать, что это лучше, чем ничего, - хороший знак. Тогда, если они обнаружат больше, они могут сделать его более эффективным или более элегантным кодом. Насколько это возможно, избегайте задавать вопросы, которые получают бинарные ответы.
Это не очень представительный
Программирование не является задачей решения десятиминутных алгоритмических задач одна за другой: гораздо больше работы по пониманию и проектированию больших систем и концентрации внимания в течение длительных периодов времени, не говоря уже о навыках межличностного общения. Вопросы кода не проверяют это на самом деле.
Но вопросы кода - это не единственные вопросы, которые вы собираетесь задать: вы можете посмотреть на их историю, их ссылки, их работу с открытым исходным кодом (если есть), чтобы найти доказательства постоянных усилий, творчества, навыков межличностного общения.
Знание того, как решать небольшие алгоритмические задачи и как сводить их к коду, является необходимым, но не достаточным условием: если вы не можете решить небольшие проблемы и не можете написать нетривиальный код, тогда все мировоззренческое мышление в мире не является собирается сделать вас продуктивным разработчиком.
Кто-нибудь может решить это
Нет, очевидно нет. Как отмечается в известном посте FizzBuzz , проблемы, которые вы можете подумать, являются тривиальной ловушкой не только для новых выпускников, но и для людей с многолетним опытом работы в отрасли. Я не знаю почему. Либо тест кода является плохой мерой (что возможно, хотя я думаю, что это маловероятно), либо они не вносили значительного вклада в проекты в своем резюме, либо они много делали, копируя и вставляя не алгоритмический код (что возможно.)
Стоит признать, что вы действительно можете многое сделать без написания алгоритмического кода. Люди зарабатывают большие деньги на приложениях, ценность которых заключается в графике или бизнес-логике, а не в том, что вы можете назвать «программированием», и это нормально. Но если вам действительно нужны программисты, это не очень подходит.
Это не может быть хорошо откалиброван
Если вы зададите вопрос, ответ может показаться вам простым. Однако, если вам задают какой-либо другой сопоставимый вопрос на ровном месте или вопрос, который не искажен в соответствии с вашими конкретными интересами и опытом, он может оказаться гораздо сложнее.
смягчение: Запустите тесты над некоторыми разработчиками, которых вы уже знаете, и посмотрите, как они это делают. Возможно, кто-то из вашей команды, который, как вы знаете, очень умен, будет иметь проблемы с одним из них, и вы можете подумать о его настройке. Возможно, они подумают о лучшем или другом ответе.
Это слишком похоже на пустяки
Я думаю, что вопросы о коде наверняка могут дойти до мелочей, если вы настаиваете, чтобы люди знали наизусть API-интерфейсы наизусть, или совершенствовали синтаксис, или помнили точное определение нетривиального алгоритма. Все они разумны, чтобы полагаться на документы, веб-поиски или ошибки компилятора, и имеют небольшую корреляцию с реальным опытом. Даже не зная, где, вероятно, будет API, можно понять, что человек недавно не использовал его, но это не обязательно проблема, если он не лежит в своем резюме.
Поэтому ответ на этот вопрос довольно прост: не задавайте тривиальных вопросов и не зацикливайтесь на тривиальных ошибках. Напомните кандидату, как называется API, или дайте ему посмотреть его; исправить синтаксические ошибки; не проверяйте людей, запоминающих определения структуры данных.
Как вы сравниваете?
Если у вас есть два кандидата, и оба хорошо отвечают на вопросы, как вы выбираете между ними? Вы можете выбрать того, кто закончил быстрее всех, но, возможно, там вы начнете собирать зайцев над черепахами. Вы могли бы сделать еще один раунд и задать гораздо более сложные вопросы, но я в этом тоже не уверен. Возможно, вы просто дадите им оба плюса и попытаетесь выбрать между ними по другим критериям (или попытаетесь найти деньги, чтобы нанять обоих).
Один из доводов, о которых я могу подумать, заключается в том, что трудно "кодировать вслух" перед другими людьми. Мне трудно даже печатать, когда кто-то смотрит через мое плечо, и я не одинок. Я замечаю, что когда кто-то зовет меня на свою рабочую станцию, чтобы помочь с чем-то, они внезапно начинают делать опечатки, выбирают неправильное завершение кода, даже делают прямые ошибки - ничего такого, что они бы сделали, если бы я не сидел прямо там. Черт, я видел, как люди начали использовать меню для операций вырезания и вставки только потому, что они находились под наблюдением. Это не нормальное поведение, и программисты, о которых я говорю, отличные программисты и к тому же довольно умные.
Недавно у меня было интервью, в котором интервьюер спросил меня, как я буду кодировать конкретную операцию, и он сказал: «Просто покажи мне математику». Ну, я должен был сначала подумать о проблеме, прежде чем приступить к ее математике, так что это заставило меня подшить и раскритиковать. То, что я сначала положил на доску, было смущающим, и я чувствовал, что проигрываю в тот момент. В конце концов я получил момент А-ха и нашел ответ (на самом деле, когда мне наконец пришло в голову то, о чем он на самом деле спрашивал), но «беспорядок», который я устроил до того, как туда попал, заставил меня чувствовать себя очень неловко. Тем не менее, я получил работу, но если бы интервьюер был менее терпеливым, я бы этого не сделал.
Я думаю, что если вы дадите собеседнику задание на кодирование, дайте им время побыть одному на компьютере, возможно, даже в IDE, с которой он знаком. Позвольте им написать код для вас, а затем поговорить об этом. Спросите их, почему они так поступили, и не может ли быть лучше другой путь. Вы узнаете больше из такого рода процессов, чем попросите их (образно говоря) пописать в чашку прямо перед вами.
Минусы: нет. Каждый раз, когда вы тратите настройку ПК, разработку теста кода и его проверку, вы избавите себя от невыразимой головной боли в будущем.
Плюсы: «Доверяй, но проверяй», - Рональд Рейган. Так много раз я видел и слышал о людях, которые, в конце концов, отпускали с позиции, где в интервью вы подумали, что получили рок-звезду. Доказательство в пудинге; Я хочу посмотреть, что они могут сделать. Он будет представлять, что произойдет, если вы потратите время и деньги, нанимая кого-то и ставя перед ним новый проект.
Минусы:
Плюсы:
Когда я брал интервью для моей текущей работы, мне дали список вопросов, чтобы написать код рекрутером. Я был очень впечатлен, потому что вопросы, очевидно, были написаны кем-то, кто имел глубокие знания SQL, поэтому он работает в обоих направлениях.
Вы действительно хотите, чтобы человек записал код на собеседовании - еще лучше, попросите его объединить программу с участником вашей команды на Х времени (все, что вы можете себе позволить с удобством времени / рабочей силы).
Это в значительной степени единственный способ узнать, может ли этот человек писать код или нет.
Я немного предпочитаю парное программирование, так как оно покажет их командную работу, даст им реальную среду IDE для работы и позволит им работать над «реальной» проблемой (другой человек в паре может помочь им преодолеть любые экологические особенности, которые опрашивает собеседник). никогда не мог разумно знать о).
Мы начали использовать эту политику найма и очень довольны результатами.
Вы судите птицу по перьям, а программиста - по ее коду.
Когда я начинал с текущей компанией, в которой я работаю, они попросили меня написать некоторый код C, который генерирует или проверяет бит четности некоторого двоичного ввода (в зависимости от того, кодируете ли вы или декодируете). Это был вопрос собеседования именно потому, что такого рода проблемы решаются во время работы. Конечно, я думаю не о проверке четности, а о работе на низком уровне.
Все ответы на данный момент (которые я прочитал) не касались того факта, что тест Джоэля НЕ является (просто) списком лучших практик для предпринимателей, а является контрольным списком для облегчения вашей оценки потенциального работодателя .
Дело в том ... если они тщательно проверяют свои кандидаты, то они, вероятно, нанимают людей, которые знают свое дело ... это значит для вас
вместо исправления ошибок после них ...
Я бы сказал:
Pros
Cons
Reverseметод или аналогичный, или для письменных тестов такие вещи, как« Каковы аргументы Fooметода Barкласса », когда любой идиот может Google это или использовать документацию), в отличие от вопросов архитектуры / дизайна, которые показывают кандидат может добиться цели и решить проблемы бизнеса .Один из них заключается в том, что он показывает, что у кого-то есть базовые знания в области программирования или чего-то еще (когда я в последний раз сталкивался с этим, я был удивлен, насколько базовым был вопрос SQL). Это также может служить основой для технической дискуссии, спрашивая, почему кандидат сделал то-то и то-то, и как это можно улучшить.
На собеседовании требуется время, которое можно использовать для других целей. Более того, написание кода на доске не является естественной средой, и у некоторых людей с этим будут возникать более и менее серьезные проблемы. Это может заставить вас пропустить разработчика, который просто нервничает без обычных инструментов или ссылок.
Программирование - это высокотехнологичный навык с кучей четких «результатов». Кандидат может или не может доставить их. Так что нет никаких «минусов» в том, чтобы задавать технические вопросы. Это полностью для того, чтобы сказать: «покажи мне код для этого приложения или« покажи код для приложения, которое ты уже написал ».
НЕ выполнение этого может привести к такому результату, как следующий: богатый человек взял интервью у репетитора, чтобы научить его детей играть в шахматы (как упражнение, расширяющее сознание). Учитель открыл клетчатую доску и начал говорить о 64 клетках, но не коснулся шахматной фигуры. В любом случае, отец был вынужден нанять репетитора. А репетитор научил детей играть в CHECKERS.