Задача по программированию отпугивает кандидатов, стоит ли от нее отказываться?

Я впервые занимаюсь HR, и мы ищем разработчика. Процесс отбора состоит из трех этапов: техническое собеседование по телефону, задача по программированию (от 0,5 до 1 часа) и, наконец, собеседование с высшим руководством и со мной.

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

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

Как я могу улучшить наш процесс найма?

ОБНОВЛЕНИЕ, ПОСКОЛЬКУ ЭТОТ ВОПРОС БЫЛ РАЗМЕЩЕН

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

а) Это показывает, что у них хорошее отношение к компании и роли , если они готовы пройти лишнюю милю , чтобы выполнить ее.

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

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

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

ВТОРОЕ ОБНОВЛЕНИЕ С РАЗМЕЩЕНИЯ ЭТОГО ВОПРОСА

Дипломированный разработчик оказался звездным сотрудником. Мы оставили его и повысили ему зарплату.

Если у кого-то нет средств для выполнения задачи для собеседования, я бы не ожидал, что он будет выполнять задачи в качестве сотрудника. Было бы иначе, если бы вы получили отзыв о том, что задача слишком сложна для предоставленного срока, но я так понимаю, что они вообще не дают отзыва. Из какой страны вы находитесь/принимаете кандидатов? В любом случае, я не считаю, что удаление теста для трудоустройства является правильным путем в этом случае, звучит так, как будто вы преследуете не тех кандидатов.
Исходя из моего собственного опыта в качестве разработчика начального уровня, спрос настолько высок, что я могу пропустить любой процесс собеседования с онлайн-тестом по программированию и легко получить хорошее предложение (примечание: не техническое собеседование с вопросами по программированию , которое вы должны делать, я имею в виду 2-4-часовой тест, проведенный в свободное время, после которого я могу или не могу получить ответ) Достаточно сказать, что спрос на действительно опытных людей, вероятно, даже выше. Зачем прыгать через все ваши обручи, когда они получают электронные письма от рекрутеров каждую неделю, если не каждый день?
Я избегаю собеседований с задачами по программированию, если работа не выше среднего. Я не вижу необходимости терять несколько часов на компанию, в которую я хожу на собеседования, учитывая, что я могу пройти множество собеседований без тестов.
Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .
Поверьте мне, вы хотите отпугнуть кандидатов, которые не умеют программировать. Возможно, вы захотите пересмотреть его содержание и/или свой подход к его представлению (например, пригласите их на собеседование на месте, соедините их с программистом и попросите их посидеть в течение часа в комнате с рабочей станцией и парной программой). упражнение). Но полностью избавиться от него — очень плохая идея .
Лично я считаю тревожным сигналом отсутствие кода кандидата в ходе собеседования. Если потенциальные будущие коллеги попадут на рабочее место, не проявив никаких технических навыков, а я буду помогать поддерживать их код, это могут быть плохие времена. Кроме того, это один из пунктов теста Джоэла .
Я считаю, что источник ваших кандидатов имеет решающее значение. Рекрутинговые агенты заинтересованы в легком выходе. На местном уровне им платят (прилично) за то, что они освобождают людей от выплат по социальному обеспечению, так что на этом они концентрируют свои усилия. Если вы не получаете SS, они просто не заинтересованы (Цитата «Не тратьте свое время, не тратьте наше время».) Следовательно, мой диплом и 40-летний опыт никогда не представляются рекрутерами потенциальным работодателям. - и большинство работодателей настаивают на использовании исключительно рекрутеров.
Этот пост в блоге «технические собеседования заставляют меня плакать» от бывшего разработчика Google, а теперь разработчика академии Хана, считает, что задача, на выполнение которой вам дается неделя, — это, безусловно, лучший способ проведения технических интервью.
@FreeAsInBeer Я делаю ровно наоборот. Я считаю, что работника нельзя судить, если он не выполняет какую-то значимую работу, поэтому я лучше присоединюсь к компании, которая нанимает на испытательный срок, чем застрянет с кем-то, кого нельзя уволить, потому что «он преуспел в каком-то абстрактном тесте, поэтому он должен быть хорош в совершенно не связанных между собой сценариях реальной жизни». Особенно то, что я ищу в младшем, это то, что его код легко читается и поддерживается остальной частью команды, а не то, что он решает проблему P-vs-NP в свой первый рабочий день.
@Agent_L да, иметь испытательный срок всегда хорошая идея, и мы делаем это здесь. Беда в том, что к тому моменту, когда вы обнаружите, что они никуда не годятся, вы потеряете зарплату на 3-4 месяца и потеряете время. Стоит ли оно того?
Что вызов кода говорит вам о кандидате? Ничего такого. Даже если вы проводите это в офисе в рамках обычного собеседования, вы либо а) ставите перед ними тривиальную проблему, которая ничего вам не говорит, либо б) вы ставите перед ними проблему, которая не может быть разумной. выполняется в течение нескольких минут , если кандидат не видел его раньше. Что, опять же, ни о чем вам не говорит. «Определить, содержит ли связанный список петлю» — один из таких «попавшихся» вопросов, который является неуместным и ставит в тупик обладателей докторской степени в области компьютерных наук в течение 30 лет, но решение простое, когда оно известно.
Вы случайно не следите за этим ? Я уверен, что в идеальном мире это идеальный способ найма программистов с точки зрения работодателя, но большинство талантливых программистов уйдут раньше, чем № 5. Никто не хочет тратить свое время на то, что не гарантировано (и давайте не будем упоминать, что в США такой сложный процесс вступления в конечном итоге подрывается двухнедельным уведомлением, которое является стандартным перед увольнением).
@Cat'r'pillar, потому что тогда вы знаете, что будете работать с людьми, у которых есть навыки, чтобы пройти тест, и что работать там будет довольно сложно. Конечно, если вас не так сильно интересует позиция, в первую очередь, нет смысла идти на какое-то собеседование.
@ Draco18s не обязательно, вы можете придумать «простые» задачи, в которых используется множество технологий, например, форма обратной связи, в которой данные отправляются на сервер. Одно это требует AJAX, Jquery, javascript, CSS, HTML и JSON. Если кандидат может это сделать, конечно, это не самая сложная вещь, которую я когда-либо знал, по крайней мере, тогда я знаю, что он знает все вышеперечисленные технологии до определенного уровня, который снижает риск.
@bobo2000 Или вы можете спросить кандидата напрямую или посмотреть его портфолио. Если они претендуют на позицию полного стека и имеют опыт работы с полным стеком, что на самом деле говорит вам испытание кода, чего вы еще не знали?
@Draco18s, это часть проблемы, когда я получаю заявки, часто у них нет портфолио или учетной записи на github.
@bobo2000 У них есть опыт работы? Является ли один из их рекомендаций менеджером с аналогичной должности, которую они занимали ранее? Если «нет», то они слишком младшие для должности, на которую вы нанимаете, и опять же, вызов кода ничего вам не говорит. Если вы не нанимаете младшего разработчика, в этом случае ему не нужны все эти навыки.
@ Draco18s Я нанимаю выпускников с одной или двумя техническими стажировками за плечами прямо сейчас, и, честно говоря, спрашивать бывшего менеджера - не всегда лучший подход, если соискатель не ладил с ним, но в остальном был способным кодером.
@ bobo2000 Межличностные отношения должны быть исключены, когда вы спрашиваете о технических навыках. Вызов кода по-прежнему не подходит для текущей работы. nomachetejuggling.com/2014/06/24/…
@ Draco18s не все менеджеры этичны - я когда-то работал с одним, который был довольно мстительным, поэтому я воспринимаю то, что они говорят, с долей скептицизма.
@ bobo2000 Если менеджер будет мстительным, кандидат не будет включать его в список рекомендаций. Я имею в виду, действительно.
@aroth, но этот тип задач не «отпугивает» в зависимости от способностей, он выбирает людей, которые не так ценят свое время и фактически могут снизить качество кандидатов.
@Draco18s, если это твоя единственная работа, иногда у тебя нет особого выбора.
@ bobo2000 Хотя это может быть, вызов кода по-прежнему ничего вам не говорит. Нет ответа, который был бы объективно правильным для всех людей, участвовавших в рассмотрении ответа.
@JamesRyan или выбирает тех кандидатов, которые действительно хотят работать на вас.
@ bobo2000 нет, нет разницы между теми, кто действительно хочет работать на вас, и теми, кто действительно хочет работать на кого угодно. И кроме того, пока они на самом деле не поработают на вас, они еще не знают, понравится ли им работать на вас, так что нет, вы также не отбираете энтузиастов и счастливых сотрудников таким образом.
Вы можете за 1 час выучить 90% того, что вы выучите за несколько часов. Остальное вы не увидите до тех пор, пока у них не будет пары недель, чтобы обустроиться и научиться вашим методам ведения дел (или нет). Эти затянувшиеся задачи — пустая трата времени и откровенно грубо, чтобы заставить людей прыгать через обручи. У таких компаний, как facebook и google, есть тысячи кандидатов, которых нужно сократить, а у вас нет.
@RonBeyer, если я, как кандидат, считаю, что задача требует слишком много времени, я не буду тратить время на обратную связь. Какую пользу мне это приносит? Просто перейдите к следующей возможности. Мое решение хорошо или плохо для компании? Не знаю, плевать. Тратят ли компании много времени на предоставление отзывов кандидатам, с которыми они решили не работать?
Я видел, как тесты по кодированию были проведены правильно, но не как фильтр перед собеседованием. В одном месте, где я работал, после 80% технических собеседований меня помещали в комнату со средой разработки ВМ, документацией по требованиям и набором тестов, созданным специально для (довольно специализированной) работы, для которой меня наняли; когда это было сделано, у всех инженеров была возможность спросить о моем выборе. Это было (1) уважением к моему времени (они не просили меня тратить время, пока они не потопили мое собственное) и (2) демонстрация усилий с их стороны (создание этого инструмента для позиции, которую они заполняли только одну) .
... когда тест по кодированию структурирован таким образом, что инженеры компании тратят на него свое время - и он предоставляется только после предыдущих собеседований - он меньше читается как «мы не уважаем ваше время как кандидата». , и многое другое, поскольку «мы действительно заботимся о создании высококлассной инженерной команды». Я устроился на эту работу (которая была в магазине, в котором действительно была высококлассная команда), после того, как отказался от многих других мест, занимающихся неуважением к вашему времени перед телефонным звонком. проверка кода.
Если вы ожидаете, что кандидат будет программировать для вас, заплатите ему за его время. Тот факт, что они ищут работу, не означает, что у них еще нет работы или что их время не ценится. Когда вы думаете об этом, вы уже сжигаете деньги в виде часов сотрудников только для того, чтобы взять у них интервью. Таким образом, вы просите кандидата «собеседоваться» еще 2-4 часа, и тем не менее вы экономите время, которое стоило бы вам в рабочих часах, чтобы провести собеседование еще 2-4 часа. Таким образом, платить кандидату за часы тестового кодирования — это не тратить больше денег.
Тесты на месте @CharlesDuffy работают, только если кандидат находится в той же стране, если вы проводите собеседование с кандидатами за границей, которые ищут работу в Великобритании, это непрактичное решение.
@bobo2000 дистанционное собеседование с кандидатами из другой страны проводится очень редко и обычно проводится только тогда, когда требуются очень специальные навыки. Риск того, что у них возникнут проблемы с переездом, слишком высок, и в большинстве случаев есть такой же хороший местный кандидат.
@JamesRyan на самом деле это не так, многие выпускники, в частности, проходят техническую стажировку за границей и учатся в лучших школах. Пару дней брал интервью у одного выпускника Кембриджа.
@ bobo2000 Ну, тянуть эту ерунду к выпускникам еще хуже, потому что у них нет опыта тестирования. Кроме того, если они выпускники Кембриджа, они будут проходить собеседование в Великобритании, прежде чем закончат университет, так что я думаю, что вы говорите чепуху.
@JamesRyan многие из выпускников, у которых я брал интервью, прошли 1 или 2 технических стажировки, на самом деле выпускник Кембриджа в настоящее время проходит одну в Гонконге. Он создает RESTful API в рамках своей стажировки.
Приходилось ли вам выполнять двухчасовое задание отдела кадров, чтобы доказать, что вы хорошо разбираетесь в управлении персоналом, прежде чем вас наняли?
@ДА. Это не моя работа, я PM. Я просто делаю это, так как больше некому этим заниматься... и это не имеет значения, если вы уверенный кодер и заинтересованы в работе в компании, что в этом такого? Во всяком случае, если они этого не сделают, вероятно, отсеют их, поскольку они никогда не были заинтересованы в работе в компании с самого начала (или не были настолько уверены в своих способностях к кодированию).
@ bobo2000 Дело в том, что большинству людей не требуется, чтобы профессионалы проходили многочасовые «тесты», чтобы «доказать свою ценность». В идеале, человек получает хорошее представление о собеседованиях, резюме, портфолио, образовании и рекомендациях кандидата. То, что мы требуем, чтобы разработчики делали это, вообще странно.
@DA, а что делать, если у них нет портфолио, аккаунта на github, а просто резюме с кучей неизвестных компаний? Откуда вы знаете, что в компании x, y парень писал хорошо написанный код?
@bobo2000 примени это к любой профессии
@ДА. Я только что просмотрел резюме предыдущего сотрудника, которого уволили после того, как он много слышал о том, как присоединился к компании. У него были все навыки на бумаге, TDD/BDD, Ruby on rails, Rspec, но когда дело дошло до дела, его уволили, потому что он был плохим... плохой найм стоил компании времени, ресурсов и кода низкого качества. который с тех пор был переписан. Тогда не было процесса проверки. Разработчикам слишком хорошо платят, чтобы их не проверяли. Если кто-то подал заявку и плохо разбирался в администраторах, это не имеет большого значения, поскольку они не строят цифровой дом.
@ bobo2000 снова, однако, примените это к ЛЮБОМУ профессионалу. Откуда вы знаете, что врач хорош в хирургии? Как узнать, что пилот умеет летать на самолетах? Я не говорю, что тесты плохие или хорошие. Я просто указываю на то, что кажется странным, что разработчики — одна из немногих профессий, где мы чувствуем острую потребность всегда их тестировать. Я бы сказал, что наем разработчика, который выглядел хорошо на бумаге, но не на самом деле, был ошибкой менеджера по найму, который, возможно, не полностью проверил рекомендации или не дал подробного интервью. И наконец, человек может отлично сдать тест, но при этом провалить ежедневную метрику.
@ДА. потому что плохая команда разработчиков может погубить технологический стартап, где качество продукта является ключевым фактором его успеха. Без какой-либо формы тестирования разработчик может провалить собеседование; рекомендации могут быть предвзятыми (рекомендацию может дать их друг), и хотя я согласен с тем, что тест в любом случае не является ответом, в сочетании с техническим телефонным интервью вы, вероятно, получите действительно хорошее представление о способностях кандидатов. Речь идет о снижении риска плохого найма, а не об его устранении.
Не могли бы вы показать копию одного из примеров? Мне искренне интересно, насколько это сложно. В любом случае, как кандидаты представляют свои результаты? Я считаю , что ideone.com — отличный способ провести простые тесты. Вы создаете шаблон с «вводом», они вставляют свой код и предоставляют вам источник и «вывод». Придержите материалы, чтобы увидеть, не копируют ли кандидаты данные из CareerCup или StackOverflow. Попробуйте разбить большие одночасовые задачи на 3–5 частей, чтобы кандидаты не чувствовали, что это экзамен по принципу «все или ничего».
@Dogbert Не могу опубликовать его публично, но я структурирую тест таким образом, чтобы иметь основную задачу и присуждать кандидату бонусные баллы за дополнительные задачи. Так, например, для теста Javascript это было похоже на завершение теста с использованием Jquery, javascript, css, html, ajax, где бонусные баллы начисляются за выполнение теста в среде JS, такой как AngularJS. Сам тест будет очень простым функционалом. Недавно у меня был соискатель, который выполнил задание в AngularJS, хотя это и не требовалось, и был очень впечатлен его отношением. Нанял его сразу.
@Dogbert Я также думаю, что главное, что я ищу, это чтобы кто-то хотя бы попытался это сделать, поскольку это дает мне хорошее представление об их отношении к роли и о том, насколько они этого хотят.
@bobo2000 Интересно, что кандидаты даже не попытались пройти тест. Что ж, возможно, это лучший механизм фильтрации, чем вы предполагали изначально. :)
В конце концов, тест @Dogbert оказался для нас хорошим - в конце концов мы нашли кого-то, кто попытался его пройти и хорошо его прошел (получив бонусные баллы), он оказался действительно хорошим сотрудником. Ему нужно очень мало тренировок, не больно управлять, и он сразу же берется за дело.
@bobo2000 Рад слышать! Надеюсь, что с этим подходом в вашей компании дела по-прежнему идут хорошо.
Это точно и мой опыт. Я делаю тест по программированию на собеседовании, на доске, что обычно занимает около часа. Около 90% кандидатов не проходят его. Остальные 10% совершенно не стоят того, чтобы нанимать остальные 10%. Мы делаем это и со старшими кандидатами, но ожидаем более высоких стандартов.
Рынок на стороне опытных разработчиков, которые могут пропустить эти тривиальные глупые тесты.
@SuperUberDuper Я не даю тест по программированию опытным разработчикам, если они уже доказали свои навыки в своем резюме, имея большой опыт работы с респектабельными брендами. Совсем другая история со стажерами/выпускниками, которым часто не хватает коммерческого опыта, поэтому ключ в том, чтобы попытаться выяснить, есть ли у них потенциал и уже есть основы для их формирования. Это также многое говорит об их отношении к работе, если они могут уделить немного времени и пройти тест.
@bobo2000 точно, хорошие моменты
@RonBeyer Я думаю, вы проводите несправедливое сравнение. Как сотрудник, вы взяли на себя обязательство выполнять эту работу, у вас есть контракт с компанией, и вы получаете ОПЛАТУ за свое время. Но как простой интервьюируемый, у вас нет никаких обязательств в отношении профессиональных отношений ни с вашей стороны, ни со стороны компании, ни подразумеваемых, ни явных. Поэтому отказ выполнять многочасовое задание по программированию в рамках собеседования очень сильно отличается от отказа сотрудника от чего-то подобного.
@RaduMurzea ключ в том, чтобы разработать тест по программированию, который длится от 30 минут до 1 часа. Если кандидат не удосужится это сделать, то мы его отклоним, так как это многое говорит об его отношении к роли.
Проекты прослушивания отличаются от вопросов для интервью по кодированию. по крайней мере, проект может включать в себя более интересные задачи и давать свободу выбора , что и как реализовать . тесты по кодированию обычно очень сконцентрированы и откровенно скучны.
"хорошее отношение к компании и роли" - представьте, если интервьюируемый получает 10 таких заданий в неделю и каждая компания думает так же. С его точки зрения, интервьюер оторван от реальности.
@Pithikos В наши дни многие компании проводят технические собеседования. Google очень строгий. Мы не Google, нет, но это не значит, что мы должны снижать наши стандарты, не имея процесса технического отбора, что увеличивает риск найма неподходящих сотрудников.
@Pithikos также только что проверил, у Facebook есть домашнее задание по кодированию интервью для какой-то должности.
Дать очень короткое (5-10 минут) упражнение по кодированию во время собеседования — это нормально, но вы не можете ожидать, что люди потратят впустую час своего времени. Интервьюируемые не знают, что его заполняют очень немногие. Суть в том, что вы можете думать, что хотите, но если они не увидят в вашей компании чего-то экстраординарного, они не станут изо всех сил стараться вам угодить, не только с небольшим шансом, что вы перезвоните им из потенциально десятков. или сотни людей, прошедших тот же тест. Они просто переходят к следующей компании.
Кроме того, я только что заметил, что вы даете им тест по телефону! Поставьте себя на их место на мгновение. Они даже не встречались с тобой. Они ничего не знают о вашей компании, а вы уже тратите их время на то, что они считают бессмысленными играми. Как бы вы отреагировали в такой ситуации? Вы упомянули Google и Facebook, и мне очень жаль вас разочаровывать, но вы не Google и не Facebook. Экстраординарные компании могут позволить себе требовать экстраординарных усилий от своих соискателей, а обычные компании — нет. Вы ничего не можете сделать, кроме как смириться с этим.
@Demonblack да, безусловно, это означает, что мы получим меньше кандидатов, но именно поэтому, когда мы в конечном итоге набираем кого-то, мы уменьшаем вероятность плохого найма и обычно нанимаем людей, у которых нет опыта, но которые чрезвычайно мотивированы учиться . Просто на это уходит больше времени, и тех, кто уверен в своих силах, это ничуть не смущает.
@ bobo2000 Тогда я думаю, что я что-то здесь упускаю. Кстати, я думаю, что с вашим методом у вас также снижается вероятность хорошего найма, но это не относится к делу. Если вы действительно получаете то, что хотели, в чем проблема?
В то время, когда я опубликовал этот вопрос (год назад), у нас были проблемы с использованием этого процесса, и мой вопрос заключался в том, был ли он слишком тяжелым для подхода, но с тех пор мы его оптимизировали, и теперь он работает нормально.
Эм, быстрый вопрос, как программист может списывать при задании. 80% нашей работы — получение кода из интернета.

