Я даже не могу вспомнить все статьи о найме работников, которые прочитал за последние несколько лет. Все они выстроены по одному формату. В начале в них утверждается, что наём сотрудников никуда не годится. Затем описывается практика найма в компании XYZ. Потом следует исключительно подробный анализ того, в каких ситуациях эта практика полезна, а в каких приведет к плохим результатам. Наконец, они завершаются тем, что наём может быть проведен на основе критериев ABC, и это только для того, чтобы кто-то другой написал статью о том, что ABC — негодный способ найма сотрудников.
К сегодняшнему дню я видел уже почти все комбинации ABC и XYZ. В качестве небольшого упражнения, я решил сделать небольшую подборку их всех. Я уверен, что многие люди будут горячо защищать свои взгляды на то, как правильно и как неправильно нанимать сотрудников. Честно говоря, я уже потерял всякий интерес в выслушивании этих мнений и примеров из жизни. До тех пор, пока кто-нибудь не проведет тщательное исследование, оценивающее разные стратегии собеседований, предпочтительно с использованием двойной слепой случайной выборки, нет никакого смысла и дальше пришпоривать эту дохлую кобылу. Отбор персонала никуда не годится у всех. И у вас он ничем не лучше.
За:
За:
На этом оригинал заканчивается, хотя в немецком переводе есть продолжение:
Хороший вопрос. Когда я работал в гугле, мы полностью полагались на живое программирование, а отдел по персоналу дополнительно учитывал данные из резюме. Не так давно гугл начал задавать поведенческие вопросы, но этот процесс находится еще в самом начале.
Я думаю, что нет решения, которое бы подошло для всех соискателей. Разные люди демонстрируют свой опыт разными способами. Кто-то хорош в живом программировании, кто-то — в пробной работе, другие могут предоставить отличные рекомендации известных людей, заслуживающих доверия. Компании должны быть гибче и давать возможность кандидатам выбирать способ демонстрации своих умений.
Это, конечно, всего лишь мое личное мнение и мне ясно, что реализация такого подхода может быть нелегка. В ближайшие десятилетия в этой сфере наверняка произойдут серьезные изменения.
Об авторе.
Раджив Прабакар (сайт), получил степень мастера по электротехнике в Стэнфордском университете, после этого работал в Intel, Oracle, Google и Amazon.
К сегодняшнему дню я видел уже почти все комбинации ABC и XYZ. В качестве небольшого упражнения, я решил сделать небольшую подборку их всех. Я уверен, что многие люди будут горячо защищать свои взгляды на то, как правильно и как неправильно нанимать сотрудников. Честно говоря, я уже потерял всякий интерес в выслушивании этих мнений и примеров из жизни. До тех пор, пока кто-нибудь не проведет тщательное исследование, оценивающее разные стратегии собеседований, предпочтительно с использованием двойной слепой случайной выборки, нет никакого смысла и дальше пришпоривать эту дохлую кобылу. Отбор персонала никуда не годится у всех. И у вас он ничем не лучше.
Посмотреть, какой университет закончил кандидат
За:
- Приемные комиссии университетов тратят много усилий на отбор наиболее способных студентов. Почему бы не использовать их усилия на благо своей компании?
- В лучших университетах в целом работают лучшие профессоры, учатся лучшие студенты и более требовательные программы обучения, всё это неизбежно скажется на кандидате.
- Чтобы поступить в университет из верхних строчек рейтинга, нужно затратить много как физических, так и умственных усилий. Это может быть хорошими признаками успешного сотрудника.
Против:
- В каждом университете есть идиоты. Да-да, даже в Стэнфорде.
- Приемные комиссии отдают предпочтение богатым абитуриентам со связями. Награждая такое, вы дискриминируете кандидатов без денег, без связей и из низких социальных слоев.
- Навыки, необходимые для поступления в Стэнфорд в 17 лет (общественная деятельность вне учебы, тест SAT и пр.) не совпадают с навыками, необходимыми хорошему программисту.
- То, каким хорошим студентом ты был в 17, не сильно совпадает с тем, какой ты в 25.
Посмотреть на список компаний, в которых кандидат работал раньше
За:
- Перечитай все «за» в предыдущем пункте и замени Стэнфорд на Гугл. Компании еще лучше выявляют необходимые умения для программистов.
- Компании обычно еще лучше выявляют людей с подходящими навыками и опытом.
Против:
- Те компании используют никудышный процесс отбора. Следовательно, нельзя полагаться на него.
- Не годится для вчерашних выпускников.
- Вы создаете самоподдерживающийся круг, в котором тот, кого с первого раза отклонил гугл, никогда не получит второго шанса.
Посмотреть на средний балл
За:
- Средний балл — всесторонняя метрика, которая учитывает успехи на большом количестве разных курсов в течение четырех лет, покрывая также домашние, курсовые и экзаменационные работы.
- Хороший индикатор того, насколько индивид трудолюбив и настойчив.
- Неплохой индикатор того, насколько кандидат умен.
Против:
- У Эйнштейна был плохой средний балл, так что, очевидно, этот показатель совершенно негоден.
- Многие отличные программисты настолько увлечены своей страстью, что игнорируют все остальные курсы, а это негативно отражается на среднем балле.
- Для кандидатов с опытом средний балл давным-давно устарел.
- Оценка по экономике не имеет отношения к работе программистом.
Попросите у них рекомендации
За:
- Даст понимание их эффективности на рабочем месте.
Против:
- Люди назовут только тех, кто будет говорить о них только хорошее.
- Кто-нибудь даст отличную рекомендацию, только чтобы вдруг не получить судебный иск.
- Выделяет людей с превосходными социальными и межличностными качествами.
- Наказывает людей, которые в прошлом работали с плохими и несправедливыми руководителями.
Пораспрашивайте других людей, с которыми работал кандидат (back-channel references)
За:
- Даст более справедливое понимание эффективности кандидата.
Против:
- Из-за этого о вас начнут плохо думать.
- Людей, способных дать точные отзывы, тяжело искать.
- Дает преимущества кандидатам в превосходными социальными и межличностными качествами.
- Наказывает людей, которые в прошлом работали с плохими и несправедливыми руководителями.
Дать задание на дом
За:
- Эмулирует настоящую работу.
- Нет влияния стресса, связанный с обстановкой интервью.
- Дает возможность посмотреть и оценить реальный продукт, которые дает кандидат.
Против:
- Это бесплатная работа. О вас будут думать плохо.
- Требует много времени. Дискриминирует людей, у которых есть семьи и своя жизнь.
- Очень легко обмануть. Кандидат может обратиться за помощью. к друзьями. Или может потратить 30 часов на то, что нужно сделать за 10, только для того, чтобы добиться хорошего результата.
Пробная работа
За:
- Настоящая работа на рабочем месте.
- Возможность увидеть, с чем любит работать кандидат.
- Видно реальный результат работы.
Против:
- В зависимости от текущего рабочего договора (и иммиграционного статуса) это может быть нелегально.
- Вы просите кандидата взять день отпуска просто чтобы поработать на вас. Люди вас за это возненавидят.
- Дискриминирует людей, которыми интересуются много компаний. Они смогут поработать только на одном или двух местах.
- Дискриминирует людей, имеющих семьи и личную жизнь.
Попросить описать предыдущие проекты
За:
- Если кандидат в прошлом работал в сложных проектах, высока вероятность, что и в вашей компании он окажется успешным.
- Создание успешного продукта может быть индикатором таланта.
Против:
- Любой может приукрасить и преувеличить свою работу и показать ее в более впечатляющем свете, чем она была на самом деле.
- Работа в «крутом проекте» часто основана на том, что человек оказался в нужном месте в нужное время.
- Успех продукта часто является отражением таланта продакт-менеджера, а не разработчиков.
- Оценка очень субъективна. Отсеивает кандидатов, чьи интервьюеры были просто в плохом настроении. Отсеивает кандидатов, которые не очень красноречивы. Отсеивает кандидатов, которые не подходят под стереотип идеального разработчика.
Попросить исходный код значимых проектов
За:
- Настоящий результат работы, отличное отражение способностей кандидата.
Против:
- Большинство рабочих продуктов кофиденциальны. Гугл никогда не позволит вам показать ваш исходный код.
- Дискриминирует людей с семьями, не у всех есть время работать над проектом с открытым кодом.
- Не все заинтересеованы в трате своего личного времени на опен-сорс-проекты. Дискриминирует людей с многообразными интересами.
Поспрашивайте о знании разных технологий, инструментов и фреймворков
За:
- Если кандидат знает о технологии Х и как её использовать, то он сможет использовать Х для выполнения работы
- Показывает, что кандидат интересуется своей сферой
Против:
- Инструменты и технологии можно изучить, их нельзя использовать как фильтр.
- Фундаметальные знания не связаны со знанием специфичиных утилит, но они намного более важны.
- Существует слишком много вещей, чтобы один человек знал их все.
- Вы не хотите быть той компанией, которая нанимает за "коричневое" (прим. перев — по ссылке забавно).
Задачки на сообразительность (brain teasers)
За:
- Проверяет общий интеллект и умение решать проблемы.
Против:
- Или вы знаете решение, или нет. Зависит от того, насколько кандидату повезло именно в данный момент получить вспышку озарения, или же он встречал эту задачку раньше.
- Нет прямой связи с программированием.
- Даже гугл говорит, что они бесполезны.
Упражнения по живому написанию кода (Live Coding)
За:
- Непосредственные тестирование и демонстрация умений написания кода, к которому не относится большинство и «против» в пунктах выше.
- То, что FizzBuzz эффективен, показывает необходимость еще большего количество живого кодирования.
- Совершенно честно и непредвзято. Если ты решил проблемы, у тебя много очков. Если нет — мало. Вот такая меритократия.
Против:
- Многие задания подвержены тем же за/против, что и задачки на сообразительность: они зависят от озарения, и вам повезло, если оно к вам пришло в нужный момент.
- Много стресса. Многие программисты не могут работать в условиях стресса, когда за ними кто-то наблюдает, да еще и часы тикают.
- Не отражает практических задач. Задания искусственны и вычурны.
- Люди будут вас за это ненавидеть.
- «90% наших инженеров используют софт, который вы написали, но вы даже не можете инвертировать бинарное дерево на доске, так что валите отсюда».
Парное программирование над «реальной» задачей
За:
- Вы работаете над реальной задачей, которая напоминает ежедневные обязанности.
- Нет ответа «знаю, как правильно». Совместный поиск решения.
Против:
- Требуются недели, чтобы разработчик хорошо ознакомился с кодовой базой, приобрел знания в нужной сфере и технологиях. Ожидания, что кто-то заглянет после обеда и сразу начнет писать полезный код, не очень реалистичны.
- Крайне изменчиво. В зависимости от дня некоторые кандидаты могут получить легкий кусочек работы, использующий языки и технологии, с которыми они уже знакомы. А другие могут получить совершенно противоположный опыт.
- Чтобы оценить чей-то потенциал, нужно дать ему задачу, которая бы потребовала полной отдачи, независимо от её реалистичности. Не зря для тестирования процессоров используются синтетические бенчмарки, а не MS Word.
- Если вы даете каждому кандидату одинаковую «реальную» задачу, которая требует усилий, но не является невыполнимой, в закрытом окружении, требующей минимальных знаний предмета, свободную в выборе языка и технологии — поздрвляю, вы переизобрели живое программирование.
На этом оригинал заканчивается, хотя в немецком переводе есть продолжение:
Что же делать?
Хороший вопрос. Когда я работал в гугле, мы полностью полагались на живое программирование, а отдел по персоналу дополнительно учитывал данные из резюме. Не так давно гугл начал задавать поведенческие вопросы, но этот процесс находится еще в самом начале.
Я думаю, что нет решения, которое бы подошло для всех соискателей. Разные люди демонстрируют свой опыт разными способами. Кто-то хорош в живом программировании, кто-то — в пробной работе, другие могут предоставить отличные рекомендации известных людей, заслуживающих доверия. Компании должны быть гибче и давать возможность кандидатам выбирать способ демонстрации своих умений.
Это, конечно, всего лишь мое личное мнение и мне ясно, что реализация такого подхода может быть нелегка. В ближайшие десятилетия в этой сфере наверняка произойдут серьезные изменения.
Об авторе.
Раджив Прабакар (сайт), получил степень мастера по электротехнике в Стэнфордском университете, после этого работал в Intel, Oracle, Google и Amazon.