Насколько эффективны проблемы программирования в процессе подбора персонала? [закрыто]

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

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

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

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

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

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

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

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

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

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

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

Очень эффективный.

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

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

Скорее всего, бояться приехать к нам на ярмарку вакансий.

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

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

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

Удачи в этом.