Ответы (24)

Вам нужен тест по программированию. Но это должно быть 5-10 минут. 30 минут максимум. Не существует двухчасового теста, который точно скажет вам, насколько хорош программист. Вы не сможете сказать, постоянно ли они пишут пригодный для сопровождения код, или они всегда правильно комментируют, или они придумывают нечитаемую мешанину «умных» решений проблем и т. д. За 2 часа единственное, что вы достижения заключается в том, чтобы выяснить, кто откровенно лжет о знании языка / программирования.

За исключением того, что вы должны быть в состоянии обнаружить откровенное мошенничество гораздо быстрее, чем за 2 часа. 5 минут написания FizzBuzz и 2-3 коротких вопроса о специфике языка покажут вам, что они абсолютно бесполезны. И это лучшее, что вы можете сделать на собеседовании.

Позвольте мне сказать вам, что я подумал бы, если бы получил 2-часовой экзамен за привилегию проведения собеседования:

«Либо эти люди думают, что это имеет ценность, что означает, что они понятия не имеют, что они делают, ЛИБО они знают, что это пустая трата времени, но по какой-то причине (вероятно, слепо следуя бюрократии HR) они готовы тратить впустую еще до того, как кандидат будет принят на работу.

В любом случае, я не хочу там работать».

Есть еще одна вещь, которая может оттолкнуть кандидатов : продолжительность процесса собеседования. У вас есть люди, которые проводят телефонные интервью. Затем домашний тест, на завершение которого у них есть неделя. Затем вы проходите тесты. Затем вы устраиваете личное собеседование с руководством. Затем (я полагаю) вы даете пару личных интервью. Затем вы возвращаетесь к парню, которого хотите нанять. Что для этого нужно? 2 недели? Дольше?

