Ужасы технического интервью

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

Традиционные технические интервью — кошмар для всех. Они неудобны компаниям для оценки кандидатов. Они неудобны соискателям для оценки компаний. Это трата времени и источник стресса для всех. Почти все (особенно если надавить) согласятся с этим. Но технические интервью всё ещё практикуются.

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

Не паникуйте. У меня есть альтернатива получше. Смотрите.

В прошлом месяце (февраль’15) Danny Crichton написал несколько отличных постов о технических интервью: их нужно прочитать (переводы появятся у нас на сайте в ближайшее время), но я выделю несколько основных моментов:

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

Он же, в свою очередь, был вдохновлён Thomas Ptacek:

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

Более того, и что наиболее анекдотично, у меня складывается впечатление — ситуация наконец-то начинает меняться. Всё больше компаний просят кандидатов сделать тестовый проект вместо живого интервью. Другие же становятся менее фанатичными в отсеве кандидатов на стадии интервью (но более жёсткими в практике увольнения после первых месяцев). Значительно помогло то, что глава HR департамента Google признал несколько лет назад: “Головоломки — пустая трата времени” и “результаты тестов бесполезны”.

И всё же. Я, может, и несколько преждевременно написал пару лет назад статью “Техническое интервью умерло”, но это не совсем так. На данный момент, во всяком случае. Оно умирает, но слишком уж медленно.

Мы, ненавистники, должны чётко обозначить свою позицию: есть причины, хотя некоторые из них и не достаточно веские, из-за которых компании упорствуют с живыми интервью, хотя они и знают, что интервью далеки от совершенства. И вот эти причины:

  • Интервью — процесс, который можно измерить и повторить (с точки зрения компании). Все понимают, как они работают — просто несколько вопросов, и несколько критериев для оценки ответов, и в результате почти любой работадатель может его провести.
  • Компании хотят отфильтровать очевидно неподходящих кандидатов на раннем этапе, и сложно бороться с чувством, что вы также можете сами задать парочку уточняющих вопросов… которые в итоге сведут всё к полностью традиционному интервью с массой технических тонкостей.
  • Есть такая штука, как талант, и вы хотите отфильтровать людей без достаточного его количества. Традиционные технические интервью служат скорее для выявления негативных черт, чем положительных. Так исторически сложилось, найм одного плохого инженера рассматривался как провал в найме двух хороших. Это была катастрофа. Но хорошие инженеры сейчас в большом дефиците, этот подход больше не работает.
  • Такая разумная альтернатива техническим интервью, как выполнение тестового задания, всё ещё не самый лучший выход. На самом деле, достаточно сложно вместить в небольшой проект и все важные вещи, и сделать так, чтобы это не заняло у кандидата больше дня или двух. В то же время кандидат хочет, чтобы это время ему оплачивалось, и/или аппелирует к тому, что у него уже есть работа и нет времени на выполнение спекулятивного проекта, который компании в то же время хотят в будущем использовать, как плагин или вообще передать его третьим лицам.
  • Вот почему личные рекомендации остаются всеми любимым способом найма…
  • …который, в свою очередь, является причиной очень незначительного числа членов IT индустрии.

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

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

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

Мне представляется примерно такой ход этой беседы:

  1. Интервьюер тратит полчаса-час на знакомство с проектом кандидата.
  2. Затем они тратят час или два на обсуждение вопросов архитектуры и реализации, альтернативных подходов, как можно было бы расширить функциональность, структурный и построчный анализ кода, окружения и конфигурации и т.д.
  3. Эти главные темы беседы фактически формализованы и могут использоваться от интервью к интервью. Кандидатов можно сравнить, а результаты можно измерить. Используют ли они глобальные переменные? Реализуется ли в коде MVC или какой-то другой паттерн? Разумно ли методы структурированы и инкапсулированы? Видно ли из пользовательского интерфейса понимание проблем юзабилити? Есть ли тесты? Ну и т.д. Наполовину обычный код ревью, наполовину проверка, насколько сам кандидат понимает свой код.
  4. Затем интервьюер просит кандидата при нём добавить незначительную возможность в проект.
  5. К этому моменту интервьюер должен быть полностью уверен или скептично настроен в отношении того, хорошо ли построен этот проект, и сделал ли кандидат его сам.
  6. Если предыдущий пункт успешно пройден, идём дальше. К согласованному времени, передайте кандидату ветку в тестовом проекте — это может быть какой-то постоянный проект или же свежий каждый месяц. (Построение нового — хороший проект для новичков.) Затем поставьте им задачу, на которую потребуется 4-8 часов работы. Тестовый проект должен быть небольшим, просто для проверки на вменяемость и давать уверенность, что кандидат может выполнять задачи в разумные сроки.
  7. Пусть пулл реквест проверит другой интервьюер, это даст вам взгляд с нескольких точек зрения.
  8. Или в качестве альтернативы (хотя и спорной) можно использовать парное программирование опять же с другим интервьюером на протяжении часа или двух.
  9. И наконец, можно принимать решение о найме.

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

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

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

Когда я четыре года назад впервые заикнулся о неэффективности и контрпродуктивности традиционных технических интервью, я написал: «Не интервьюируйте никого, кто не закончил что-то сам. Никогда. Сертификаты и учёные степени — не достижения; я имею в виду реальные проекты для реальных людей. Нет оправдания для разработчиков без сайта, приложения или сервиса, о котором они могут сказать «Я сделал это! Все сам!», в мире, где Google App Engine и Amazon Web Service предлагают бесплатную привязку, а зарегистрироваться Android разработчиком и начать публиковать свои приложения стоит $25.»

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

Перевод m.oh

Добавить комментарий