Малый IT бизнес. Часть 3. Найм сотрудников, собеседования, тесты

Всем привет!

Продолжается серия публикация, анонсированная здесь.

С момента выхода последней статьи прошло много времени, но то что начато, должно быть завершено, так что ловите следующую!

1. Общая стратегия поиска сотрудников

Эта статья посвящается процессу найма разработчиков(программистов) в небольшую IT команду. Многие принципы можно успешно использовать для поиска других специалистов: дизайнеров, технических писателей, тестеров, менеджеров.

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

Отличительной особенностью подбора персонала для малой IT компании является то, что руководитель принимает непосредственное активное участие в этом процессе. По крайней мере, так происходит у меня. Следующей особенностью является то, что процесс не является потоковым. Вы не нанимаете десятки людей 365 дней в году. Это означает, что к каждой вакансии возможен, и нужен очень индивидуальный подход.

Вот основные этапы и действия, которые можно порекомендовать при поиске нового сотрудника:

• Определите качества разработчика, который вам нужен.
• Определите преимущества работы именно в вашей организации.
• Составьте предельно понятное предложение о работе.
• Разместите объявление на как можно большем количестве ресурсов.

Определение качеств и требований к разработчику

Помните одну важную вещь – не бывает универсальных людей. Человек способен профессионально работать только в нескольких областях, а не везде сразу. В связи с этим вы должны четко понимать, для каких задач вам нужен разработчик, а для каких нет. Попытка найти специалиста “все в одном” приводит к плачевным результатам.

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

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

Вот некоторые вопросы, на которые вы должны сами себе ответить перед поиском нового сотрудника:

• Насколько профессионален должен быть разработчик? Разные задачи требуют разного уровня профессионализма. Очень часто для выполнения крупного проекта достаточно 1-2 высокопрофессиональных разработчиков и несколько с гораздо меньшей квалификацией. Если у вас нет необходимости в супермегакрутом программисте – ищите более простых ребят. Они найдутся быстрее и будут стоить дешевле.
• Какие требования к надежности и ответственности вы предъявляете? Если задачи, под которые вы ищете человека, могут быть легко и сходу сделаны другим разработчиком, вы можете закрыть глаза на надежность сотрудника. В одном из моих проектов несколько лет назад нужно было сделать много несложной и хорошо задокументированной работы. Я договаривался с разработчиками на fixed оплату по результату и брал на работу любого желающего. За несколько месяцев через проект протекло более 100(!) человек, которые в совокупности стоили недорого и сделали поставленную задачу.
• Какие навыки необходимы для выполнения поставленных задач? Если у вас будет разработка проекта для американского рынка, очевидно, вы должны включить в требования знание английского. Если у вас разработчик будет делать только серверную часть, он может и не знать AJAX и прочие Javascript клиентские штуки. И так далее. Четко определите обязательные и опциональные требования.
• Какой график работы вы можете предоставить? Если вы можете предоставить относительно свободный график работы – для многих разработчиков это будет плюсом. Нет необходимости затягивать гайки насчет графика работ без причин. Однако слишком сильно расслаблять персонал тоже не стоит.
• Возможна ли удаленная работа? Возможность удаленной работы расширит географию поиска сотрудников, но вы должны понимать, что степень надежности удаленного сотрудника гораздо меньше офисного, каким бы профессионалом он не был. Без контроля люди расслабляются – это факт. Тем не менее, на удаленном типе работы ставить крест не стоит. Удаленная работа очень даже неплохой вариант, если задачи не очень ответственны и просты.

Чем больше ответственности, ограничений и требований вы накладываете на сотрудника, тем труднее его будет найти, и тем дороже он будет стоить. Так что, если какое-то требование не является принципиальным – смело вычеркивайте его!

Преимущества работы именно в вашей организации

У вас малый IT бизнес. Это означает, что вы, скорее всего, не сможете привлекать сотрудников только одним именем организации(Microsoft, Google, etc…). Найдите преимущества работы именно в вашей компании. Как правило, это:

• Демократичная атмосфера работы. Многим людям просто не нравится работать в больших компаниях.
• Возможность развития. В небольшой организации можно получить гораздо более мощное развитие, чем в крупной компании т.к. сотрудник не просто звено, винтик в огромной системе. Как правило, в компаниях с количеством сотрудников в 5-10 человек общий результат работы достаточно сильно зависит от каждого члена команды.
• Компромиссы по рабочему графику, отпускам, и прочим формальностям. Отпуск два раза в год, в Ноябре и Марте – это прерогатива работников крупных жестко зарегламентированных организаций. Подойдите гибко к этому вопросу, и люди к вам потянутся!
• Работа над проектами определенного типа, которые интересны разработчику. Это ОЧЕНЬ важный пункт! Возможно, вообще ключевой. Вы можете убедить работать разработчика именно в вашей компании только из-за тех проектов, которые ему интересны и которыми он будет заниматься.
• Работа в команде с интересными людьми. Если в вашей компании уже работают выдающиеся личности, интерес к вашей компании существенно возрастет. Многим, особенно начинающим и прогрессирующим разработчикам, интересна возможность работы опытным человеком. Точно также, опытному человеку будет интересна работа в качестве тим лида над перспективной командой.

Составьте предельно понятное предложение о работе

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

В моем понимании, в предложении должна присутствовать следующая информация:

• Позиция, на которую ищется сотрудник. Исходя из объявления, должно быть понятно, насколько опытным должен быть человек и какие обязанности предстоит выполнять.
• Условия оплаты. Если планируется снижение оплаты на испытательный срок – обязательно расскажите об этом. Неожиданные детали, типа заниженной оплаты, всплывшие на собеседовании, вызывают неприятный осадок.
• Профессиональные требования. Укажите обязательные требования к сотруднику. Еще раз повторюсь – не стоит просто для галочки писать раздутый список требований.
• Условия работы. Если вы можете предоставить интересные условия работы(супер офис, личный кабинет, бесплатные обеды и т.п.) – обязательно напишите об этом в объявлении.
• Возможность удаленной работы. Если удаленная работа возможна – я пишу об этом. Если невозможна – я также пишу.
• Насколько срочно нужен сотрудник. Например, если найм терпит пару месяцев – обязательно напишите об этом. Это привлечёт внимание тех, кто на текущий момент не планирует смену работы, но потенциально заинтересован в будущих предложениях.

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

Размещение объявления

Разместите объявления везде, где только можно и нельзя. Потратьте пару часов своего времени для того, чтобы получить хорошее количество откликов. Как правило, 99% процентов того, что вам пришлют, будет отсеяно при первом же прочтении. Так что, чем больше источников(сайты по пойску работы, сообщества, форумы и т.п.) будут вами охвачены, тем больше вероятность того, что нужный вам человек увидит объявление.

Если вам повезет, и вы найдете несколько сильных кандидатов на вашу позицию, то вы просто познакомитесь с разработчиками для будущих потенциальных вакансий. В следующий раз вы просто разошлете письма кандидатам напрямую.

2. Стадии найма сотрудника

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

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

Итак, поехали:

• Первоначальный разбор резюме. Это самая простая стадия. При этом на ней отсеивается 99% кандидатов. На уровне знакомства с резюме можно сделать очень много выводов. Я искренне верю, что те, кто отсеялись на этой стадии с очень маленькой вероятностью прошли бы остальные.
• Уточняющие вопросы. Даже толковые резюме очень редко содержат в себе полную информацию. Как правило, необходимо уточнить причины поиска работы, наличие отзывов от бывших работодателей, попросить рассказать про примеры выполненных проектов. Если все в порядке – переходим к следующему этапу!
• Тестовое задание или пример кода. Тестовое задание я выдаю только тем, кого с большой вероятностью хочу взять на работу. Для опытных людей эта процедура заменяется на демонстрацию примера кода. Если кандидат на позицию разработчика не смог предоставить код и не согласился на выполнение тестового задания – я его на работу не беру, каким бы крутым он не был. Раньше, года два назад брал, а сейчас нет.
• Собеседование. В случае успешного выполнения тестового задания я приглашаю разработчика на собеседование. Я уже знаю о разработчике всю необходимую мне информацию и получил подтверждение профессиональных навыков. Цель собеседования – это просто проверка на комфортность общения с человеком.
• Тестовый проект. Если есть возможность, я сначала стараюсь давать новому сотруднику не очень ответственную или критичную для организации работу. Риск облажаться очень велик в первые месяцы работы, так что лучше свести потери к минимуму. Это уже нормально оплачиваемая работа, но в случае провала проекта общие негативные последствия для организации минимальны.
• Окончательный прием на работу. Только после успешного выполнения первого небольшого проекта можно судить о том, что человек подходит для вашей организации. С этого момента начинается серьезное и долгосрочное сотрудничество.

