Ваш процесс собеседования - пустая трата времени...
Какова причина номер один, по которой вы нанимаете разработчиков?
Это написание кода?
Возможно, вы одна из тех компаний, которые проводят собеседования в стиле компьютерных ученых. Ваш процесс собеседования включает вопросы о нотации Big-Oh. Или вы спрашиваете людей о тонкостях определенного языка.
Если человек проходит собеседование, вы принимаете его на работу за его "технические способности". Но как только ваши новые сотрудники получат работу, они будут тратить свое время на создание пользовательских интерфейсов и CRUD API.
Мы живем в эпоху фреймворков и автоматически генерируемого кода. Мы тратим больше времени на настройку, чем на кодирование. Большинство из нас прокладывают свой путь через создание инфраструктуры с помощью кнопок.
Тем не менее, мы разрабатываем эзотерические, труднопроходимые интервью. Неподготовленные интервьюеры лижут свои зубы, надеясь поставить кандидатов в тупик.
Мы ждем, что люди проявят себя. Напишите код на доске, чтобы мы могли судить о вас. Мы смотрим в шпаргалку, пока кандидат борется с маркером на доске. Нам не терпится увидеть очередную версию последовательности Фибоначчи, пока пот стекает по их бровям.
Почему мы так поступаем?
Эго. Цель таких собеседований - удовлетворить эго интервьюера.
Это хорошо продуманная система, которая позволяет нам судить о человеке и синтаксисе. У нас в голове есть неофициальная система баллов. Если интервьюер задает вопрос, уменьшаем на один балл. Когда кандидат теряет достаточно баллов, мы его дисквалифицируем.
Это садистский процесс. Дисквалифицируем людей, но жалуемся, что слишком много работы. Рассуждайте о достоинствах культуры, но посылайте разработчиков программного обеспечения через перчатку. Допрашивайте их до тех пор, пока они не провалятся.
Все притворяются Google.
Тем временем, в условиях нехватки разработчиков программного обеспечения, проекты отстают. Клиенты страдают из-за продуктов с анемичными характеристиками. Инвесторы продолжают терпеть убытки.
Почему? Потому что мы разработали стратегии найма так, чтобы отсеивать, а не нанимать квалифицированных специалистов. Это отвлекает команды разработчиков программного обеспечения от главного - ценности бизнеса. Мы кормим свое эго, но морим голодом бизнес.
Вы концентрируетесь на технических вопросах, а не на выполнении работы
Я: Как прошло собеседование?
Интервьюер: Они справились с первой частью собеседования, но, похоже, замялись, когда я перешел к техническим вопросам.
Я: О чем вы их спросили?
Интервьюер: Если бы вам нужно было найти заданное целое число в отсортированном по кругу массиве целых чисел, как бы вы это сделали?
Я: Как, черт возьми, это связано с тем, чем мы здесь занимаемся?
Как и большинство интервьюеров, они гуглили трудные вопросы для собеседования и прокручивали их до тех пор, пока не нашли то, что можно всучить кандидату.
Затем мистер Эго просмотрел видеоролик на YouTube, в котором рассказывается, как решить проблему.
Как этот вопрос говорит нам что-либо о кандидате? Как мы можем узнать, способен ли потенциальный наемный сотрудник засучить рукава и выполнить поставленную задачу?
Самая большая проблема в индустрии разработки программного обеспечения - это несвоевременное выполнение проектов.
В 70% случаев вся отрасль выходит за рамки бюджета или сроков. И те инженеры, которые могут ответить на вышеупомянутый вопрос, не могут оценить, чтобы спасти свою жизнь.
Так что же нам делать?
Ищите опыт успешного выполнения поставленных задач. Проводите собеседование с инженерами на основе их резюме. Не ленитесь. Позвоните их рекомендателям и спросите их предыдущих коллег о количестве проектов, выполненных в срок.
Речь идет не о найме как таковом, а о рекрутинге. Ваша задача - проверить соответствие требованиям, культуру и систему ценностей.
Вы не обучили свою команду правильному проведению собеседований
Ваши лучшие инженеры - худшие интервьюеры, если вы их не обучите.
Часто мы ищем эзотерическую чушь, которая напоминает нам о старых добрых временах. Мы помним, как здорово было разбираться в сортировке слиянием. Многие из нас испытывают прилив дофамина, когда разгадывают алгоритм.
Мы мечтательно перелистываем страницы своих учебников. Мы хотим протестировать нового кандидата. Мы оцениваем их, а затем рассказываем о них своим коллегам.
И вот что самое интересное: мы не извлекаем никакой пользы из самых сложных технических вопросов.
Я вспоминаю, как один интервьюер сказал мне, что отказался от кандидата, потому что тот не упомянул Docker в качестве архитектурного решения. Другого он дисквалифицировал, потому что ему не понравился ответ кандидата о значении включения use strict в начало исходного файла JavaScript.
Глупый процесс собеседования, случайно разработанный Google
Вот что делает большинство людей, чтобы попасть в Google или подобные ей компании (так же поступал и я, когда проводил собеседования в компаниях, претендующих на роль Google).
Во-первых, я запомнил сложность каждого алгоритма сортировки. Я записал каждый из них тридцать семь раз ручкой, потому что где-то прочитал, что 37 - это какое-то магическое число для запоминания.
Затем я стряхнул пыль с учебников и писал эти алгоритмы до тех пор, пока не смог ошибиться. Я даже засекал время, когда писал merge-sort на нескольких языках.
Конечно, я просмотрел свою книгу по структурам данных. Я слышал, что Google неравнодушен к хэш-таблицам, поэтому я пропустил эти главы.
Но вот что я понял: Я проходил собеседование, но интервьюер "не знал, подхожу ли я ему".
Интервьюеры сосредоточились на том, чтобы получить конкретные ответы на технические вопросы, которые они изучили заранее. Ни один из них не задал мне ни одного вопроса о моем резюме. Откуда они могли знать, подхожу ли я им?
Когда я проходил собеседование в качестве подрядчика в Google, я прошел обычный проктологический осмотр. Многочасовые собеседования, сидя в комнатах, сделанных в IKEA. Я терпел все собеседование, пока какой-то молодой парень говорил: "А вы не могли бы придумать другой способ".
В конце собеседования вошел пожилой чувак и сказал: "Я не буду задавать вам бесполезных технических вопросов. Я уверен, что у вас их достаточно. Расскажите мне, как бы вы изменили дизайн веб-браузеров".
Через два часа мы оба поняли, что нравимся друг другу и можем добиться результата.
Инженеры не подключаются к сети
Подумайте вот о чем. Для типичного собеседования с "руководителем" требуется группа идейных лидеров. Команда подбирает лидеров с особой тщательностью.
Опытные интервьюеры заранее изучают резюме кандидатов. Чтобы понять, что это за человек, они проводят исследование.
Например, если речь идет о финансовом директоре, компания может заранее обзвонить рекомендации. Цель - выяснить, соответствует ли философия кандидата миссии и видению компании. Проведя небольшую домашнюю работу, мы выясняем, соответствует ли финансовый директор или нет.
Мы используем резюме кандидата, чтобы понять, принесут ли его навыки пользу компании. Иногда этот процесс занимает несколько недель и требует участия нескольких человек, имеющих опыт проведения собеседований.
Но разработчики программного обеспечения укладываются в максимально возможное количество часов. Неподготовленные, рассеянные интервьюеры выстраивают очередь из трех-четырех вопросов. У человека, проводящего собеседование, мало времени, потому что он работает над проектами, требующими сжатых сроков.
Для них дело не в соответствии или ценности бизнеса, а в вопросах, которые они нашли в Google.
Вот что не придется делать финансовому директору:
- Выходить к доске и доказывать, что она умеет составлять баланс.
- Решать случайные математические вопросы, чтобы доказать, что она еще умеет складывать.
- Получать вопросы, которые она в последний раз видела в колледже.
Только разработчики программного обеспечения получают такой уровень неуважения. И что самое ужасное: Мы делаем это друг с другом. Плохая отраслевая практика приучила нас дисквалифицировать, осуждать и придираться.
Как думать о собеседовании
Как же проверить разработчика программного обеспечения, если вы не задаете острых вопросов?
Опыт. Вдумчивость. Усилия. Обучение.
Вы читаете их резюме и звоните рекомендателям. Вы спрашиваете об их предыдущем опыте. Интервьюеры могут многое узнать из того, как кандидаты рассказывают свои истории, и, если ваша компания хорошо обучила вас, вы научитесь слушать, чтобы понять глубину технических знаний.
Сильные кандидаты будут отвечать на вопросы, чтобы показать свои знания. Они добровольно пойдут к доске, потому что в этом есть смысл, а не потому, что это часть упражнения на собеседовании.
Хорошие интервьюеры задают открытые вопросы и делают заметки. Открытые вопросы - это лучшая стратегия для определения соответствия культуре и технической глубины.
Плохие интервьюеры показывают ужасный язык тела, надеясь и ожидая, что кандидат провалится, и они смогут вернуться к своим рабочим столам и писать код.
Суть в том, что мы нанимаем разработчиков программного обеспечения, чтобы они приносили пользу бизнесу. Мы хотим, чтобы наши команды были согласованы. Мы жаждем великой культуры и совместных побед.
Вместо того чтобы проверять основные ценности, мы проводим тестирование. Мы дисквалифицируем. Мы думаем о ближайшем проекте и спрашиваем себя, сможет ли кандидат сделать что-то следующее.
Нет дальновидности. Нет глубины. Просто куча глупых технических вопросов, которые мы все гуглим. Мы повторяем этот процесс и терпим неудачу.
У этого явления даже есть определение