Pull to refresh

Как я нанимаю программистов

Reading time 4 min
Views 10K
Original author: Aaron Swartz
Есть три вопроса, ответ на которые надо знать, когда нанимаешь на работу программиста:
      1) Он умный?
      2) Способен ли он выполнять работу?
      3) Смогу ли я с ним работать?

Кто-то умный но не способный выполнять работу может быть хорошим другом, но не сотрудником. Можно обсудить с ним какие-то проблемы, пока он прохлаждается на своей собственной работе.

Тот, кто способен выполнять работу но не умён – неэффективен. Неумные люди выполняют работу путём грубой силы. Работа с такими людьми движется медленно и обычно раздражает.

С тем, с кем я не смогу работать – я не смогу работать.

Под катом продолжение статьи Аарона Шварца. Я бы предпочёл чтобы меня собеседовали таким образом, чем быть изучаемым девочкой-сотрудницей ОК, которая не отличает http от mp3.


Традиционно процесс найма программиста состоит из:
      1) чтения резюме;
      2) краткого собеседования (по телефону);
      3) выполнения тестового задания.

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

Поэтому, когда я нанимаю человека, я стараюсь получить ответ на эти три вопроса.

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

Чтобы понять умён ли человек, я просто стараюсь с ним неформально поболтать. Делаю всё что можно, чтобы не давить на человека: назначаю встречу в кафе, даю понять, что это не собеседование, делаю все, чтобы быть неформальным и дружелюбным. Ни в коем случае я не задаю вопросов, стандартных для собеседования. Я просто болтаю с человеком, как с кем-то, кого я встретил на вечеринке (плохая идея спрашивать о «сильных и слабых сторонах личности» или дать оценку количества настройщиков роялей в Чикаго). По-моему в обычной беседе довольно просто понять насколько человек умён. Я постоянно отмечаю о людях на сколько они умны, так же как мы все замечаем насколько тот или иной человек привлекателен.

Если пытаться формализовать что именно делает человека умным, я бы отметил три вещи.

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

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

В-третьих, обучаем ли он. В какой-то момент беседы обычно я что-то объясняю. Действительно ли он понимает вещи, которые я рассказываю или просто кивает и улыбается? Много людей, которые действительно много знают в какой-то узкой области, но совершенно не проявляют интереса к другим. Есть и люди, которые любопытны, но совершенно не обучаемы: они задают много вопросов, но не слушают ответы.

Мне бы хотелось, чтобы на все три вопроса ответ был положительным.

Наконец, я должен понять, смогу ли я работать с человеком. Для этого я стараюсь просто провести с ним время. Многие люди могут выглядеть просто бриллиантами на протяжении часа, но через пару часов ситуация может полностью измениться. Поэтому после беседы, я приглашаю человека перекусить со всей остальной командой, или на какую-нибудь игру в офис. Важно сохранить как можно более неформальную обстановку. Смысл здесь в том, чтобы просто посмотреть: действует ли человек мне на нервы.
Если всё выглядит так, что я готов человека нанять, то в качестве последнего испытания, чтобы убедиться, что меня не одурачили, я прошу выполнить какую-то часть работы. Обычно это значит выбрать какой-то совершенно отдельный участок работы, и попросить человека выполнить его. Если в данной ситуации необходимо оценить может ли работать человек под давлением – можно ограничить его жёстким сроком. Можно предложить оплату за эту работу, хотя обычно в этом не возникает необходимости, так как большинство программистов не возражают выполнить небольшой участок работы, при условии что результат останется открытым (open source). Такая проверка при помощи выполнения задания не работает отдельно сама по себе, но если человек прошёл первые три, то этого более чем достаточно, чтобы быть уверенным, что меня не одурачили и мы скорее всего действительно сможет успешно работать вместе.

Я понимаю, что много кто скажет: «А почему бы просто не нанять человека на испытательный срок и посмотреть как пойдёт?». По-моему это просто не работает. Если вы не способны сформировать мнение о человеке после небольшого проекта, вы не сможете этого сделать и за месяц. Кончится тем, что вы постоянно нанимаете людей, которые недостаточно хороши.

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

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

upd:
Задачу про настройщиков роялей до гугла, оказывается, кто только не использовал. Например о ней пишут здесь и ещё ранее она упоминалась в книге «Как сдвинуть гору Фудзи». Спасибо тем, кто поправил.
Tags:
Hubs:
+88
Comments 133
Comments Comments 133

Articles