Каждая из стадий рассмотрена подробно ниже.

3. Разбор резюме

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

Сразу скажу, что я привык работать с толковыми ребятами, но без профессиональных понтов и звездной болезни. Это означает, что процедура приема на работу не зависит от крутости кандидата. Отклик на вакансию в пару строчек типа: “Я Вася, известный в рунете программист галактического масштаба, крут не по годам! Хочу у вас работать. Детальное резюме присылать не считаю нужным – обо мне и так все знают!”, я, как правило, по тихому отправляю в архив и желаю Васе удачи.

В первую очередь, качество присланного документа свидетельствует о:

• Желании получить работу в вашей организации.
• Личных качествах кандидата.

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

В связи с этим, я даже не отвечаю на такие письма(реальные примеры из жизни):

Пример 1

Профессиональные навыки: Владею ПК на высоком уровне. Увлекаюсь видео обработкой, владею Photoshop на базовом уровне. Обладаю средним навыком в создании сайтов (знание HTML языка, CSS стилей,PHP,Javascript) Знаком с Apache и MySQL. Английский-знание на базовом уровне.Хорошо владею оргтехникой(подключение, обслуживание).Усидчивый, ответственный.Люблю ставить интересные и сложные задачи, и потом их решать.

Пример 2

Здравствуйте. Я по работе.
Сейчас нахожусь в процессе глубокого изучения Yii, есть видимый прогресс. Знание
английского языка на достаточном уровне. Есть возможность работать удаленно целый
день. Большое желание развиваться в этом направлении.
Готов продемонстрировать свои знания и умения на небольшом тестовом задании, которое
может пойти в зачет вашего текущего проекта.
С уважением, Дмитрий.

С моей точки зрения в хорошем резюме должна присутствовать следующая информация:

• Персональные данные: ФИО, дата рождения, семейное положение.
• Контактные данные: e-mail, телефон.
• Адрес проживания кандидата. Это не совсем важный параметр, но в целом полезный. Например, можно понять, насколько далеко от вашего офиса живет разработчик.
• Уровень образования. С моей точки зрения нет ничего проще получения высшего образования, даже параллельно работая. Так что, отсутствие высшего образования, заброшенные вузы и т.п. наводят на сомнения найма такого сотрудника. Понятно, что это не относится к поискам толковых студентов.
• Профессиональные навыки.
• Список предыдущих\текущих работодателей.
• Отзывы от работодателей, если таковые имеются.

Наконец-то вам пришло толковое резюме! Давайте разберем моменты, на которые следует обратить внимание.

Соответствие возраста позиции

В любой отрасли есть достаточно четко обозначенные темпы развития специалистов. Любые отклонения должны вызывать сомнения в продолжении общения с кандидатом.

Наиболее часто встречающееся отклонение – это попытка людей возраста 30+ устроится на достаточно низко оплачиваемую работу разработчика среднего и начального уровня, идеально подходящую для студента 20-22 лет. Если разработчик действительно работает над своим развитием, к 25 годам он\она получает необходимый опыт и знания для участия в очень сложных проектах, с очень высокой зарплатой и прочими привилегиями.

Если вам пишет человек с 10 летним опытом, что он готов работать за 30 тысяч рублей – это мертвый груз. Это значит, что за 10 лет разработчик не смог продвинутся выше простейших задач и вряд ли это сделает. Если вам нужен неопытный человек – возьмите лучше на ту же зарплату студента, здесь хотя бы есть шанс динамики развития.

