От найма до увольнения — один пулл реквест

Меня зовут Давид Шекунц и последние 6 лет я помогаю IT-проектам. Сегодня хочу поделиться историей, как мне пришлось за 2 дня нанять специалиста, а на 4-ый день уволить. Я расскажу, как быстро проводить интервью и что может стать причиной незамедлительного расторжения отношений.

Ситуация была критической: нужно было срочно помочь друзьям на одном проекте. Решили нанять удаленных разработчиков.

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

Немного ловкости рук и мы нашли десяток кандидатов.

Вот такого рода сообщение я писал людям:

Запомните очень важное правило: всегда говорить и спрашивать тонкие вещи в первых же сообщениях.

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

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

Созваниваемся и общаемся с разработчиком минут 10-15.

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

Не надо тратить много времени на рассказ о своем проекте, если человек об этом не просит. Я очень не люблил, когда созванивался с работодателем и слушал час о его проекте на первом созвоне. Это просто трата времени и появляется ощущение, что они в себе не уверены. Если мне интересно, я сам все спрошу ИЛИ поговорим на 2-3 звонке.

Главное, чтобы человек показался адекватным и не было явных звоночков. Если все ок, то выходим на третий этап.

В данной конкретной ситуации у меня был только один вариант: услышать разбор одного из кейсов разработчика.

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

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

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

Если тут все проходит успешно, то остается последний этап.

До этого этапа стоит довести одновременно x2-3 больше разработчиков, чем вам нужно, потому что уже тут остается подытожить готовность, стоимость, сроки оплаты и вводить кого-то в курс дела.

Конечно, на этом этапе уточняем про тестовый период. Основная идея этого периода — можно расстаться день в день. Обычно это от 3-х дней, до 2 недель. Позже этого срока у человека уже появляется такая ответственность на проекте, что расставаться день в день невыгодно для всех.

Тестовое для уровня выше Middle- не работает. Реальное тестовое я даю только, когда беру на работу Junior или не верю в человека. Если он выполнит тестовое, тогда я в него поверю и готов буду рассмотреть.

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

На том проекте, до конца собеседований дошло 4 человека, из них 2-х мы могли взять и как раз 2 человека подходили. Остальные были гораздо дороже.

Один кандидат по ощущениям Middle+, второй Middle-. Каждый по 10$ в час. Оба живут не в России.

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

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

Когда мы начали работу, уже на второй день стало ясно несколько вещей:

Во-первых, его PR нужно было сильно править, потому что они были с кучей логических ошибок.

Во-вторых, PR часто не работали или не решали задачу так, как это было описано в карточке Trello.

В-третьих, у него были большие проблемы даже со знанием самого JS: использование filter и map без присвоения, везде «new Promise» без причины, незнание команды throw и так далее.

Да, возможно, проблема была не в нем, а в нашем менеджменте или скорости, но есть два «НО»:

(1) Второй разработчик, который сам признался, что считал себя менее опытным, справлялся очень хорошо

(2) Неважно с кем конкретно возникла проблема, важно, что она возникла в нашем совместном взаимодействии.

Мы разошлись на четвертый день работы.

Сразу скажу это нелегко… это всегда нелегко. Особенно, когда понимаешь, что перед тобой добрый и ловкий человек. Но времени на разбирательства не было.

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

Последствиями стало то, что кроме потери человека, мы себя немного деморализовали.

Жалею ли я, что нанял его? Нет, это было правильное решение, все указывало на то, что надо было так поступить.

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

Второй программист до сих пор успешно работает на том проекте, что меня очень радует.

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

Если вы несогласны с какой-то точкой зрения, тоже добро пожаловать в подкат.

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