За это время я получил уже 3 предложения. Я принял один, и я начинаю на следующей неделе. Думаешь, я пойду делать твой двухчасовой тест?

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .
Но это должно быть 5-10 минут. 30 минут максимум. - Это не должно быть таким коротким, но если они сделают это на месте, прежде чем они уйдут, это повысит процент завершения. Неважно, что это двухчасовая задача, если вы заставите их делать это дома, они не вернутся домой и решат, что это не стоит усилий. Но в целом я согласен с тем, что испытание типа «быстрое шипение», скорее всего, даст такие же результаты, как и более глубокий тест, с меньшими усилиями, необходимыми для оценки результатов. И если процесс найма занимает 3-4 недели, я уже начал где-то в другом месте.
Я не возражаю против более длительных собеседований - я думаю, что это немного отличается. Вопрос в том, хотят ли кандидаты работать где- нибудь или в вашей компании . Дайте мне неделю или две, чтобы сделать домашнее задание и решить, хочу ли я переехать и куда, и сколько это будет стоить, и я с большей вероятностью приму предложение. Поторопите меня, и я не могу.
Нет, вам не нужны никакие тесты по программированию. Что вам нужно, так это испытательный срок.
@Agent_L Замена сотрудника, зарабатывающего 40 000 долларов, обходится (в среднем) в 16 000 долларов. Замена работника, который зарабатывает 80 000 долларов, стоит 120 000 долларов. Это безумная сумма, чтобы заплатить за пробный период, чтобы отсеять половину ваших кандидатов, когда вместо этого вы можете дать 5-минутный тест бесплатно. Серьезно, с какой стати вы нанимаете кого-то и начинаете платить ему несколько недель/месяцев только для того, чтобы узнать, что он солгал в своем резюме? Зачем это делать, если можно потратить 5 минут и не заплатить им ни копейки, чтобы узнать то же самое?
но вам нужно знать, насколько они знакомы с платформой, над которой они будут работать. в зависимости от уровня опыта, который вам требуется, объем концепции и архитектуры, которые могут потребоваться для вашего теста, могут сильно различаться.
@Шейн ЧТО? Вы просто платите им за то, сколько они работали. Если они врали, то это видно в первые дни, а потом отпускаешь (даже не говоря о том, что если ему удалось тебя надуть на собеседовании, то нанимай его продавцом). 40 тысяч долларов в год — это всего лишь 158 долларов в день. То, что вы упомянули, - это издержки найма не того человека, основанные только на способности решать тесты. И потребовались месяцы, чтобы понять, что он не командный игрок. Ваше решение стоит 16 тысяч долларов, а не мое.
@Agent_L: Затраты на неудачный найм намного выше, чем потраченная не по назначению заработная плата. К ним относятся необходимость повторного найма, например, и все административные действия, связанные с добавлением человека в штат. Я не знаю, откуда взялись цифры Шейна, но они не кажутся необоснованными. Вероятно, что 16 000 сверх оклада, который дают плохому найму. Поскольку вы предлагаете альтернативные решения, предположительно, вы были менеджером по найму или работали в какой-то должности, связанной с наймом?
мне кажется, что испытательный срок при устройстве на работу привлечет много посредственных/ужасных программистов, а очень хорошие не придут работать к вам на 1-2 месяца, чтобы потом узнать, приняты ли они на работу. Просто мое мнение
«Это не должно быть таким коротким, но если они сделают это на месте, прежде чем они уйдут, это повысит процент завершения…» - Лично я бы попросил их сделать это до того, как их пригласят на место. Заставьте их делать это, когда они отправляют резюме. Зачем тратить время на кандидатов, которые не соответствуют минимальным или базовым стандартам?
@Agent_L это зависит от того, где вы работаете. В некоторых странах, когда вы начинаете работу, вы не можете просто для парня через 2 дня, это может занять недели или месяцы, и в то же время вы должны платить им.
@Agent_L Я живу в одной из тех стран, где действительно трудно уволить кого-то после того, как нанял его. Вы должны пройти формальный процесс, который занимает месяцы.
Стоит добавить, что эти же принципы применимы ко всем тестам, а не только к тестам программирования. Все тесты «Домашнее задание» дискриминируют занятых и востребованных людей и, как правило, проверяют неправильные вещи (знания в предметной области, которые можно изучить на работе, а не способности , которые нельзя). У меня было то же самое в команде, которая набирала графических дизайнеров, используя многочасовое домашнее задание «Дизайн X в стиле нашего бренда», которое я заменил своего рода болтовней на собеседовании для творческого мышления .
@GustavBertram Да, я живу в Польше, где так сложно кого-то уволить, что никто больше не получает настоящий трудовой договор. Контракт с заранее определенной продолжительностью, передача прав на интеллектуальную собственность, контракт на выполнение определенной задачи, контракт на случайную работу — варианты бесконечны. Все, что вам нужно, это взаимное желание обойти ограничения.
@Шейн, стоимость плохой более высокой статистики очень интересна. У вас есть источник для этого? Я верю вам и согласен с тем, что плохой найм стоит дорого, но цифры мне показались слишком высокими. Спасибо!
Я не понимаю всех людей, говорящих, что @Agent_L неправильный и будет дороже. Суд проводится, чтобы они могли уволить вас по любой причине, и они должны были выплатить вам только месячную зарплату. Вы могли бы сказать, что процесс найма стоит денег и т. д., но отказ от найма также стоит им денег.
@EpicKip Итак, вы нанимаете кого-то для выполнения работы. Допустим, их месячная зарплата составляет 1000 долларов. Вместо того, чтобы работать продуктивно и приносить компании 2000 долларов прибыли, они ничего не делают. Затем требуется месяц, чтобы найти кого-то нового. При хорошем найме компания могла бы иметь в кармане 4000 долларов после продаж и зарплаты. Вместо этого это 1000 долларов долга от расходов на зарплату. Компания потеряла 5000 долларов. Есть и другие факторы, например, чем дольше вы работаете, тем эффективнее вы работаете, но в основном это суть.
@Shane Вы не можете найти все в тесте. Я программист, и любое место, которое нанимает (по крайней мере, в Нидерландах), наймет вас на основе 1-месячного пробного периода (у них есть собеседование и, возможно, очень небольшой тест). И отказ от найма кого-либо из-за долгого/неправильного процесса найма будет стоить компании дополнительных сверхурочных денег.
"У них есть интервью и, возможно, очень маленький тест" Угу, да. Это именно та часть, о которой мы говорим здесь. Вопрос об этой части интервью и о том, стоит ли проводить очень маленький тест. И мой первый абзац подробно продолжается о том, что «Вы не можете найти все в тесте». Быть может, вы из Нидерландов, у вас есть языковой барьер? Но я бы посоветовал вам перечитать вопрос и мой ответ, потому что я думаю, что мы больше согласны, чем не согласны.
@Draco18s Первый абзац: « Одна вещь, которую я недавно заметил в поиске работы, — это количество компаний, которые настаивают на том, чтобы вы написали им образец кода в соответствии со спецификацией. Не просто образец кода, а полностью функциональное, законченное приложение. Это абсурдно по нескольким причинам ». Далее он говорит: « Джоэл Спольски говорит о том, как важно просить разработчиков писать код во время их интервью. Но он также подробно рассказывает о том, как он интерпретирует это в своей собственной компании: а именно, он просит людей написать функции во время интервью ». Это идентично тому, что я говорю. 1/2
@Shane Quick, напишите мне на доске функцию, которая будет определять, содержит ли односвязный список цикл. Идти. Кроме того, вы не можете изменить структуру данных или создать новый список.
2/2 Он заканчивает словами: « Задайте несколько технических вопросов, требующих кода, на собеседовании ». Жалоба, которую он предъявляет к тестам на кодирование, касается того типа теста, о котором спрашивал ОП. Этот ответ рекомендует то же самое. Кроме того, я не согласен с тем, что это показывает, что они не могут учиться. Это показывает, что они хоть чему-то научились. Их стиль кодирования не похож на «гугл для образцов кода и надежды». Помимо демонстрации способности изучать программирование 101, мало что из того, что вы будете делать в процессе собеседования, может показать, что кто-то со временем учится. Или, по крайней мере, я хотел бы услышать, как вы можете выяснить это за несколько минут.
Да, это был бы достойный вопрос — при условии, что ваш магазин работает с технологиями, использующими связанные списки. Хотя лично я не сторонник искусственных ограничений, как у вас.
Долгий домашний тест перед первым личным собеседованием — это шутка.
«Но это должно быть 5-10 минут» - тогда вы потеряете много хороших кандидатов, которым просто нужно время, чтобы рассмотреть разные решения и т. д. 30 минут имеют смысл.

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

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

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

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

Моя нынешняя компания сделала это хорошо, и я бы пошел по этому пути на вашем месте. Дайте им небольшую задачу, на выполнение которой уйдет, может быть, 90–120 минут, и попросите их обосновать в комментариях, почему они выбрали именно такой способ решения проблемы. Это то, что можно сделать за одну ночь, и это даст вам представление об их мышлении.