Обратная ситуация, когда на позицию старшего разработчика с окладом в 70 тысяч резюме присылает 20-летний разработчик, встречается реже, но тоже присутствует. Эти ребята просто рассылают свои резюме всем подряд =).

Список предыдущих работодателей

Если список предыдущих мест работы может конкурировать с Желтыми Страницами, у вас кандидат долго не задержится. Даже не тратте на него время, несмотря на профессиональные качества. Есть очень много высокообразованных и ультрапрофессиональных разработчиков с головой и руками, меняющих работу каждые несколько месяцев по причине геморойного характера, поиска новых проектов и прибавке в 1000 рублей на новом месте. Если вы ищете долгосрочное сотрудничество – переходите к следующему резюме.

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

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

Квалификация

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

Хобби, личные качества и т.п.

Такая информация, как личные качества, имеет не очень большой вес. Сейчас, начитавшись статей про идеальные резюме, о “высокой обучаемости”, “надежности”, “ответственности”, ”стрессоустойчивости” и т.п. пишут все. Вот только при первой серьезной критической ситуации ничего из этого списка у разработчика не обнаруживается.

Хобби – это другое дело. По ним косвенно можно понять, что из себя представляет кандидат, как личность. Вы ведь хотите работать не с роботом, а с живым человеком! Так что, если разработчик в хобби указал что-то отличное от “компьютеры”, “шахматы”, ”изучение языков программирования”, то перед вами может оказаться интересный человек, с которым можно и поработать, и в кабаке нормально выпить!

Что делать с отклоненными резюме?

Ни в коем случае не удаляйте не прошедшие проверку резюме! Складывайте их в отдельную папочку. За 7 лет я их накопил столько, что сейчас во многих случаях могу прослеживать историю обращения одних и тех же людей из года в год. Иногда бывает очень познавательно!
Вам пишет матерый, закаленный в mission impossible проектах разработчик, а тут вы откапываете его резюме, присланное вам в 2004 году =).

4. Общение до собеседования

Итак – вы отобрали из первой сотни 2-3 более-менее вразумительных резюме. Что дальше? Не стоит сломя голову приглашать кандидатов на собеседование и обещать любые материальные и духовные блага. Правда жизни такова, что скорее всего никто из них не продвинется дальше тестового задания. Так что вооружитесь терпением, внимательно изучите еще раз резюме и ответьте на следующие вопросы:

• Почему разработчик меняет работу? Идеальный вариант – закончил все дела на старой работе и больше нет проектов, переехал в другой город, предыдущая компания закрылась(разработчики – поняли что надо писать? =))). Эти варианты подразумевают бесконфликтное завершение дел с предыдущим работодателем.
• Могут ли предыдущие работодатели предоставить отзывы? Если разработчик имеет привычку корректно завершать дела, то с отзывами проблем нет. Если же к вам на работу просится опытный человек без отзывов – это то же самое, что купить Impreza WRX 2005 года за 5000$. Наверняка сварена из двух частей или владелец поменялся насильственным способом.
• ТОП 3 наиболее сложных\интересных проекта? Эта информация не очень актуальна для младших позиций, однако для средних и старших очень важна. Определите, действительно ли кандидат участвовал в нетривиальных проектах, или же всю жизнь делал простые сайтики на Drupal. Данные о ранее выполненных проектах также помогут понять, делалась ли работа, схожая с предстоящей.
• Может ли кандидат предоставить пример кода? На основании кода можно очень много сказать о профессионализме разработчика. Важно понимать, что НЕ предоставить код могут только те, кто никогда его не писали, или писали очень убого. Так что любые отмазки типа “лучше дайте мне тестовое задание”, ”мой код мегасекретен, я не имею право его давать”, ”у меня накрылся жесткий диск, все пропало” просто говорит о том, что заявленные в резюме скилзы не соответствуют действительности. Если вы берете сотрудника на позицию технического писателя, дизайнера и т.п. – можно просто попросить предоставить примеры работ.
• Когда кандидат может приступить к работе? Обязательно уточните этот вопрос! Может так приключиться, что заинтересованному в вашей вакансии разработчику необходимо пару месяцев на корректное завершение дел у текущего работодателя, что не состыкуется с вашими планами.

