Алгоритм найма на работу

kika — 13.11.2016 Офигеть, 10 месяцев не писал. Тут возник вопрос в ФБ и поскольку там даже свои посты-то с трудом найдешь, что уж говорить о комментариях, то решил написать сюда, ибо вопрос возникает редко, но регулярно.

Как с моей точки зрения правильно нанимать программистов/девопсов на работу:

0. Правильно составить объявление о найме. Сжато и быстро написать bid и ask. Что надо делать (на самом деле, а не всё на свете + еще немножечко) и что за это предлагается. Что делает компания и где лежат грабли (это важнее чем расписывать какая она leading и какие технологии bleeding). Грабли могут быть технологические (адовое легаси например), организационные (адский режим работы например), финансовые (от последнего раунда осталось полгода runway, и следующий раунд зависит как раз от результатов работы) и так далее. Это все равно всплывет, но тогда, когда вы уже потратите кучу времени. Не надо надеяться что вы "продадите" хорошему программисту (то есть человеку, предположительно хорошо умеющему в рациональное мышление) свою компанию. Если он может проигнорировать какие-то грабли - он придет на интервью как минимум. Если не может - то и не сможет, значит и на интервью не придет. С граблями лучше сгущать краски чем приукрашивать, верьте мне, люди.

1. Читаем резюме. Если идет поток треша, мы что-то не то написали в №0, идем обратно туда. Если говна не больше 80% с этим можно работать, но лучше оптимизировать. Я иногда получал практически 100% выход годных (когда натурально хочется позвать всех) но не знаю как это синтезировать искусственно. Быстро валидируем резюме на непротиворечивость (даты, продолжительности, технологии), потом выделяем интересные моменты (технологии, компании, обучение), причем не обязательно интересные для данной позиции, а просто знакомые лично вам, то есть что можно обсудить на интервью. Резюме русские писать не умеют, причем как не умели 20 лет назад, так и сейчас не умеют. Немного лучше научились оформлять разве что. Впрочем лучше пусть дальше так не умеют как скажем индусы умеют, когда резюме читать вообще смысла не имеет. Обратите внимание на оформление, кстати, если вы просили в ворде, а прислали - пдф, это звоночек. Если вы просили на английском, а прислали на русском или наоборот - это тоже звоночек. Это на самом деле важно, как показывает практика.

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

3. Задаем несколько вопросов как в №2, но по теме данной позиции и копаем вглубь пока лопата не зазвенит. Причем годятся любые вопросы, ответы на которые практически невозможно запомнить всухую. "А вы помните в каком релизе там фундепы внедрили?" Правильный ответ "что-то типа NNN или около того, но потом пришлось обратно всем откатываться, потому что оказывается что фундепы сломали тайпчекер, как оно тесты-то прошло, бгггг". Очень хорошо идут вопросы из резюме кандидата (из №2) но в приложении к технологиям из №3: "а вот вы рассказывали что вы делали ХХХ, а как бы вы сделали тоже самое, но уже с использованием YYY, которое нам нужно?". Тут люди очень часто заводятся и начинают увлеченно "проектировать" ибо чувствуют себя в своей тарелке. Вообще говоря, на этом месте иногда можно и закончить и послать человеку оффер (ну или наоборот), если повезет.
В завершение, если человек декларирует знание английского, то переходим на него и пару технических вопросов обсуждаем на английском.

4. Даем тестовое задание. Лучше иметь несколько на выбор, если ваше "основное" слишком длинное. Но в любом случае тестовое задание не должно быть больше 8 часов при требуемом вами уровне квалификации, а лучше меньше. Идеально - 4-5. Если есть возможность - не говорить кандидату на этапе №2 сколько именно вы рассчитываете займет задание. Просто отделайтесь "небольшое" и попросите его на этапе №5 оценить время самому.
Я стараюсь иметь бюджет на оплату тестовых заданий и плачу по разумной рыночной ставке, чтобы человеку было не обидно и замечено что люди даже за небольшие деньги гораздо внимательнее относятся к выполнению, включается психологический паттерн "работа". Задание даю так, чтобы его можно было сделать за отведенное время аккуратно, без висящих соплей. Стараюсь давать из существующего проекта, либо что-то новое (поскольку заплачено, то не стыдно и использовать будет) либо уже существующее (зато есть reference implementation и можно отдать на глубокое ревью тому, кто писал оригинал). Задание должно быть вырезано из существующего проекта аккуратно и не требовать экзотического тулинга и строго заданных ОС. Человек будет делать задание из дома, а там у него может не быть рабочего окружения, а просто игровой компутер с виндой. Можно дать доступ на EC2 инстанс, где уже все готовое установлено, а потом его просто убить.
Я читал много завываний что вырезать из существующего проекта небольшое изолированное задание очень тяжело, но что-то мне подсказывает что это у людей проблемы с проектированием и управлением проектом. У меня таких проблем никогда не было.
Задача должна быть реальная, делать что-то полезное, а не сортировать массив пузырьком, прости господи.

5. Ревью задания с кандидатом. Почему вы сделали так, а не иначе, что бы вы сделали если бы было больше времени, покрытие тестами, точки интеграции в "большой" проект, то есть обычная рабочая рутина. Посмотреть как человек вертится, как и что предлагает, насколько хорошо оценивает риски, и т.д. Желательно конечно убедиться что задание компилируется, работает и делает что обещано :-)

6. Мой любимый вопрос: "представьте себе что я вам дал миллион долларов и вы можете его потратить на что угодно в области вычислительной техники, что вы сделаете?". Это не решающий вопрос, но много интересного может рассказать о кандидате. А может и нет, но обычно впендюриваю. Бывало что по результатам я усердно гуглил потом и мне раскрывались разные бездны.

7. Никаких, упаси господь, задач из области компутер саейнса, вы программистов нанимаете, а не компутерных сайентистов. Если человек хорошо знает алгебру, логику, теорию категорий, графов, игр - это будет написано у него в резюме.
Никакого программирования в реальном времени на собеседовании, вообще кандидат должен при таком предложении вежливо распрощаться, это бред сивой кобылы (ну, кроме случаев когда надо в боевом режиме так программировать и это соответственно оплачивается). Никакого тестирования "стрессоустойчивости" при этом не происходит, ну что за бред.
Можно порисовать диаграммки на доске если интервью личное.
Если у вас так уж пригорает на тему "формального тестирования", то разработайте квиз с парой десятков вопросов системы "выбор из 4-5 вариантов". Но это пустая трата времени.
Никаких вопросов про пол, ориентацию, семейное положение, возраст, детей, etc. Это правонарушение и даже если вы нанимаете в какую-нибудь условную Руанду, где это не так, все равно ведите себя цивилизованно. Допустимо задать вопрос про командировки, если это требуется.

Нигде не написано в какой момент надо пригласить в офис посмотреть в глаза и поговорить. Это зависит от массы факторов, удаленности, бюджета, etc. Чем ближе к концу тем ниже риск, очевидно. Само очное интервью - это что-то из №2 и №3, но с бОльшим числом людей. Я нанимаю как с очным интервью, так и чисто удаленно и никакой разницы по качеству набора не вижу.

Набираю я хорошо, это по-моему, лучшее что я научился делать за 25 лет в этом вашем IT. К сожалению, я надеялся что научусь большему.

Пост наверное через некоторое время уберу во френдз-онли ибо я тут под своим настоящим именем и незачем давать готовую инструкцию "по прохождению интервью".

Оставить комментарий

Популярные посты:

• Архив