версия для печатиВопрос о том, как правильно нанимать программистов, мучает многих руководителей IT-компаний. То тут, то там снова всплывает мысль, что нанимать их надо не так, как других сотрудников. "Вебпланета" уже публиковала некоторые версии подобных пособий. Теперь предлагаем еще одну, своего рода "немецкий подход". Это перевод статьи Удо Шрётера (Udo Schroeter) "".
Эвана Карми о прохождении собеседования в Google напомнила мне о временах, когда мы только начинали бизнес. За более чем десять лет в вопросе "современных" собеседований о приёме на работу в IT-стартапы ничего не улучшилось. Если уж на то пошло, часть вины за это лежит и на мне. В течение нескольких лет я просто использовал готовый механизм приёма на работу, который в то время казался чем-то вроде стандарта. Как следствие, я не смог достичь наиболее важных целей, которые компания должна ставить перед собой при поиске новых разработчиков.
Сейчас все техно-СМИ активно пишут об усилиях Ларри Пейджа направить Google в другую сторону; но я думаю, что значительная часть проблем с производительностью в компаниях, чей бизнес построен вокруг разработки софта, выжигается на их ДНК глубоко порочным процессом найма.
Как мы это делали
Мы с партнёром создали небольшую компанию по веб-разработке в Германии [по всей видимости, речь идёт о Trionic GmbH — прим. перев.]. Начали работать буквально у моего друга в подвале. Со временем мы расширились и переехали в настоящий офис. Поначалу находить новых сотрудников было легко, мы просто приглашали на работу своих друзей. Конечно, эту модель нельзя масштабировать, но она выполнила важную функцию — обеспечила приём на работу в компанию людей, которые отлично для этого подходили как в личном, так и в профессиональном плане. Затем наступил день, когда нам понадобилось начать заполнять вакансии людьми со стороны.
Региональные бюро по трудоустройству Германии полезны тем, что они по телефонному запросу в течение нескольких часов высылают вам огромную кипу резюме. Я был приятно удивлён, что нам не пришлось нанимать для этого агентство. Плюс к этому, мы собрали часть резюме через онлайн-форму нашего сайта, так что нам предстояло потрудиться над отсеиванием кандидатов. В конце концов мы сошлись на том, чтобы отобрать около десятка лучших и пригласить их для собеседования. Вот с этого момента всё и пошло наперекосяк.
Стандартное собеседование с программистом
Кандидат приходил, одетый обычно в свой лучший костюм с галстуком, мы садились и беседовали. Беседа по сути походила на устный экзамен в колледже. Я просил их написать коды алгоритмов для всех типичных крохотных компьютерных проблем и получал ответы весьма разнообразного качества. Некоторые с невероятной скоростью выпуливали в меня заранее заготовленными ответами. Они были подготовлены как раз к такого рода собеседованию. Другие ломались под "давлением" и едва были способны продолжать собеседование.
Признаться, когда мы только начали этим заниматься, мне пришлось заранее ознакомиться с этими задачками, преимущественно для того, чтобы самому не опозориться. Это должно было стать первым сигналом к тому, что мы, возможно, проверяли наличие не совсем тех умений, которые соответствовали нашим требованиям. Если у меня и возникли такие сомнения, я очень быстро от них отмахнулся. В конце концов, все подходили к процессу собеседования именно так.
Конечно, мы остановились на кандидате, чьи ответы были наиболее гладкими. Само собой, когда открывалась новая вакансия, мы снова и снова действовали тем же образом в течение всего существования компании. Если вам это знакомо, вы явно не одиноки.
Истинная производительность труда
Какие результаты демонстрировали выбранные нами кандидаты? По правде говоря, результаты очень варьировались. Многие из этих людей были середнячками, очень немногие оказались отличными работниками, а некоторые просто совершенно не подходили для этой работы. Так что в самом лучшем случае собеседование не давало никакого эффекта на качество отбираемых специалистов. А в худшем, я боюсь, из-за него мы могли снизить планку производительности.
Что в данном контексте означают "хороший" и "плохой"? Давайте взглянем на некоторые из критериев, которые я считаю важными:
Культура компании. Судя по опыту, одним из наиболее важных качеств, которыми должен обладать новый сотрудник, является соответствие духу людей, которые уже здесь работают. Стандартное собеседование для программистов, по вполне очевидным причинам, показывает себя в этом вопросе с наихудшей стороны. Трудно судить о личностях людей по собеседованию, потому что в этих условиях они не являются в полной мере самими собой. На самом деле у них как раз имеется стимул не быть самими собой.
Компетентность в программировании. В какой-то степени это неочевидно, но примеры кодов, написанные во время собеседования, оказались плохим признаком истинной компетентности. На практике проекты редко требуют применения бинарного поиска без доступа к парсеру или литературе. Оказалось, что сотрудники, которые очень хорошо проявили себя в программировании тестовых задач, не всегда были способны преобразовать теоретические знания в практические решения. Если кандидаты должны писать на доске алгоритмы сортировки, преимущество получают люди с хорошей и точной кратковременной памятью, подготовившиеся именно к такого рода вопросам. В нашем же случае требовались изобретательные кодеры, способные создавать чистые, стабильные и элегантные программы. Таких людей процесс собеседования нам не поставлял.
Управление проектом. Люди, которые хорошо показали себя на собеседовании, необязательно были хорошими сослуживцами и не всегда хорошо выглядели в глазах заказчиков. Это тоже стало для меня неожиданностью. Оказалось, что умение подлизываться в течение часа к интервьюеру кардинально отличается от умения, скажем, хорошо взаимодействовать с другими членами команды или теми, кто оплачивает наши счета. Точно так же выступление на собеседовании не демонстрировало их способность писать хорошую документацию или умение вести себя в онлайне.
Результат
Результаты подобного процесса найма могут быть одной из причин, по которым компания теряет свой изначальный дух и созидательную энергию. Именно так случилось с нашей компанией. Вина за произошедшее в конце концов фиаско определённо лежит на мне как на гендиректоре; однако немалую роль в неспособности компании выдавать продукт необходимого качества и количества сыграло то, что работу выполняли не те люди. Нашу команду раздирали распри. Некомпетентность прикрывалась умением хорошо подавать себя, лизать задницу начальству. Хорошие люди покидали компанию из-за нетерпимости к новой атмосфере.
Хотя мне приходилось увольнять многих людей по тем или иным причинам, а в самом конце, в то утро, когда я распустил компанию, пришлось произнести труднейшую в своей жизни речь, я лишь однажды уподобился Дональду Трампу, увольняя подчинённого. Это был человек, который лишь годом ранее продемонстрировал самые лучшие результаты на собеседовании и имел самые лучшие университетские рекомендации среди всех прочих.
Конечно, это крайний случай. Большинство компаний всё равно добиваются успехов. Но я всё-таки верю, что мы могли значительно увеличить наши шансы найти подходящих кандидатов, полностью изменив подход к собеседованиям. И в нашем случае это могло бы оказать решающее значение.
Альтернатива
Как же тогда должно выглядеть собеседование по приёму на работу программиста? Всё просто: совершенно исключите из него экзаменационную часть. Вместо этого задавайте вопросы, которые не предполагают однозначных ответов. Это вынудит кандидатов рассказать о своей работе.
- Каким был последний проект, которым вы занимались на предыдущей работе?
- Расскажите о ваших любимых проектах.
- Над какими проектами вы работаете в свободное время?
- В какие онлайновые хакерские сообщества вы входите?
- Расскажите о каких-то (программистских/технических) проблемах, которые вас волнуют.
Цель этих вопросов — побольше узнать о человеке, который перед вами сидит. Они помогут вам решить, интересуется ли кандидат тем же, что и вы, нравится ли вам способ его мышления и где лежат его истинные интересы. Так ему труднее навешать вам лапшу, потому что вы можете копнуть глубже, выявив множество его слабых мест.
Что насчёт способности к созданию кода? Что ж, выберите пару минут после интервью и взгляните на код, написанный кандидатом. Может, это будет какой-то опенсорс-проект, может, ему придётся послать вам что-то, не являющееся публичным — неважно. Изучение настоящего рабочего кода скажет вам о кандидате намного больше, чем если вы принудите его написать на доске пять строк надуманной проблемы.
Уверен, что вы сможете придумать ещё больше вопросов и найти другие пути, годные для найма работника. На данной стадии практически любая идея пойдёт лишь на пользу.
Возможные возражения
Большинство быстро находят доводы в защиту статус-кво, и, конечно, такую позицию занимать выгодно. Ничем не рискуешь и всегда можешь спрятаться за старым аргументом "многие умные, богатые и успешные люди делают это по-старому, так что я делаю ставку на этот способ".
"Хорошо, но это не годится для больших успешных компаний. Твоя идея не масштабируется".
Ещё как масштабируется. Нет никакого различия в смысле усилий, затраченных на каждое собеседование. Нет никакой причины, почему это не годится для крупных компаний. В конце концов, интервьюер всегда принимает личное и глубоко субъективное решение, я всего лишь предлагаю способ, который выявляет наиболее значимую для принятия этого решения информацию.
"У лучших программистов нет проектов, которыми бы они занимались в свободное время" или "Самые талантливые люди, которых я знаю, работают с 9 до 5, после чего идут домой смотреть футбол/проводить время с семьёй/неважно что".
У меня другой опыт. Я не говорю, что хороший программист не должен иметь личной жизни. Но я уверен, что определённый энтузиазм для программирования необходим. И в самом деле, если вы обладаете таким крутым умением, то не использовать его для развлечения мне представляется своего рода расточительством.
"В свободное время я зарабатываю очередной миллион для своей компании. А, когда я не работаю на свою компанию? Я с семьёй или друзьями" (дословно ).
Отлично, такие люди действительно могут показать мне что-то, над чем они работают. Я бы, однако, рассматривал отсутствие каких-либо хобби-проектов как предупреждающий сигнал для некоторых видов работ.
Заключение
Мой опыт показывает, что традиционное собеседование не подходит для поиска хороших кандидатов на работу программиста. Хотя типичные задачи для кодирования на доске определённым образом коррелируют с общей компетентностью в работе с компьютерной техникой, они плохо демонстрируют истинную производительность при программировании.
Моя точка зрения состоит в том, что мы годами проводили собеседование таким способом, потому что это легко осуществить, но данные, которые всплывают на этих собеседованиях, в лучшем случае весьма нерелевантны. Мы как индустрия должны перейти к использованию на собеседованиях более личностных вопросов, которые нацелены на полноту набора программистских навыков.
Также я уверен, что значительно полезнее судить о рабочем коде, а не об абстрактных модульных задачках, которые не имеют никакого отношения к работе, о которой идёт речь.
И самое важное - я убеждён, что получение представления об истинной личности программиста так же важно, как и проверка его профессиональной компетентности, потому что один неподходящий человек может развалить всю команду.