Я могу сказать вам прямо сейчас, что если я получаю проект, который занимает 8+ часов, я говорю им спасибо, но мне это не интересно. У меня хорошая работа и жизнь. Если менеджер видит в этом проблему, это говорит мне, что ему все равно на мой баланс между работой и личной жизнью на работе (особенно если им все равно до того , как я его получу). Ни одной компании, за исключением, может быть, Google, Apple или Facebook, это не сойдет с рук.

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .
@ Арон, платить им за тест не имеет экономического смысла, учитывая количество разработчиков, с которыми мы беседуем. В то же время я открыт для предложений о том, как сделать процесс лучше. Единственное, что меня беспокоит, это то, что если я этого не сделаю, и мы закончим тем, что наймем плохо, потому что окажется, что парень не умеет программировать (это уже случалось), в долгосрочной перспективе это будет стоить нам намного дороже.
Не согласен с другими здесь и +1, хотел бы я добавить больше, потому что «я думаю, что упражнения по программированию - это провал». Вы как бы возвращаетесь к этому, предлагая задачу по программированию, но все же. Я согласен с вами, они смешны и вообще не работают, потому что я работал со многими людьми, которые вроде бы прошли эти тесты, но некомпетентны. На самом деле многие люди, с которыми я работал рядом, не выполняли свою настоящую работу, а сидели и изучали вопросы типа собеседования, чтобы они могли подать заявку на другую работу программиста на работе. Этот процесс должен умереть.
Google и Facebook имеют высоко оптимизированные процедуры найма, и ни один из них не использует домашние тесты как часть указанных процедур.
Должно быть, это было написано до того, как спрашивающий уточнил длину теста, потому что сейчас это ужасный ответ.
@stannius Это неправда. У Facebook есть домашний проект в рамках процесса собеседования. я взял это
«дайте им небольшую задачу, которая должна занять всего 90–120 минут». Судя по вашему собственному описанию, это кажется хуже , чем задача по программированию, которая занимает 30–60 минут, а это то, чем они сейчас занимаются.
Google также предлагает оценку программирования на дому (онлайн и по времени). Хотя это совсем ненадолго.
Что ж, либо это новый процесс (в прошлом году), либо он не используется в их офисах в Сиэтле, либо они не заставляют всех это делать.
@stannius - Судя по моему опыту, вы правы насчет домашней тестовой части, по крайней мере, для Google. Однако они заставят вас писать код во время собеседования. Несколько раз. Обычно на доске и перед несколькими разными интервьюерами (которые все являются членами команды разработчиков). Кроме того, в ответе не говорится: «Упражнения на дом — это провал», а говорится: «Упражнения по программированию — это провал». Что очень отличается. И Google, и Facebook обязательно используют упражнения по программированию, когда берут интервью у программистов. Эта часть этого ответа просто неверна .
@aroth В этом контексте я имел в виду домашние упражнения по программированию, а не те, которые выполняются на доске во время интервью. Я ожидал бы этого от любой компании, в которой я беру интервью, несмотря ни на что.
Помните тех людей в старшей школе, которые были совсем не умными? Да, эти люди будут работать с вами в той или иной форме. Это могут быть программисты, врачи, юристы, сантехники, профессора, кого угодно — есть тупицы, выполняющие эту работу. Проблема в том, что слишком много рабочих мест и не хватает преданных своему делу, трудолюбивых и умных людей, чтобы заполнить их. Таким образом, вы получаете лжецов, мошенников, скупердяев в любой области, на любой работе. Я слышал ужасные истории о программистах, которые буквально не могут даже включить компьютер. Нет способа бороться с этим.
90-120 минут? Если вы сказали мне, что хотите, чтобы я провел два часа , выполняя упражнение в рамках первого собеседования, вам лучше надеяться, что ваши объявленные цифры зарплаты значительно выше, чем у конкурентов, потому что в противном случае я ухожу, как и все остальные, кто не является безработным. . Только отчаявшиеся люди соглашаются на такую ​​трату времени, и из-за своей несправедливости они, как правило, не самые лучшие программисты.
То есть вы бы не наняли кого-то, кто работает полный рабочий день, а также над другими личными проектами или проектами с открытым исходным кодом? Вы не заставите кого-либо тратить 100% своей полосы пропускания программирования для вашей компании. Я надеюсь, что они могли бы помочь своим детям с домашним заданием.
Даже Google, Apple или Facebook не требуют 8+ часов проекта на дом. Тем не менее, многие кандидаты готовы это сделать. Просто потому, что проекты на вынос — это огромный красный флаг.

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

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

Плохой разработчик может тянуть столько, сколько захочет. Вы не увидите, что они занимают в 4 раза больше времени; вы просто увидите завершенный тест. Вы также не увидите, как они обращаются к Google или своему приятелю за помощью с ifзаявлением.

Моя последняя компания сделала это, и подавляющее большинство людей, которых мы пригласили для личного собеседования, не получили одобрения Fizz (около 65%). Думаю, это произошло из-за того, что мы непреднамеренно отсеяли хороших, занятых людей, которым не нужно было собеседование в другой компании, и в то же время навязывая легкое собеседование плохим кодерам.

Что, я думаю, мы должны были сделать вместо этого

Вместо того, чтобы давать людям домашнее задание, на оценку которого уходит 15-20 минут, нам нужно было провести 15-20-минутное собеседование по Skype, где мы задавали вопросы типа Fizz buzz. Это заняло бы столько же времени, но я, скорее всего, отсеял бы плохих программистов до двухчасового личного собеседования.

К вашему сведению -> Вот очень подробная статья о Fizz-buzz и общих методах проведения собеседований.

Однажды меня попросили выполнить задание по программированию на hackerearth.com и ввести личную информацию, чтобы зарегистрироваться. Это было немедленное отключение. Более того, сама задача программирования не была надежным индикатором способностей. Я согласен, что такие домашние задания действительно того не стоят.
Единственный раз, когда я когда-либо делал домашнее задание по программированию, менеджер по найму преследовал меня, потому что у меня не было 1 дня на выполнение. После этого я решил, что, если я снова получу домашнее задание, сказать, что меня не интересует эта работа.
только времени недостаточно, чтобы должным образом выполнить задачу.
Проблема с практикой кодирования интервью Fizz заключается в том, что у вас есть числа, которые делятся и на 3, и на 5. Это первое, что приходит мне в голову, и какой порядок вы бы хотели в таких ситуациях. Если только вам не нужны данные.
@Чад, что можно заказать? coliru.stacked-crooked.com/a/bab3aa8f4ea44fcd
@TechnikEmpire у вас есть числа, которые делятся на 3 и 5. Таким образом, вы получаете как Fizz, так и Buzz за одну итерацию. Порядок, который из двух идет первым, зависит от того, как вы упорядочиваете свои делители, например, 3 сначала или 5 сначала. Что-то, что я видел в вашем примере кода, вы сделали то же самое.
@ Чад, ладно, просто не понял, что ты имеешь в виду.
@TechnikEmpire, кстати, просто для удовольствия, я сделал это по старой школе. coliru.stacked-crooked.com/a/31dc2f5cbbc0e76b
@TechnikEmpire Мне очень понравилось читать ваш код, интересно посмотреть, как далеко продвинулся С++.
@Чад Найс. это мне чуждо, потому что я никогда в жизни не пользовался printf. ржунимагу
Расскажите, пожалуйста, подробнее об этих ifвысказываниях — это те, которые вызывают нападение велоцираптора?
@CodeJockey Да, если заявления злые, давай, чувак, не отставай от 10000000 произвольных «стандартов», которые составляют случайные люди и компании, чтобы решить, кто более элитен, чем следующий парень. Боже, ты провалил тест на собеседование, ты, должно быть, плохой программист (это явно сарказм).
Мой любимый способ сделать FizzBuzz, если у меня есть выбор языка (без математики, операторов if или технически даже циклов):filter fb{@($_,"Fizz","Buzz","FizzBuzz")[0+(@(2)[$_-match'[^05]$'])+(@(1)[$_-notmatch'(^([369][0369]?|[258][147]|[147][258]))$'])]}1..100|fb
@CodeJockey: И я бы попросил вас написать версию, которую я могу понять.
@ gnasher729 - вот почему вы либо не дали бы мне выбор языка, либо потребовали бы от меня (если бы у вас было время) объяснить, как работает мой пример. В случае с моим примером (PowerShell) вместо математики (то есть большего, чем простое сложение и умножение) вы используете регулярные выражения; вместо операторов if вы используете автоматический выбор индекса массива; и вместо цикла вы используете диапазон целых чисел, переданных в фильтр.
@gnasher729 — это более удобочитаемая версия, которую я добавил в Rosetta Code, если вам интересно: rosettacode.org/wiki/…
Вы объяснили всю мою проблему с особенно сложными проблемами программирования доски. Великие программисты не станут его изучать — они уже купаются в предложениях. Амбициозные, но посредственные программисты знают, что они в невыгодном положении, и будут учиться. Конечным результатом такого рода тестирования, который является конечным результатом большинства вздорных интервью, является то, что сигнал полностью теряется в шуме.
@CodeJockey Вы провалите и тест на ремонтопригодность, и тест на хитрость :-) Только (несколько) шутите о последнем; но первое чрезвычайно важно. «Умные» решения отвергаются при проверке кода

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

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

Заметьте, я сказал «короткий» . Мы даем кандидатам ноутбук с правильно установленной Eclipse (выбранной нами IDE), когда они приходят на собеседование. Правильная настройка означает, что у них есть доступ к исходному коду jdk, но нет интернета, и их просят не пользоваться мобильными телефонами во время теста. У них есть час, чтобы решить от нуля до пяти проблем, начиная с «FizzBuzz» и повышая сложность до чего-то порядка простой многопоточной системы производителя/многократного потребителя.

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

Между прочим, у нас были якобы опытные программисты , которые не могли правильно понять FizzBuzz. Позвольте мне повторить это еще раз: у нас было несколько кандидатов, которые не смогли правильно заполнить FizzBuzz. Обычно не следуя указаниям, но читая спецификацию, это важная часть работы разработчика.

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

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

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

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

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

Я не ожидаю отрицательных голосов. Вы полностью соответствуете другим ответам, выступая за более короткие тесты на месте и против длинных домашних тестов. Единственное, с чем я лично не согласен, так это с пунктом «нет интернета». Для разработчика Интернет является одним из основных инструментов его работы — его удаление показывает, насколько хорошо они обходятся без Интернета, что не имеет отношения к 99% рабочих мест разработчиков.
@Peter Может быть, даже лучше разрешить доступ в Интернет и просто посмотреть, куда они идут. Они идут в StackOverflow, чтобы что-то проверить? Сюда приходят жаловаться? (Конечно, такой мониторинг должен быть явно заявлен программисту и требовать его согласия, чтобы в дальнейшем избежать разногласий.)
Честно говоря, ваш ответ совсем не противоречит другим ответам/общему настроению. IMO существует (огромная) разница между «выполнить эту задачу в свободное время, чтобы попробовать эту должность» (текущий процесс OP) и «давайте вместе оценим ваши способности и пригодность для компании» (что вы предлагаете) .
У моего нынешнего работодателя мы делаем что-то подобное, и это ближе всего к ответу, который я бы написал. Я бы добавил одну вещь (возможно, вы могли бы добавить как вариант или примечание для ОП?): Мы разрешаем доступ в Интернет и проводим тесты как упражнение «парного кодирования» с членами команды, с которыми человек будет работать. Партнер по кодированию помогает объяснить цели, отвечает на вопросы, помогает, если необходимо, т. е. очень похоже на то, как они будут работать вместе на практике. Мы не только оцениваем технические навыки, но и получаем хорошее представление о том, как кандидат работает с другими.
@NeilSlater Я полностью за подход на месте, но что, если кандидат проходит техническую стажировку за границей? Я беру интервью у одного кандидата, который находится точно в такой же ситуации в Гонконге, и хочет вернуться в Великобританию, как только все закончится.
@bobo2000: Если кандидаты - это особый случай, то нужно придумать, что делать. Я мог бы провести тест парного программирования по видеоконференции для вашего примера и выделить на это немного дополнительного времени. Может быть, это основа для других вопросов и ответов по Workplace SE? В любом случае, я не думаю, что беспокойство обо всех возможных особых случаях должно помешать вам иметь продуманный стандартный подход, и вполне нормально предположить, что одна часть собеседования проходит на рабочем месте.
Согласен с @Peter. Если бы я брал у вас интервью, фраза «нет Интернета» заставила бы меня подумать, что вы цените запоминание API больше, чем понимание концепций, что заставило бы меня дважды подумать, прежде чем принять предложение о работе от вашей компании. В остальном я в целом согласен с ответом, и последнее предложение особенно верно.
@reirab Я не понял. «Нет интернета» не означает «запоминание API». Любой приличный ide (мы используем eclipse) связывает вас с исходным кодом jdk. Я работаю в Windows, поэтому «Открыть объявление» привязано к клавише F3. Я сильно ударил . Я бы разочаровался в кандидате, который этого не сделал. I have just edited my answer to make clear that the jdk sources are available to the candidate.
Переполнение стека @CPerkins? Может быть, потому, что я не специалист по Java, но услышать, что бит доступа к Интернету отсутствует, было бы для меня серьезным красным флажком. Я не хочу тратить свое время на изобретение велосипедов. Разве что задачи настолько элементарные (т.е. fizzbuzz), что любой программист мог бы решить их сразу. Я думаю, вы хотели бы, чтобы я решал проблемы , IDE — это только один инструмент из многих, необходимых для этого.
@JaredSmith да, это я, почему? Естественно, мы также занимаемся вербальным дизайном, просматриваем предыдущую работу и все такое. Но вот как мы это делаем. Мне комфортно осознавать, что это может стоить нам нескольких хороших кандидатов. "Нет доступа в Интернет" является преднамеренным. Речь идет о способности кандидата solveрешать проблемы на основе собственных знаний и навыков, подкрепленных источниками jdk, где это необходимо, чтобы напомнить нам (и мне тоже) о деталях API, в отличие от поиска чужого решения в Google или обращения за помощью к другу. .
+1 явно за «Одна из вещей, которые я решил за те годы, что мы этим занимаемся, заключается в том, что любая компания, которая не проводит тестирование, с меньшей вероятностью примет меня в качестве сотрудника». Компания, которая заботится о моих способностях к программированию, имеет гораздо больше шансов получить мой голос, чем компания, которая просто верит мне на слово в отношении навыков и любит мою личность. Это тоже важно, но не исключительно.
@Peter, я согласен с тобой, но только для более сложных упражнений. Никому не нужен Интернет для решения FizzBuzz или других тривиальных упражнений, но вы не хотите потерять хорошего программиста только потому, что он не может вспомнить какой-то непонятный синтаксис, который они использовали один раз и никогда больше, и который можно найти в Интернете в пять секунд. Поиск в Google — это такой же навык разработки, как и само программирование — я знаю людей, которые совершенно не умеют это делать. Они часами ищут то, что можно найти за считанные минуты с правильными ключевыми словами.

