Каковы плюсы и минусы для работодателя кодовых вопросов во время собеседования? [закрыто

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/21230

  •  22-10-2019
  •  | 
  •  

Вопрос

Тест Джоэла Вопрос № 11: «Новые кандидаты пишут код во время своего интервью?». Что касаются аргументов для и против, чтобы попросить новых кандидатов написать код во время собеседования и принять решение по нему?

Это было полезно?

Решение

Я не вижу минусов. Интервью имеет много частей, и кандидат должен быть одобрен «цепью» несколько раз.

Я интервью ~ 10 человек еженедельно. Я действительно, очень, очень ценю тот факт, что HR проделал всю фоновую работу и подарил мне множество заметок. К тому времени, когда они добрались до меня, мне пора забить их тесты.

Испытания полностью зависят от позиции. Как правило, я пытаюсь исследовать:

  • Общий навык программирования. Можете ли вы эффективно использовать операторов? Можете ли вы зачать численную систему с Radix, которая не составляет 10?

  • Вы знаете, как сделать то, что мы нанимаем вас, чтобы сделать?

  • Оценка ваших вкладов в любые проекты с открытым исходным кодом, которые вы перечислили

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

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

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

Другие советы

С извинениями перед Скоттом Уитлоком:

Минусы:

  • никто

Плюсы:

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

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

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

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

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

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

Боязнь сцены

У вас может быть кто -то, кто на самом деле действительно хороший разработчик, но он очень нервничает в этом интервью, и они по сути получают страх. Выступление под давлением в некоторой степени важно, но борьба с этапами не является такой ключевой частью того, чтобы быть программистом (по сравнению с другими профессиями), и было бы неудачно отвергнуть кого -то, кто сильно страдает от этого. Это может усугубить: если человек не может ответить на вопрос, который, как они знают, он должен ответить, он может стать более плотно. Или же, как в этом вопросе, Они чувствуют, что не могут говорить и кодировать одновременно.

Смягчение: начните с некоторых вопросов, чтобы узнать, что вы об их опыте, целях и т. Д., Прежде чем перейти к техническим вопросам. Возможно, начните с некоторых более простых технических вопросов, чтобы они получили какой -то импульс. Не будьте членом во время интервью (бросаясь в срок о полуколонах и т. Д.).

Это шумная мера

Интересные вопросы кода могут иметь более одного правильного ответа. Если один человек пишет правильный ответ, а другой пишет правильный и более эффективный ответ, сколько веса вы должны нанести на это?

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

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

Это не на самом деле представитель

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

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

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

Любой может решить, что

Нет, очевидно нет. В качестве Знаменитый пост Fizzbuzz Указывает, что проблемы, которые, по вашему мнению, являются тривиальными ловушками не только новых выпускников, но и людей с многолетним опытом работы в отрасли. Я не знаю почему. Либо тест кода-плохая мера (что возможно, хотя я думаю, что это маловероятно), либо они не внесли большой вклад в проекты на их резюме, либо они много делали, копируя и не внесли свой вклад. Алгоритмический код (который возможно.)

Стоит признать, что вы действительно можете многое сделать, не написав какой -либо алгоритмический код. Люди зарабатывают много денег на приложениях, ценность которых находится в графике или бизнес -логике, не в том, что вы могли бы назвать «программированием», и это нормально. Но, если вам действительно нужны программисты, это не подходит.

Это может быть плохо откалибровано

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

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

Это слишком похоже на мелочи

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

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

Как сравнить?

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

Один из них, о котором я могу придумать, это то, что перед другими людьми трудно «кодировать вслух». Мне трудно даже печатать с кем -то, кто смотрит через мое плечо, и я не одинок. Я замечаю, что когда кто-то звонит мне на свою рабочую станцию, чтобы помочь с чем-то, он внезапно начинает делать опечатки, выбирая неправильное завершение кода, даже совершая совершенно ошибки-ни один из которых они не сделали бы, если бы я не сидел прямо там. Черт, я видел, как люди начинают использовать меню для операций по вырезанию и пасты, только потому, что они находились под наблюдением. Это не нормальное поведение, и кодеры, о которых я говорю, являются отличными программистами и довольно умными, кроме того.

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

Я думаю, что если вы дадите интервьюируемым задачу для кодирования, дайте им некоторое время в одиночестве, чтобы разобраться на компьютере, возможно, даже в IDE, с которым они знакомы. Позвольте им написать код для вас, а затем поговорить об этом. Спросите их, почему они сделали вещи определенным образом, и может ли другой способ не лучше. Вы узнаете больше из такого рода процесса, чем прося их (образно говоря) мочиться в чашку прямо перед вами.

Минусы: нет. Каждый раз, когда вы тратите настройку компьютера, разработку тестирования кода и просмотр его сэкономит невыразительную головную боль в будущем.

Плюсы: «Доверься, но проверь» - Рональд Риган. Так много раз я видел и слышал о людях, наконец, отпустил с должности, где в интервью вы думаете, что получаете рок -звезду. Доказательство в пудинге; Я хочу посмотреть, что они могут сделать. Это будет представлять то, что происходит, когда вы инвестируете время и деньги на найм кого -то, и наклеите новый проект перед ними.

Минусы:

  • Требует, чтобы у вас был технический человек на собеседовании

Плюсы:

  • Экономит много времени и душевной боли в будущем, если вы не позволяете нанимать кого -то, кто не может программировать

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

Ты В самом деле Хотите, чтобы человек написал код на собеседовании - еще лучше, попросите его в программе сочетаться с участником вашей команды за X количество времени (все, что вы можете с комфортом позволить себе во времени/рабочей силе).

Это в значительной степени один из единственных способов сказать, может ли этот человек кодировать или нет.

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

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

Вы судите птицу по его перьям и программистам по его/ее кодексу.

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

Все ответы до сих пор (которые я читал) не рассматривал тот факт, что Тест Джоэла не (просто) список лучших практик для предпринимателей но контрольный список, чтобы облегчить ваш Оценка работодателя проспекта.

Дело в том, что ... если они тщательно проверяют свои кандидаты, то они, вероятно, нанимают людей, которые знают свои вещи ... это значит для тебя

  1. меньше головной боли а также
  2. повышенная вероятность обучение что-то от ваших коллег

Вместо того, чтобы фиксировать ошибку за ними ...

Я бы сказал:

Плюс

  • Демонстрирует, что кандидат обладает по крайней мере проходимым знанием программирования, поскольку резюме могут быть изготовлены/украшены
  • Если интервьюер обсуждает код с кандидатом, в отличие от того, что он больше похож на письменный тест, может быть хорошим показателем того, как вы «сетчат» в социальном плане, и если кандидат подходит для компании/компании и команды хорошо подходит для кандидата

Минусы

  • Может быть оскорблением для кандидатов, если вопросы - это раздача/тривиальная чушь, которая никогда не появится во время работы (например, «Напишите сортировку пузырьков», когда все современные рамки, которые можно использовать на работе "Когда есть встроенный Reverse метод или аналогичный, или на письменные тесты, такие как «Каковы аргументы для Foo Метод Bar Класс », когда любой идиот мог бы погуглить это или использовать документацию), а не архитектурные/дизайнерские вопросы, которые показывают, что кандидат может добиться цели а также Решить бизнес -проблемы.

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
scroll top