Найм разработчиков является больной темой для большинства компаний. И эта проблема значительно усугубляется для тех руководителей, которые сами не имеют достаточного опыта в разработке. Предлагаем вам советы от 37Signals о том, как нанимать на работу программистов, если сами вы - не программист.

Как нанимать программистов, если вы таковым не являетесь? Несколько вещей, которые стоит взять на заметку…

1. Насколько у них сформировано свое мнение?
Задайте им вопрос на одну из сочных тем в программировании (напр. что лучше: Ruby или Pyton?). Характер и аргументация ответа скажут вам о многом. Когда у людей есть сильная позиция относительно определенных вещей — когда они могут долго рассуждать о чем-либо — это хороший показатель того, что они увлечены вопросом.

2. Как много они вкладывают в open source проекты?
Посмотрите на их вклад и работы в open source. Даже если вы не программист, то все равно сможете сказать, есть ли в нужном месте строки кода. Тот факт, что люди «за идею» вкладывают во что-то свой труд, уже является неплохим началом. Это означает, что им не сидится на месте. Они углубляются во что-то, что, как им кажется, должно быть усовершенствовано: вникают в проблему и решают ее самостоятельно. Таковой уровень сопричастности является очень хорошим показателем.

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

4. Действительно ли они делают работающие проекты(вовремя)?
Узнайте, как они организуют свою работу. ПО часто слетает — узнайте, как они справляются с этим. Расспросите о том случае, когда они создавали работающий проект в срок и уточните, какой подход им в этом помог. Или узнайте об уроках, которые они извлекли из просроченных проектов. Очень важно то, как они распределяют свои задачи и как подходят к каждой из составных частей работы над проектом.

5. В чем они преуспели? В чем их мастерство?
Ренди Нельсон из Pixar утверждает, что успех в одной области является хорошим признаком будущего успеха и в других сферах. Так что ищите мастеров в своем деле. Кандидат является замечательным поваром? Мастером горного велосипеда? Обладает любыми другими выдающимися умениями? Это сигнал к тому, что он будет крайне эффективным в работе и над вашим проектом. То, что человек, например, может запросто добраться до вершины горы, выгодно выделяет его среди прочих кандидатов. И наоборот, есть очень небольшой шанс того, что кто-то добьется мастерства в работе, если до этого он ни в чем не преуспел.

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

Тест драйв

Если это возможно, отходите от решений в стиле все-или-ничего. Наем сотрудника на фулл-тайм — это большое, сложное дело. Привлеките соискателя к работе над небольшим проектом, который он сможет делать в свободное время. Это намного лучший выбор и для вас и для предполагаемого сотрудника, чем решение безвозвратно принять на веру слова друг друга.
В книге «Getting Real» говорится следующее:

Прежде чем нанимать сотрудников мы даем им мини-проекты для пробы своих сил. Мы видим, как они справляются с проектами, как они общаются в рабочей обстановке, ведут себя и т.д. Работа с кем-либо (дизайнером, программистом) всего лишь над парой страниц даст вам тонны информации. Вы очень быстро поймете, насколько успешно происходит рабочий процесс.
Назначение может быть не на сто процентов правильным решением даже в этом случае. Однако совместная работа в 20, 40 часов — намного лучше, чем ничего. Подходите ли вы с соискателем друг другу — будет почти очевидно. И, если нет, обе стороны уберегут себя от возможных проблем и рисков, предварительно исследовав ситуацию.

Неплохо бы также подумать над тем, что вы предлагаете соискателям. Как вам сделать ваше предложение настолько привлекательным, насколько это сейчас возможно. В очерке “Great Hackers” Пол Грэм предлагает список того, что лучше всего привлекает выдающихся программистов: хороший инструментарий, открытое ПО, закрывающиеся кабинеты, интересные задачи, опытные сослуживцы. Если у вас имеется часть/все из вышеперечисленного, убедитесь, что потенциальные наемники об этом осведомлены.

Заняться этим самостоятельно?

Все эти вещи действительно могут вам помочь, но самым лучшим условием найма по-настоящему хорошего программиста является ваше знание, хотя бы общее, программирования. Нанимать человека на работу, которую вы сами никогда не делали, очень сложно. Точно так же, как и управление этим человеком после принятия его на работу. Грэм рассматривает данный вопрос в “Great Hackers”:

Я встречал нелепейшие статьи о том, как руководить программистами. На самом деле, таких статей должно быть всего две: одна о том, что делать если вы сами являетесь программистом, и вторая — на случай, если вы им не являетесь. Вторая статья, в принципе, могла бы быть сокращена до одного слова: сдавайтесь.
И проблема не в повседневном менеджменте. Действительно хорошие разработчики (хакеры) и так хорошо самоорганизованы. Проблема в том, что если лично вы — не разработчик, то не сможете определить, кто является хорошим разработчиком, а кто — нет.

Потому, если возможно, приобретите некоторые навыки в программировании прежде чем нанимать для этого отдельных сотрудников. (Как сказано в книге «REWORK»: “Никогда никого не нанимайте на любую работу, пока вы не попробуете делать ее самостоятельно.”) Например, в компании 37Signals не искали сис. админа покуда один из основателей не потратил множество времени на обучение настройке серверов. Выберите такой же путь и вы лучше поймете, что именно стоит искать в кандидатах, и какие конкретно проблемы вы собираетесь с их помощью решать.
Что же касается ошибок, которые вы совершите в процессе обучения, запомните, что именно так “настоящие” программисты и работают. “Пробег итераций при разработке похож на нескончаемую череду исправлений ошибок” — говорит Джереми Кемпер, — “Это звучит угнетающе, но со временем придает сил. Даже тестовая пред-разработка выливается в серию исправлений. Потому мой совет — для начала лично поработать в этой сфере.”

Данный материал является переводом статьи «How to hire a programmer when you’re not a programmer» из блога 37Signals