Почему нет домашних тестов?

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

Если речь идет о старшей должности , старший разработчик с навыками работы с людьми сможет менее чем за 10 минут сказать, хорош ли старший разработчик на другом конце телефона или просто придумывает. Мы не будем точно знать, насколько хорошо, но мы будем знать столько же, если не больше, чем говорит нам каждый мыслимый домашний тест на кодирование.

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

Как проверить вместо этого?

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

После того, как они прошли фильтры, вам нужно больше узнать о способностях ваших кандидатов к кодированию. Я рекомендую потратить от 30 минут до максимум 2 часов либо на парное программирование, либо на проверку кода — реальная работа, а не упражнение. Повторить 1-2 раза с разными партнерами. Преимущество парного программирования и проверки кода заключается в том, что у разработчика уже достаточно знаний, чтобы внести свой вклад.

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

Вы обманываете себя, если думаете, что кто-то может сказать в течение 10 минут, хорош ли человек на другом конце провода.
Энтузиазм и желание учиться? Как насчет существующих знаний или способности учиться?
@djechlin Приятно иметь, но не так важно для юниора. Конечно, если они заявляют, что с энтузиазмом относятся к программированию и хотят учиться, но ничего не знают, то я бы поставил под сомнение их энтузиазм. Мне повезло, что я никогда не встречал никого, кто хотел бы, но не мог учиться.
лол, так что ваш критерий работает, потому что вы адаптируете его, чтобы он означал все, что вам нужно, когда вы видите кандидата, который вам нравится или нет. Почему бы просто не сказать "есть искра" или "не хватает искры", это проще.
Кроме того, преподавая продвинутый курс математики, я определенно встречал желающих, но не способных.
@djechlin Вы правы. Скорректировано в том числе "талант".
@Dunk Я не согласен. Мне потребовалось бы 10 минут, чтобы решить, есть ли у них «ЧТО-ТО хорошее». Но потребовалось бы намного больше времени, чтобы убедиться, что они «достаточно хороши». Смысл проведения «раундов» собеседований заключается в постепенном отсеивании кандидатов. Что сделал ОП, так это создал эквивалент «поиска достоинства».
Честно говоря, многие джуниоры, с которыми мы беседовали, прошли 1 или 2 технических стажировки, поэтому мы их тестируем. Если вы новичок и никогда не использовали MVC-фреймворк или не создавали программу, в которой выполняли интеграцию с API, то я не уверен, что хочу их использовать. Время и затраты, необходимые для обучения кого-то с нуля, не делают затею стоящей.
+1000 за часть "10 минут разговора по телефону со старшим разработчиком". Если вы хотите знать, знает ли разработчик свое дело, свяжите его с другим разработчиком, мнению которого вы доверяете, и он разберется во всем быстрее любого теста. Короткие личные тесты — это хорошо, если вы настаиваете (но далеко не обязательно), но гораздо более надежный метод отсеивания плохих кандидатов — реальное взаимодействие с ними коллеги.
Мне пришлось пролистать слишком далеко, чтобы найти это!
Что ж, Арон, если бы вы действительно могли отсеять «хороших» людей за 10 минут, то вы как разработчик тратите впустую свое время. Компании будут платить очень, очень большие деньги людям, которые не могут накормить их ничем, кроме хороших разработчиков. Черт возьми, если бы вы действительно хотели продолжать заниматься разработкой, вы, вероятно, все еще зарабатывали бы состояние, проверяя разработчиков один день в неделю, и у вас было бы достаточно денег, чтобы финансировать собственную компанию по разработке и делать то, что вам интересно. Тем более, что ваша компания будет нанимать только «хороших» разработчиков.
Относительно: «Не упражнение, основанное на реальном коде, а реальная реальная работа», это требует некоторых предостережений/объяснений. Во многих странах у вас могут возникнуть проблемы с законом, если в процессе собеседования кандидаты будут выполнять реальную работу, которая, возможно, может принести пользу вашей компании без оплаты. Не имеет значения, считаете ли вы сумму слишком тривиальной или вы не будете использовать этот код-ревью — это реальная работа, и многие законы требуют, чтобы кандидатам платили (или даже считали нанятыми, хотя и временно, в этот момент). .
У меня есть 10 лет опыта, и мне прислали тест на роль по контракту, который занял бы у меня 2-3 дня, чтобы пройти его должным образом, разумеется, я усмехнулся и отказался.
Вы можете не определить (очень) хорошие за 10 минут, но вы должны быть в состоянии определить (очень) плохие.

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

  1. Во время технического собеседования они усадили меня за компьютер, на котором была урезанная версия их кодовой базы, и дали мне решить три относительно короткие задачи, связанные с ней (найти и исправить ошибку, которую они специально добавили, добавить новое поле в информационная таблица и др.). Мне дали ровно час на это, и через час они рассмотрели мое решение, а также то, как я подошел к проблемам. Это дало им больше информации обо мне как о программисте, уважая при этом мое время, делая его кратким и точным.
  2. Во время технического собеседования они попросили меня решить проблему, с которой они столкнулись во время разработки на доске, при этом имея возможность поделиться с ними идеями. Это был самый короткий вариант, но он все же дал им возможность увидеть, как я справляюсь с проблемами и насколько я действительно могу выполнять необходимую работу.
  3. Во время технического собеседования (на должность младшего специалиста по веб-разработке Ruby on Rails) мне поручили создать с нуля веб-приложение, которое будет переходить на веб-сайт, заполнять несколько форм по мере их представления, собирать данные с итоговой страницы и представлять что пользователю. Они сказали, что это должно быть быстрым упражнением, и, возможно, это было для веб-разработчика старшего уровня, но, имея на тот момент всего год профессионального опыта, я потратил четыре часа, пытаясь заставить все это работать, прежде чем сдаться и уйти. домой (все интервьюеры ушли за несколько часов до меня, потому что это было дневное собеседование, они сказали, что я должен просто сохранить готовую программу, когда закончу). Это нелепое задание для указанной должности, оно не дало им представления о моих способностях к кодированию, и мне показалось, что они просто пытались получить бесплатную работу от сделки. Излишне говорить, что к тому времени, когда я ушел в тот день, я даже не хотел эту работу.
  4. Еще до технического собеседования они дали мне задание создать веб-приложение, которое использовало бы преимущества API, используемого их компанией, чтобы «делать что-то интересное». Это было именно так широко, как это звучит. Это потребовало от меня сделать следующее, прежде чем даже пытаться создать приложение: создать учетную запись разработчика для API, загрузить комплект разработки API, создать общедоступное веб-приложение (с другой учетной записью разработчика), изучить API и создать данные. репозиторий для доступа с помощью API. Это, конечно, заняло много часов только для того, чтобы начать работу, и вскоре после начала работы над самим веб-приложением я получил другое собеседование и вскоре после этого предложение о работе, поэтому я прекратил работу над заданием.

Итак, чтобы более точно ответить на ваш вопрос, должны ли вы провести упражнение по программированию? Да, но убедитесь, что он предназначен для проверки того, что вас действительно волнует, и не требует от интервьюируемого тонны посторонней работы. Хотите узнать об их алгоритмическом мышлении? Дайте им задачу алгоритма. Хотите узнать об их стиле кодирования? Задайте им задачу по кодированию. Хотите узнать об их процессе разработки? Обсудите с ними их процесс, пока они решают проблему.

интервьюеры сдались и пошли домой?! ФФС, ты все равно не хотел там работать. Я бы ушел через 2 минуты после них.
Они не столько сдались, сколько просто пошли домой с работы. Как только они дали мне задание, они просто оставили меня наедине с проблемой, и, поскольку это было дневное собеседование, и я работал над проблемой целых четыре часа, в итоге они пошли домой. К тому времени, когда я ушел, пара сотрудников все еще была там, и я понял, что пора сдаваться, когда эти ребята заказали ужин в офис.

Позвольте мне начать с:

  • Мне дали тесты для выполнения дома, которые варьировались от 15 минут до 10 часов.
  • Мне дали пройти онлайн-тесты.
  • Мне поручили написать ответ на FizzBuzz и другие модные интернет-тесты на доске.
  • Меня спрашивали о квадратных и круглых крышках люков.

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

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

Найти кого-то, кто может написать немного кода или поискать в Google, как применить конкретный шаблон, тривиально по сравнению с поиском кого-то, кто был в бизнесе, которым вы занимаетесь, и может использовать эти знания. Другими словами, если бы я нанимал компанию, занимающуюся ипотечной документацией, я бы предпочел кого-то, кто мог бы рассказать о разнице между 15-летним фиксированным кредитом и кредитом ARM, а не того, кто мог бы написать алгоритм пузырьковой сортировки за 2 минуты. Причина в том, что «нормальные» деловые люди выдвигают всевозможные странные требования, а экспертам в предметной области легче добраться до сути того, что нужно, в то время как кто-то, кто ничего не знает, с радостью добавит бесполезные вещи или сделает приложение действительно плохим.

Возвращаясь к вопросам, задавайте только разрешенные/недопустимые вопросы .

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

Важно ли определить, когда запрос открыт для инъекции sql? Для позиции Sr - абсолютно; для младшей позиции нет. Это то, что легко обучается и обрабатывается с помощью проверки кода. Следовательно, причина, по которой вы хотите, чтобы sr. знать его вдоль и поперек - чтобы они могли тренировать юниоров.

Критично ли им знать точное максимальное значение типа Int32данных? Обычно нет - для этого уровня тривиальных знаний и нужен Google; но, возможно, вам требуется кодирование на устройствах с ограниченной памятью - в этом случае: абсолютно.

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