Если на какой-то из этих вопросов вы не получили ответа в резюме – смело задавайте их по e-mail!

Любые менее важные вопросы можно уточнить просто по телефону.

5. Тестовое задание

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

Цели выполнения тестового задания следующие:

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

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

Составление тестового задания

Уделите достаточно времени составлению тестового задания. Оно вам пригодится много раз.

Вот несколько советов касательно составления задания:

• Привлеките к составлению задания одного из опытных сотрудников. Или, по крайней мере, отправьте результат ваших творений своим сотрудникам на рецензию.
• Задание не должно быть слишком объемным, на его выполнение должно хватить 3-4 часа.
• Задание должно подразумевать инициативу. Не стоит его жестко регламентировать, оставьте несколько степеней свободы. И внимательно следите за тем, кто ими воспользовался, а кто нет.
• Если вы хотите протестировать на английский язык – дайте задание, подразумевающее обязательное изучение англоязычной документации.
• Если вы хотите протестировать на способность быстро схватывать новые вещи – дайте задание на неизвестном разработчику фреймворке.
• Если вы хотите протестировать на аккуратность исполнения интерфейсов, включите в тестовое задание вывод информации для конечного пользователя.
• Не стоит все расписывать подробно. Вам нужно, чтобы кандидаты задавали вопросы и не стеснялись это делать. Весь прикол в том, что многие не задают вопросов, делают совсем не то и не так! Вам ведь не нужен такой разработчик в реальной работе?
• Четко определите, в каком виде вы хотите получить результат. Лично я предпочитаю готовую демку + исходный код. Например, если тестовое задание состоят в создании веб компонента, я прошу разработчика выложить на какой-нибудь сервер, чтобы можно сразу было посмотреть все в действии.

Проверка тестового задания

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

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

На что стоит обратить внимание при проверке тестового задания:

• Полнота исполнения. Все ли заявленные требования учтены. Если не все – разработчик либо поленился, либо просто невнимательно отнесся к задаче.
• Качество написанного кода. Вы, или опытный разработчик из вашей компании, должны обязательно проанализировать исходный код задания на качество исполнения: форматирование, четкое следование определенным стандартам, комментарии и т.п. В тестовом задании проще, чем когда-либо написать почти идеальный код. Если это не сделано – у вас будут проблемы с разработчиком.
• Наличие любой сопроводительной документации, пусть даже в 3 строчки. Это просто правило хорошего тона. Если документации нет, вы имеете дело с незрелым специалистом.
• Аккуратность исполнения. Здесь имеется в виду общая аккуратность интерфейсов, продуманная файловая структура. Если вам нужен системный разработчик для компонентов уровня ядра сложных продуктов, то требовать аккуратности интерфейсов и т.п. не стоит, главное, чтобы код был профессиональным. Однако, если вы берете на работу вебмастера для работы на фронтендом, вам придется многое подчищать за неаккуратным человеком.

Тестовое задание – это реклама разработчиком своих возможностей. Мотивация сильна как никогда – это получение рабочего места. Так что, в теории все должно быть сделано просто идеально! Если же тестовое задание сделано кое-как, это свидетельствует либо об отсутствии сильного желания работать у вас в компании, либо о низких профессиональных навыках разработчика. Ни первое, ни второе вам не нужно.

6. Собеседование

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

• Делать несколько собеседований одно за другим в один и тот же день. Стробоскоп лиц не даст вам возможности внимательно обдумать результаты.
• Собеседовать разработчика толпой в 5 человек. Разработчику будет просто некомфортно сидеть как на допросе. Вас и одного специалиста более чем достаточно.

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


На что можно, и нужно протестировать кандидата при личном общении:

• Общий IT кругозор. Если кандидат имеет представление о многих сферах разработки, пусть даже поверхностно, это хороший знак.
• Фундаментальные знания. Знание основных принципов разработки, вне зависимости от языка программирования и технологии, достаточно критично. Если разработчик не может рассказать про концепции объектно-ориентированного подхода, или же про то, что означает слово ‘реляционная’ в СУБД, это весьма плохой сигнал.

