Pull to refresh

Собеседования с разработчиками: вы делаете это неправильно

Reading time 5 min
Views 4.2K
Original author: Udo Schroeter
Истории о том, как люди проходят собеседования в Google, напоминают мне о тех давно ушедших днях, когда я работал в стартапе. За десять лет проведения «современных» IT-интервью наша компания ничему не научилась, и я был частью этой проблемы несколько лет. Я просто скопировал стандартный механизм интервью тех времен, и тем самым совершил большую ошибку. Я думаю, проблемы с производительностью в компаниях, в которых во главе угла ставятся разработчики, выжжены в их ДНК процессом найма новых сотрудников — в корне порочным.

Как мы это делали


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

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

Стандартное собеседование


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

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

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

Что из этого получалось


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

Что, собственно, подразумевается под «хорошими» и «плохими» в данном контексте? Вот несколько важных для меня критериев:

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

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

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

Результат


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

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

Альтернатива


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

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

Эти вопросы расскажут вам многое о человеке, сидящем напротив вас, — интересно ли ему то же, что и вам, нравится ли вам его стиль мышления, в чем его страсть. Умение программировать? После собеседования посмотрите на какой-нибудь код кандидата — написанный для open-source проекта или на прошлой работе, неважно — это расскажет гораздо больше, чем затейливые коды из десятка строк на доске.

Отрицание

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

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

Лучшие программисты не занимаются проектами в свободное время
Самые талантливые люди, которых я знаю, работают с 9 до 5, а потом отправляются домой смотреть футбол

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

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

Заключительные мысли


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

Комментарий переводчика


Из статьи непонятно, из-за чего закрылась компания автора и почему автор так уверенно винит в этом процесс найма. Для доказательства его тезиса следовало бы основать вторую компанию, точно такую же, но с другим процессом, и сравнить результаты.
Tags:
Hubs:
+87
Comments 54
Comments Comments 54

Articles