Что я делаю, чтобы брать интервью у людей:

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

  • Я задаю им несколько конкретных вопросов по технологии, которую мне нужно, чтобы они использовали. Если это SQL-сервер, я спрошу об обновлении при соединении. Если это HTML, я передам им 10-строчный html-файл с парой классов CSS и спрошу, что получится на выходе. Это тривиальные вопросы к людям с опытом в этих областях, и они быстро отсеивают претендентов.

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

  • Если я ищу младшего разработчика, я спрошу о домашних проектах. все, что я хочу знать, это тип используемой технологии. Это должно подсказать вам, что они действительно хотят сделать. Другими словами, разработчик C# вряд ли будет заниматься любимыми проектами на php. Честно говоря, я не ожидаю слишком многого от младшего разработчика, кроме как обучаемости. Если они активно работают над любимым проектом, я могу их обучить. Если они из тех, кто нуждается в людях, чтобы сказать им, что делать, есть гораздо более крупные компании, в которых эти ребята могут работать.

Я не придумываю эти вопросы на лету, возможные ответы рассматриваются заранее и соответствуют шаблону «да/нет». Если вопрос не подходит, то он не актуален. Я также спрашиваю каждого кандидата об одном и том же, если я не уверен на 100%, что не нанимаю их, и в этот момент я прекращаю собеседование.

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

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

Спасибо за ваш ответ, хороший ответ. У нас аналогичный подход, но без домашнего теста.
Хороший разработчик может получить знания в предметной области лучше, чем хороший эксперт в предметной области может научиться хорошо программировать. Вы излишне сужаете свой кадровый резерв, и ваша компания от этого пострадает.
@DavidThornley: У нас с вами, вероятно, разные определения отличного, хорошего и посредственного разработчика. В моем мире отличный разработчик будет задавать правильные вопросы и быстро приобретать знания в предметной области. Хороший разработчик может в целом хорошо выполнять то, что ему говорят, но не задавать разумных вопросов по этому поводу. Посредственный вообще не задает вопросов и часто переделывает свою работу больше, чем обычно. К сожалению, найти отличного разработчика гораздо сложнее, чем найти хорошего, который уже знает предметную область.
"точное максимальное значение типа данных Int32"... ммм, это же INT_MAX, не так ли?

С точки зрения человека, ищущего работу, я обычно избегаю мест, кодирование которых занимает более 1 часа. Однажды я пошел в это место, которое потребовало почти 3-дневного проекта java-кодирования. Я сделал все это, и парень был даже впечатлен, но они сказали мне, что наняли кого-то другого после второго этапа собеседования. Поэтому после этого, если бы я пришел в компанию, я бы проигнорировал/пропустил бы любой проект, на выполнение которого требуется больше пары часов. Мое время так же ценно, как и их, и я предпочитаю не тратить его на вещи, которые никуда меня не приведут.

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

Сильное резюме, рекомендации и возможность выполнить короткий тест — это все, что вам нужно. Держитесь своего оружия и удачи в поиске работы.
Amazon связался со мной несколько лет назад и попросил пройти 3-часовой тест с 3 разными головоломками, чтобы выяснить И код. Я потушил все 3, но только один закончил к моему удовольствию. Это было довольно весело, но отсутствие какой-либо обратной связи очень разочаровывало. Год спустя у меня было еще одно интервью с ними по кодированию, но на этот раз член команды придумал головоломку, и мы написали ее вместе. Я не получил работу, но за эти 90 минут парного программирования я узнал столько же, сколько за половину семестра традиционного школьного обучения.
Единственный раз, когда у меня возникла проблема с программированием «на дом», компания так и не ответила после того, как я представил свое решение. Я связался с ними через неделю, и менеджер сказал, что получил его, но еще не успел просмотреть. Они так и не перезвонили, и я тоже.
«парень был даже впечатлен этим, но они сказали мне, что наняли кого-то еще». Но не настолько впечатлены, чтобы нанять вас? Они сказали вам, почему?
@DaveisNotThatGuy Это похоже на тест ОП. Тест был дан только для того, чтобы получить личное интервью; это не используется, чтобы нанять их, а скорее просто убедиться, что они хорошо осведомлены, прежде чем они рассмотрят их. Они были впечатлены тем, что я выполнил задание и получил правильные результаты. Думаю, их просто не впечатлило мое интервью.
Так что, даже если позже они признали вас хорошим программистом, они знали еще до того, как вы ушли с первоначального собеседования, что вы относитесь к категории ненанятых. Как вы могли бы провести тест по кодированию по-другому, чтобы компенсировать это и перейти в следующий раунд? Вряд ли это кажется вам справедливым.

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

Что вы вообще тестируете?

Тест на доске или краткий тест по программированию дают вам некоторое представление о человеке, но на самом деле не так много. Если только вы не планируете, что кто-то будет тратить свое время на написание кода на доске или в стиле FizzBuzz.

Чего ты хочешь ?

Вам нужен кто-то, кто:

  • страстный
  • желающий обучаться
  • умеет решать проблемы*
  • разумно техничный
  • поможет вашей команде улучшить

* Обратите внимание, что большинство разработчиков решают свои проблемы, зная, какие термины искать в Google.

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

Как вы можете проверить их?

  • Спросите их о проекте, который им понравился. Если кажется, что они не хотят говорить об этом, попробуйте выразить мягкое недоверие, например: «Ты не можешь сделать X, не так ли?» Если это то, чем они увлечены, они поправят вас. Это также поможет вам узнать, являются ли они техническими или нет.
  • Спросите их о вещах, которые они недавно узнали. Или то, что они узнали из проекта, над которым работали.
  • Спросите их о том, когда в последний раз (или когда) им не хватало знаний. Как они получали необходимую им информацию? Они ушли к товарищу по команде? Они искали в Интернете?
  • Спросите их, есть ли что-то, что они хотели бы улучшить в своей текущей/последней команде. Нужны ли им более качественные сообщения о коммитах? Больше обзоров кода? Больше испытаний? Больше автоматизации?
  • Спросите их, какие технологии их волнуют и почему.

Если у вас есть кто-то, кто технически компетентен в этом разговоре, будет проще всего сказать, будет ли этот человек худшим. Пример: к нам пришел парень и взял интервью — он сказал, что по шкале от 1 до 10 его навыки Java были примерно на 7-8. Я не думаю, что он даже знал, что Java была скомпилирована в файл jar, который позже был скомпилирован в машинный язык с помощью JVM. Я бы поставил себе, может быть, 2 или 3, и я знаю это.

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

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

Того парня не взяли на работу.

Выясните, какие атрибуты вы ищете, а затем выясните, как их тестировать .

Но мне действительно нужно увидеть, как она кодирует!

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

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

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

Вы поднимаете несколько хороших моментов, но недостатком фразы «лучше всего будет нанять ее в качестве подрядчика для небольшого, четко определенного проекта» является то, что большинство кандидатов предпочтут предложение на полный рабочий день, а не найм по контракту. Если у них есть несколько предложений, они выберут более «безопасный» вариант.
@RQDQ согласился. Я думаю, что это наименее эффективный способ проведения собеседований... но это наиболее эффективная форма проведения собеседований с кодом.
Старый принцип «попробуй, прежде чем купить». Хотя вся индустрия идет по этому пути, и моя следующая должность, скорее всего, будет заключаться в найме на 3-6 месяцев, меня огорчает заключенный в ней страх. Когда мы перестали делать домашнее задание и когда мы стали бояться кого-то уволить?
@JoshuaDrake безработица, вот тогда ;)

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

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

Кто-нибудь действительно провалил FizzBuzz?
@PatriciaShanahan: Да, вы всегда будете удивлены диапазоном качества. Побочным эффектом востребованности разработчиков является то, что многие люди хотят попробовать себя в качестве одного из них, даже если они не совсем готовы или недостаточно хороши, они могут убедить себя, что могут учиться на работе. Приличный краткий технический тест действительно помогает предотвратить случайный найм кого-то, кто может говорить, но не работает на практике, и такая ситуация достаточно распространена, и вам нужна какая -то техника собеседования, чтобы отфильтровать их.
Полезность FizzBuzz обсуждается в Programmers SE: Programmers.stackexchange.com/questions/15623/fizzbuzz-really .
Это сработало очень хорошо для нас. Во время хорошего собеседования вся команда оказывается у доски, разрабатывая решение вместе с кандидатом. знак равно
@NeilSlater - FizzBuzz был великолепен, когда только вышел. Пять лет назад, когда состоялось это обсуждение, он все еще был хорошим дискриминатором. Сейчас не так здорово. Одна вещь, в которой американское образование преуспело, — это обучение детей тому, как преуспевать в стандартизированном тесте. FizzBuzz (вместе с чем-либо подобным ему) теперь опустился до статуса стандартизированного теста.
@DavidHammen: Интересно. Однако вы можете просто переопределить «тест FizzBuzz», чтобы он означал «любую простую задачу по программированию, похожую на FizzBuzz». Придумать подобную проблему не составит труда.
@PatriciaShanahan Я прошла 2 собеседования на своей нынешней должности. Успех FizzBuzz равен 0/2.
@NeilSlater Теперь многие люди знают о FizzBuzz. Обратите внимание, что я сказал: «Классический пример…». Я не имел в виду, что FizzBuzz — это окончательный вариант теста на интерактивной доске, однако общая идея остается прежней. Дайте кандидату решить тривиальную задачу и посмотрите, как он ее решит.
@NeilSlater Я бы согласился, ЕСЛИ мы все еще не видим, как кандидаты проваливают FizzBuzz. Тем не менее, мы не делаем FizzBuzz изолированно, если они просто пишут базовую реализацию без ошибок и обсуждений, мы просим их реализовать ее по-другому. Последующие действия, как правило, показывают тех, кто понимает, что на самом деле происходит, а не тех, кто запомнил данную реализацию. Последующие действия также проверяют некоторые навыки человеческого взаимодействия.
@PatriciaShanahan: Я совершенно уверен, что они не ошибаются в понимании FizzBuzz, но понимают требования. Например, печать как числа, так и текста (например, 1, 2, 3Fizz, 4, ...), когда требования требуют печатать только текст (например, 1, 2, Fizz, 4). Или, если они более строгие (хе-хе), недостаточно добавить отдельные Fizz и Buzz для создания FizzBuzz, вместо этого вы должны использовать третью строку «FizzBuzz», например, по модулю 15.
FizzBuzz, если бы меня спросили об этом на собеседовании, я бы воспользовался этим как возможностью отсеять плохих интервьюеров. Он проверяет одну вещь: «Знаете ли вы, что такое оператор по модулю». То, что я редко использую в рабочем коде. Какая пустая трата времени.
@AdrianThompsonPhillips Это было мое первоначальное впечатление, пока я не увидел людей с 10-летним опытом, не знающих разницы между оператором присваивания и оператором равенства, или не знающих, как написать цикл и т. д. К сожалению, есть некоторые очень недооцененные квалифицированных и неудовлетворительных кандидатов.
@silencedmessage Я полностью согласен, задавать вопросы об этих вещах было бы намного лучше, чем неясные исторические вопросы о связанном списке, по модулю, сдвиге битов и обмене значениями между двумя регистрами.

НЕ ИЗБАВЛЯЙТЕСЬ ОТ ТЕСТА КОДИРОВАНИЯ!!!!

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

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