Если качество исполнения тестового задания вас в целом устроило, но остался ряд небольших вопросов и замечаний, их вполне разумно разобрать на собеседовании.

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

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

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

7. Тестовый проект

Тестовый проект – это первое задание на рабочем месте. Если у вас есть возможность занять разработчика непродолжительной по времени(2-6 недель) и не очень ответственной для компании(потери от провала минимальны) задачей, это то, что нужно!

Какое бы сильноположительное впечатление не произвел бы на вас разработчик своими профессиональными и личными способностями, делать серьезные выводы рано. По личному опыту могу сказать, что только через год die-hard работы в вашей организации можно с уверенностью сказать, что сотрудник подходит вам. Что уж там говорить о гарантиях в самом начале сотрудничества!

Если разработчик профессионально облажается, неожиданно решит уволиться, сделает работу плохо – это проблемы для вашей организации. Так что постарайтесь смягчить отрицательный эффект путем старта с не очень ответственного проекта.

На роль тестовых проектов идеально подойдут:

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

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

Если разработчик успешно справился с тестовым проектом – поздравляем, вы получили в штат перспективного сотрудника! Однако если результаты оказались плачевными, корректно расходитесь, связывайтесь с другими потенциальными кандидатами и повторяйте процесс заново.

Сложно? А кто говорил, что будет легко!? =)

8. Общие мысли и замечания

Ниже несколько личных замечаний и советов, которые относятся к процессу найма в целом:

Работодателям

• Вы – не Красный Крест. Не занимайтесь благотворительностью. Для вас сотрудники – это не братья и сестры, а инструмент для реализации сервисных услуг. Если инструмент плохой – не задумываясь меняйте его.
• Любое увольнение должно быть по возможности корректно. Под “корректно” я подразумеваю нормально предупредив, выплатив зарплату(пусть даже серую), дав рекомендации с случае, если сотрудник их просит и заслуживает. Исключение: сотрудник с вами сам обошелся весьма некорректно(такое происходи достаточно часто, лично у меня примеров просто завались).
• Людей перевоспитать невозможно. Если у вас систематически всплывают одни и те же проблемы с нанятым сотрудником – корректно увольняйте его как можно скорее.
• Нашли хорошего человека – не тяните с наймом. Хорошие люди большая редкость, в независимости от квалификации. Такой разработчик быстро найдет еще пару вариантов трудоустройства, а вы на поиск другого кандидата потратите пару месяцев.
• Зарплата должна быть адекватной. Частый перекос – попытка найти хорошего сотрудника дешево. В IT такое давно не прокатывает. Редкий перекос – попытка быстро найти сотрудника поиска путем предложения сверхзарплаты. Не найдете. Те, кто достойны сверхзарплаты и так ее имеют. Деньги не самое важное. Проекты и рабочее место часто важнее. Направьте свои, в том числе и финансовые усилия лучше в этом направлении.

Разработчикам

• Уделите достаточно времени для составления профессионального резюме. Помните о мелочах, например о том, что руководитель может сидеть под маком, и ваше присланное в MS Word резюме вызовет тоску. Сделайте PDF версию. Наспех состряпанное резюме приведет к вакансии такого же качества. Оно вам надо?
• Не спамьте резюме на все опубликованные в рунете вакансии вне зависимости от требований. Вы никогда не получите работу, если ваши скилзы лежат за пределами требований, зато оставите о себе неприятные воспоминания: “Аааа, это же тот спамер, который по поводу и без присылал свое резюме”.
• Если вам выдали тестовое задание, и вы не готовы подойти к выполнению серьезно – лучше вообще не беритесь. Сэкономите свое время и время работодателя. Весь прикол в том, что качественно выполненных заданий часто ноль, редко единицы. Так что, сконцентрировавшись на вакансии наиболее понравившегося работодателя вы обойдете большинство кандидатов.
• Приложите максимум усилий для получения рекомендаций. Рекомендации могут быть не только от работодателей, но и от более опытных коллег по цеху. Сам факт наличия рекомендаций выделяет вас из толпы. Кстати, не стоит их расписывать в резюме. Просто сообщите, что рекомендации имеются и могут быть предоставлены по запросу.

Дмитрий Филатов,
Ноябрь 2010