Это действительно зависит от наличия людей, которые могут интерпретировать результаты тестов/наблюдений. Вы можете нанять третью сторону для проведения этого скрининга, если вы не знаете, как это сделать. Просто получить правильный ответ — это только полдела. Разработчикам нужны навыки поиска в Google, но это еще не все. Если один программист может сделать тест быстрее, это плюс.

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

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

Ваша задача — убедиться, что вы не наняли плохого программиста и не должным образом оценивать всех, кто подает заявку. Ошибки будут. Хеджируйте свою ставку и не делайте худшую.
Именно по этой причине мы его представили: слишком много разработчиков-ковбоев, у которых в резюме есть миллион языков, но, когда дело доходит до этого, они не могут кодировать. Это также самая высокооплачиваемая должность в компании, поэтому мы не можем позволить себе рисковать с плохим наймом... с другой стороны, это несколько раз спасало нашу задницу, пару парней, которых я подозревал, были слабыми. кандидаты по телефону после технического собеседования отозвали свое заявление о приеме на работу в последнюю минуту, как только я представил тест на кодирование во втором туре. Мне пришло в голову просто провести техническое телефонное интервью.
@ bobo2000 - вам действительно нужно сопоставить продолжительность теста с наличием талантов в вашем районе. К сожалению, если это рынок программистов, вам, возможно, придется пойти на уступки. В качестве своего рода теста «A/B» вы можете случайным образом выбрать нескольких кандидатов, чтобы дать более короткую версию теста и посмотреть, проявят ли они больший интерес.
@bobo2000 Я чего-то не понимаю: в других комментариях вы говорите, что у вас в основном свежие выпускники в качестве соискателей, а здесь вы говорите, что ищете самую высокооплачиваемую должность в компании. Что-то особо не сходится. Можете ли вы объяснить, как эти два факта сочетаются друг с другом?
Тест на кодирование — это одно. Тест по кодированию, который занимает более 8 часов, — это совсем другое.
@bobo2000 «Некоторым кандидатам ( в основном выпускникам ) я даю задание по программированию» + «Это также самая высокооплачиваемая должность в компании» = здесь что-то не сходится.
Я чувствую, что «свежие» выпускники больше не верят обещаниям романтики и богатства от слабо финансируемого стартапа. Хорошо для них! Я сделал это дважды в прошлом пузыре, и ни один из этих дампов больше не существует.
@RaduMurzea: В мире стартапов программисты, даже программисты, только что окончившие колледж, как правило, являются самыми высокооплачиваемыми людьми, за ними следуют продавцы, а затем генеральный директор / основатели. Через пару лет вы, как правило, обнаружите, что зарплаты менеджеров увеличиваются, поскольку они больше не считают слишком рискованным тратить немного больше, чем реинвестировать. Примерно через пять лет вы обнаружите, что продавцы зарабатывают больше, чем программисты, если компания хорошо зарабатывает. Но вначале основатели обычно тратят много денег на то, чтобы найти лучших программистов, которых они могут себе позволить.
@slebetman - как он сказал. Для стартапа с ограниченными ресурсами предотвращение найма плохого кодера является ключом к росту, поскольку они создают продукт.
если вы полагаетесь на свежих выпускников, чтобы построить свой бизнес, у вас есть проблема.
@sevenseacat, если честно, большинство небольших компаний не могут позволить себе старшего разработчика. Хороший старший разработчик будет стоить в районе 50-100 тысяч, а средний уровень — в диапазоне 40-50. Если стартап находится в периоде роста, как у нас, то вы ограничены юниорами. Хитрость заключается в том, чтобы найти того, кто уже многому научился на стажировках. Они, вероятно, перейдут через год или два (после получения стартового опыта), но к тому времени, надеюсь, у них будет больше ресурсов. Я также очень серьезно отношусь к тренировкам здесь.
@DaveisNotThatGuy Я работал во многих в качестве бывшего разработчика и согласен с вами. Проблема многих в том, что они берут на работу младших и не вкладывают средства в их обучение, скорее, они ожидают, что они будут программировать как сеньоры. Теперь, когда я управляю, у меня есть шанс поступить по-другому, при условии, что у них есть хорошая база для работы.
Спросите себя, действительно ли вы сможете обучить младшего разработчика? Вы имеете право тренировать юниоров? У тебя есть время? У вас есть другие, опытные разработчики, чтобы сделать это? Какой у тебя план тренировок? Каковы ваши ожидания относительно прогресса? Есть ли у вас опубликованные стандарты для создания вашего кода, по которым вы можете оценить новичка? У большинства стартапов нет ни того, ни другого. Если вы не можете ответить ни на один из этих вопросов, не нанимайте новичка. Вы и он пожалеете об этом.
вот почему я избегаю стартапов, как чумы, в этом нет смысла. «Наймите кого-нибудь, кто, скорее всего, не будет хорошо выполнять свою работу, но он будет дешевым, так что вам придется потратить гораздо больше денег, чтобы потом за ним убирать».
Не зовите меня на выходные на собеседование. Я резервирую свои выходные для других дел, кроме работы (конечно, если не считать критических моментов). Если стоит устроить мне контролируемый тест по программированию, то стоит проводить его в обычное время.

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

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

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

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

Спасибо за это, что мне делать, если кандидат находится в другой стране и не может приехать на место, чтобы выполнить задание? Завтра я беру интервью у кандидата, который находится в Гонконге, а мы в Великобритании. После личного собеседования мы ожидаем, что кандидаты решат, хотят ли они работать у нас.
Вы должны скорректировать интервью в соответствии с обстоятельствами. Тем не менее, вы должны продать работу кандидату, а не просто бросать ему тесты. Более того, весь процесс — это упражнение в укреплении доверия между вами двумя. Вы хотите, чтобы ваш кандидат точно знал, во что он ввязывается; если требуется международный переезд, вы можете потратить немного больше времени на то, чтобы узнать больше друг о друге.
Используйте демонстрацию экрана, если кто-то не может посетить вас лично.
@user70848 user70848 Суть задачи по программированию состоит в том, чтобы убедиться, что кандидат может справиться с задачей программирования. Демонстрация экрана — ужасный способ сделать это, потому что вам пришлось бы потратить час, наблюдая за кандидатом, и они, несомненно, чувствовали бы себя более неловко, чем если бы они делали это по-настоящему. С другой стороны, если работа требует парного программирования, то это был бы хороший способ сделать это удаленно.
@koan Это правда, но если вы находитесь буквально за полмира от кого-то, это гораздо более дешевое и простое решение, которое поможет обеим сторонам принять решение о том, стоит ли вкладывать больше времени и энергии. Это не значит, что у вас не может быть другой задачи по программированию, если и когда вы снова встретитесь лично.

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

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

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

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

Вы хотите нанять программистов , которые не умеют программировать ?

Рискну предположить, что вы этого не сделаете.

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

Готовы ли вы снизить свои стандарты, потому что все пытаются нанять программистов?

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

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

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

Является ли отпугивание кандидатов проблемой?

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

Хорошо отпугивать этих кандидатов. Вы хотите нанять способных, мотивированных кандидатов. Пока вы не отпугиваете и их, все в порядке.

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

Как я могу улучшить наш процесс найма?

Проверьте содержание вашего упражнения по программированию. Является ли это разумным и подходящим для контекста интервью?

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

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

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

Было бы лучше, если бы вы могли запустить упражнение через веб-портал, на котором кандидаты могут зарегистрироваться и начать упражнение, и как только они начнут, таймер начнет обратный отсчет с 1 часа. Затем они либо представляют что-то в течение этого часа, либо нет. Это менее открыто, лучше удерживает внимание кандидата и обеспечивает четкие крайние сроки / временные рамки, так что 1) вам не придется ждать всю неделю результата, который никогда не будет получен, и 2) неквалифицированные кандидаты не выбросить неделю своего времени, пытаясь выполнить ваше упражнение по программированию. У них есть 1 час, они либо решают проблему, либо нет, и вы сразу знаете результат.

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

Нижняя линия

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

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

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

Вакансий больше, чем людей, любой технический руководитель может потратить несколько минут на чтение чьего-то кода на github и отказаться от необходимости выполнять глупые домашние задания по созданию простого приложения с пользовательским интерфейсом бесплатно для использования JSON.
Вы говорите: «На самом деле не настолько заботитесь о своей компании, чтобы выполнить простое упражнение по программированию»: большинство компаний полностью взаимозаменяемы — они не спасают и не разрушают мир. Почему кто-то должен заботиться о них, прежде чем устанавливать отношения с компанией и ее сотрудниками? Не ищите заботы, ищите лучший способ определить способности.
Вы не хотите снижать свои стандарты, потому что это горячий рынок для программистов. Вы действительно хотите, чтобы им было легко подать заявку и избежать дополнительных препятствий, потому что на горячем рынке хорошие люди будут обращаться в компании, в которые легко подать заявку. Вы можете нанимать людей, которые не могут найти хорошую работу в другом месте.

В качестве прямого ответа на ответ Бобо (который является принятым ответом, потому что парень написал его и сам принял, что, честно говоря, мне кажется немного жалким):

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

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

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

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

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

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

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

Что вы хотите делать, так это находить доказуемо интересных кандидатов. Поищите в StackOverflow и GitHub лучших инженеров (я слышал , что в StackOverflow есть инструмент, который помогает в этом ), найдите технически интересные компании, которые производили хорошее программное обеспечение, но облажались с финансами или монетизацией и только что уволили 10 высококлассных инженеров. Проведите время, работая в университетах, помогая с проектами последнего года обучения. Определите хороших потенциальных кандидатов и подружитесь с ними, желательно лично или удаленно; даже если у них есть предложения, хорошие инженеры общаются с хорошими инженерами. Кроме того, они могут рассказать вам, как они относятся к процессу найма.

Это звучит как много работы? Это должно . Одна из причин, по которой найм кажется таким «трудным», заключается в том, что вы пытаетесь сделать это максимально эффективно. Чем больше времени, умственных способностей и ресурсов вы отводите на это, тем легче это получается. Не лучше ли потратить эти ресурсы на доставку продукта — это вечный вопрос руководства. Но если вы тратите много времени на «фильтрацию дерьмовых программистов», это сжигание денег. По крайней мере, шаги, описанные выше, имеют неотъемлемую ценность, выходящую за рамки процесса найма.

(*): Черт, найми их .

Да, это в настоящее время мой подход. Вы были бы удивлены количеством разработчиков, у которых нет общедоступных «репозиториев git»,
Хорошая точка зрения. Однако есть риск полагаться на опубликованный код — не все пишут код в свободное время (различные хобби, семейные обязанности и т. д.). Хотя многие люди предполагают, что «кодирование в свободное время» коррелирует с техническими способностями, мне не ясно, правда ли это. Я знаю хороших разработчиков, которые помимо работы занимаются разными вещами.
@sleske, это правда, я пишу код в свободное время (разработчик CS Major / бывший) и никогда не публикую свой код в общедоступных репозиториях. Но это, вероятно, часть проблемы, кандидат может легко пойти на собеседование и солгать о своих навыках, используя модные словечки.
@sleske Я согласен, поэтому «проверить репозитории git» — это небольшое утверждение в гораздо большем абзаце (и я фактически удалил его сейчас). Если вы ищете профессионального разработчика, который не публикует свою работу, обратите внимание на компанию, в которой он работал. Это хорошая компания? Это хорошо работает? Почему оставили? Над каким аспектом они работали? Есть много связанных данных, которые вы можете использовать, и они более полезны, чем ваши тесты; и если у них нет этих данных, то вы можете использовать тесты . Но если они это сделают, используйте его вместо тестов.
@bobo2000 Опубликованная работа выходит за рамки образцов github; см. мой комментарий выше.
Меня всегда забавляет, когда люди говорят, что обратились ко мне, потому что они поражены моими проектами на github/public, а потом они все равно хотят, чтобы я провел с ними 3 дня, беседуя с ними.
@grasshopper Видите ли, я вижу это с точки зрения «какой вы на самом деле хотите быть рядом», но они не должны спрашивать вас, знаете ли вы, что такое логическое значение.
@grasshopper хорошо сказано, сэр! Это так раздражает. Я чувствую себя плохо, когда они присылают домашнее задание и говорят им уйти, мое время более ценно.
@SuperUberDuper хорошая леди в моем случае.
@grasshopper Я уверен, что он хорош собой;)
Re «Поиск ведущих инженеров через Stack Overflow и GitHub» : Stack Overflow закрыл свою платформу для найма .

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

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

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

Затем я предоставил свое резюме и доступ к своему LinkedIn, но сразу же после этого меня попросили заполнить соответствующий опыт работы с датами и описаниями. Эта информация есть и в моем LinkedIn, и в моем резюме, было нелепо предоставлять одну и ту же информацию 3 раза. Я закрыл вкладку браузера. Через 5 минут я обращался в другую компанию, которая предлагала действительно классные преимущества, которых не было в первой. На самом деле я мог подать заявку в другую компанию с лучшими преимуществами быстрее, чем я смог бы прыгнуть через обручи, которые первая компания хотела от меня.

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

Примеры качественных преимуществ, которые я обычно вижу, предлагают технологические компании:

  1. Удаленная работа.
  2. Бесплатные компьютеры/мониторы в качестве бонуса при подписке.
  3. Компания участвует в уважаемых проектах с открытым исходным кодом.
  4. Возмещение расходов на профессиональное обучение и/или конференции.
  5. Комплексные обеды.
  6. Гибкий график.
  7. Возможность работать с новыми или незнакомыми технологиями.
  8. «Стартап-культура» — она же отсутствие политики/бюрократии.
  9. Собственный капитал компании.
  10. Узнаваемость имени: ваша компания или ваш продукт хорошо известны. Кандидатам нравится упоминать, где они работают, и слышать, как люди отвечают: «О, здорово! Мне нравится их продукция».
  11. Цели/видение благотворительной или революционной компании. Людям нравится писать код, который делает жизнь людей лучше.
  12. Плата выше среднего. Деньги покрывают множество организационных грехов.
  13. Ежегодная компания уезжает в прохладные места.

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

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

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

Альтернатива № 2. Они, вероятно, уже написали бесплатный код, который они покажут вам, если вы просто спросите. У большинства программистов есть код на Github, Bitbucket, сайтах вопросов и ответов, таких как Stack Overflow, или они могут предоставить вам некоторый код, который они еще не опубликовали.

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

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

В чем проблема вашего бизнеса?

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

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

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

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

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

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

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

  1. Сравните и сопоставьте Java и C (или любые другие языки, имеющие отношение к делу, указанные в резюме кандидата и т. д.)
  2. Какие функции, по вашему мнению, следует добавить в язык? (Или еще лучше, что вы думаете об этом конкретном предлагаемом/недавнем изменении языка?)

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

..или пиши шипучие сообщения.
Кстати, я могу ответить на оба этих вопроса на многих языках, на которых я не могу написать привет, мир.
Я нашел их полезными. Чрезвычайно сложно «пройти» их, если вы не можете сказать что-то умное о том, чем отличаются подходы между языками, чем отличается распределение памяти, чем отличаются примитивы параллелизма и т. хорошо подходит для обсуждения того же.
@Джеймс Согласен. И даже если они не могут написать hello world на Java, если они могут сравнить и сопоставить Java с другими языками, они, вероятно, будут более полезными, чем те, кто может написать hello world, но не может сравнить и сопоставить Java с другими языками.

ИМХО, вероятность того, что новый выпускник колледжа сможет написать сложный программный код на начальном уровне, составляет почти 0%. Если ваш тест по кодированию занимает одну неделю, вы должны четко указать в своем требовании, что вы ищете программистов с опытом работы не менее 2 лет, потому что я думаю, что для выполнения работы с кодом требуется большой опыт. неделя для завершения. И я думаю, что если вы ищете новых выпускников, то разработайте свой тест соответствующим образом, и вы можете найти много идей в Интернете, или вы можете попросить старших программистов, работающих на вас, разработать подходящий тест для новых выпускников.

Я бы лично не ожидал, что старший разработчик напишет подходящий тест, если только у него не было определенного опыта в том, что работает, а что нет во время собеседования. Очень легко сосредоточиться на том, что, как вы сами знаете, легко и очевидно, и трудно исправить это, что напрасно подведет кандидатов, которые не знают точно, что делает автор теста. Я думаю, что эта ситуация является одной из причин, по которой такие тесты, как FizzBuzz, стали популярными — кажется, что они работают на правильном уровне общих знаний, чтобы правильно фильтровать кандидатов.
@ Нил Слейтер: - Возможно, старший программист не знал, как разработать тест для кандидата на программирование начального уровня. Но не так сложно понять, чего ожидать от кандидата начального уровня. И когда моя предыдущая компания хотела нанять нового программиста, я знал, чего просить/ожидать от нового программиста, и я поступил соответственно, и мы наняли хорошего кандидата. Также во многих местах, где меня брали на собеседования по поводу работы программистом, меня брали на собеседования старшие программисты этой компании. Вот почему я предложил это, и это очень распространенная практика.
На самом деле занимает 30 минут, если вы разбираетесь в веб-разработке. Я даю им 1 неделю, так как я беру интервью у многих кандидатов в середине недели, и это дает им время пройти тест в течение периода времени, который соответствует их графику; личные обязательства, работа, учеба и т. д. Лично я бы предпочел, чтобы кандидаты сдавали тест быстрее, потому что это экономит мне время ожидания их. Я думаю о том, чтобы бросить это и просто заняться fizzbuzz, чтобы облегчить себе жизнь.

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

РЕЗУЛЬТАТЫ

Положительные стороны подхода

1) Домашний тест отсеивает демотивированных кандидатов и заменяет их кандидатами, которые действительно хотят работать на вас. Уже одно это делает его стоящим занятием, поскольку мотивированные люди = продуктивные сотрудники. Если они не удосуживаются выполнить одночасовое задание, то это многое говорит об их отношении к получению работы.

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

а) Некоторые кандидаты не заполняют его. Не стоит нанимать.

б) Некоторые кандидаты пытаются выполнить задание, но плохо его выполняют. Не стоит нанимать.

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

г) Некоторые кандидаты, услышав техническое задание, вдруг отзывают свою заявку, к которой раньше проявляли БОЛЬШОЙ интерес. Вероятно, увернулся от пули.

д) Некоторые кандидаты справляются очень хорошо, комментируют свой код и в одном или двух случаях предоставляют документацию. Стоит нанять.

Минусы подхода

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

2) Не всегда можно сказать, обманул ли кто-то, но именно поэтому это часто подкрепляется техническим интервью по телефону.

Результат этого подхода

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

Итак, вы построили всю свою стратегию найма на работе одного парня. Ух ты...
Почему именно я должен быть мотивирован делать бесплатную работу для вашей компании? Наймите меня, и вы найдете меня работающим, чтобы помочь компании. Потратив слишком много времени на подачу заявления, я найду другую работу и буду помогать их компании. Поймите, работодатели, что очень немногие люди заинтересованы в том, чтобы работать именно на вас, и что разработчики, которых вы хотите, могут найти работу, на которую легче подать заявку.
@DavidThornley, эта тема исчерпала себя. Речь идет об управлении рисками: если люди не удосуживаются выполнить 30-минутное упражнение по программированию, значит, они явно недостаточно мотивированы, чтобы хотеть играть роль. Кроме того, как упоминалось ранее, упражнения по кодированию более применимы к людям с непроверенным послужным списком; стажеры, выпускники, чем опытные сотрудники с большим опытом работы.
@ bobo2000 Вы, кажется, упускаете мою мысль. Предположим, я ищу работу. Я хочу работу. Скорее всего, я не заинтересован в том, чтобы работать конкретно на вас, но если меня наймут, я буду делать для вас хорошую работу. Чем больше времени я трачу, в частности, на процесс подачи заявления, тем меньше времени у меня остается на работу над моими общими шансами на получение хорошей работы. Должен ли я пройти ваш тест или подать заявку еще на две работы? Теперь, если бы это была центральная площадка для тестирования, которую использовали бы многие компании, это стоило бы моего времени.,
@DavidThornley, многие компании проводят тесты по программированию как часть процесса подачи заявок, и, судя по опыту, лучшими кандидатами, как правило, являются те, кто тратит время на их выполнение - и таких будет много.
@DavidThornley, чтобы добавить, вы можете подумать, что это несправедливый процесс найма, но стоимость замены непроверенного разработчика, который оказался плохим разработчиком, хвастающимся этим, намного дороже, чем просто не нанимать их в первую очередь.
@bobo2000o Справедливость — не главное в рекрутинге. Вы хотите, чтобы хорошие люди хорошо выслушали, чтобы принять решение, но реальная справедливость по отношению к кандидатам, как правило, даже не рассматривается. Я думаю, вы могли бы получить лучший кадровый резерв без взяток домой и проверить их базовую компетентность за полчаса или около того под наблюдением. Если вы не можете сказать, компетентен ли кто-то в принципе, вы все равно пропали. Это не имеет значения для людей, с которыми я тусуюсь. Мы получим работу. Это важно для вас.
@DavidThornley, каждый человек, которого я нанял, используя этот подход, оказался хорошим сотрудником, основываясь на практическом опыте этого. Напротив, если бы у меня никогда не было процесса технического скрининга, это было бы дорого для бизнеса.

Незнакомая мышь или необычная раскладка клавиатуры (особенно Mac по сравнению с ПК) или другая IDE могут резко снизить производительность без какой-либо разницы в компетенции. Кроме того, полное приложение часто требует большого количества шаблонного кода, который у разработчика может не хватить времени для ввода или даже для запоминания. Запуск нового приложения полностью с нуля на самом деле является очень редкой задачей; большая часть работы сосредоточена на расширении или улучшении существующего кода.

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

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

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

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

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

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

Я хотел изучить XMLreader и XMLwriter.

Сначала думал забыть. Но потом я увидел в этом шанс доказать, на что я способен. У меня нет степени CS, поэтому я скучаю по некоторым теоретическим материалам. Они спросили, каковы 3 столпа ООП, и хотели сказать, кого это волнует.

Мое сообщение: люди, которые хотят получить работу, должны пройти тест.

Что ты имеешь в виду под "хотел сказать, кого это волнует" ?
Это клиффхэнгер! Что произошло дальше? Вы получили работу? Узнали ли вы что-то, что позже применили? Подразумевают ли «3 столпа ООП» их не заботит результат задачи программирования? Что они сказали о выполненной задаче по программированию?
Задача по программированию отпугивает кандидатов, стоит ли от нее отказываться?
СпросиСетьПолитика конфиденциальности1y, 0v