Приветствую коллеги. В данной статье я расскажу о своем опыте проведения технических скринингов разработчиков, о том как успешно внедрил их в одну из компаний, а также о результатах которых получил в итоге.
Что это и зачем?
Если вам знакомо ощущение, когда спустя 30 минут, после начала собеседования, коллеги активно пишут в корпоративном чате: "Заканчиваем", "Еще пару вопросов и хватит", а вам становится непонятно как кандидат дошел до технического собеседования на позицию Senior backend developer и при этом не может рассказать о том, что такое Dependency injection, чем отличаются друг от друга SQL и NoSQL, то у вас однозначно что-то идет не так. Возможно вам или HR стоит посмотреть в сторону внедрения скринингов, в flow найма.
Скрининг - это процесс, который помогает фильтровать кандидатов не доходя до основного технического собеседования. Обязательными условиями успеха являются сжатый тайминг и четкий набор вопросов предполагающий простые и быстрые ответы, которые точно отвечают на вопрос, подходит кандидат на открытую позицию или нет.
Проблематика и кейсы
Несколько лет назад, будучи разработчиком, мне часто приходилось присутствовать на собеседованиях. Порой я наблюдал следующую картину: в переговорке собиралось 3-6 человек (удаленка тогда еще не была мейнстримом), это могли быть team lead, архитектор, разработчики и даже product manager (что делал последний на техническом собеседовании, для меня до сих пор загадка, но не будем об этом).
Бывало, спустя непродолжительную беседу становилось понятно, что кандидат не подходит. И хорошо если собеседование прерывалось досрочно, но бывало этого не происходило и пустая трата времени всех участников встречи, в том числе и кандидата, продолжалась.
Уже тогда я понимал, что так быть не должно. На помощь тогда пришла HRD, она рассказала о таком замечательном процессе как скрининг (за что ей спасибо). Изначально я со скепсисом отнесся к этому предложению, потому как мне казалось, что скрининг применим лишь для вакансий с линейным персоналом, но забегая вперед, я был не прав. Да простят меня коллеги по цеху, но разработчики - это тот же линейный персонал, только в сфере IT и очень специфичный.
В течении года я пробовал новый для себя формат общения с кандидатами, изучал тонкости, подбирал вопросы, тайминг и прочее. Главное то, что этот процесс работал. Собеседования стали проводиться реже, а неподходящих кандидатов на них стало меньше.
...Спустя несколько лет, придя разработчиком в другую компанию, я увидел похожую ситуацию. На собеседованиях присутствовало до 10 человек, разработчики всей команды, архитектор, продакт, в общем 10 человек Карл!
Давайте посчитаем, общее время затрачиваемое одним участником равно времени самого собеседования (до 2-х часов), плюс подготовка к нему, обратная связь, вход и выход из рабочего контекста, а также один маленький кофе-брейк займут еще 1-2 часа. Получается каждый участник тратит около 3-4 часов рабочего времени.
Не сложно догадаться, что 10 человек потратят 30-40 часов. При этом, реалии рынка диктуют высокую стоимость времени IT специалистов, те каждое подобное собеседование влетает в хорошую копеечку для компании. А если допустить, что на них будут приходить кандидаты, которые точно не соответствуют требованиям вакансии, то это грозит серьезными потерями денег для компании.
Проблема ясна - пока на собеседование попадают "залетные" кандидаты, время сотрудников, а значит и деньги компании тратятся не лучшим образом.
Как сделать скрининг рабочим процессом?
Спустя десятки проведенных скринингов у меня сформировался список рекомендаций, соблюдая которые, думаю получится внедрить его в любую компанию с любым flow найма.
Определите границы
Перед тем как приступить к составлению вопросов, важно понять кто же тот супер герой который вам нужен, что он должен точно знать и уметь. Иными словами вам необходимо на основании портрета кандидата и требований описанных в вакансии, выписать все важные навыки, технологии и их уровень знаний которые вы точно ожидаете от кандидата, а если он не соответствует им, то вы точно не сможете продолжить общение с ним. При составлении вопросов необходимо в первую очередь отталкиваться от получившегося списка навыков и технологий.
Вопросы, коротко и по делу
Составить правильные вопросы, пожалуй это самая ответственная часть, которой следует обратить особое внимание, это ваш ключ к успеху. Вопросы должны быть по делу и не слишком объемными, вы должны четко понимать зачем каждый из них, действительно ли он соответствует списку требований к кандидату составленному в предыдущем пункте? Важно не забывать главную цель скрининга - это понимание того, готовы ли вы пригласить кандидата на полноценное техническое собеседование. В свою очередь это значит, что вопросы связанные с технологиями и навыками которые для вас не приоритетны, слишком узкие или наоборот слишком абстрактные, лучше приберечь для полноценного собеседования и не использовать на скрининге.
В моем плане скрининга присутствует около 20 вопросов. Вначале это как правило легкие и быстрые вопросы, далее появляются вопросы объемней и сложнее, в конце это может быть маленькая задачка или некий код в котором необходимо провести ревью тк в нем есть определенные недочеты. Вот примеры некоторых вопросов которые я использую:
1) Что такое Trait? В каких случаях ты его используешь?
2) Чем отличается абстрактный класс от интерфейса? Можно ли создать объект абстрактного класса?
3) Как изменить значение приватного свойство объекта?
4) Dependency inversion и Dependency Injection это синонимы? Объясни почему ты так считаешь.
5) Возможно ли при использовании MySQL и требовании минимального downtime добавить колонку в таблицу объемом 100Gb? Если возможно то как?
6) Как добавить колонку в коллекцию MongoDB? (вопрос с подвохом)
7) От коллеги тебе на ревью поступил данный код, что можешь сказать о нем?
8) Представь что у нас есть REST API и например в endpoint "/users/125" поступает большое количество запросов на PATCH. С какими проблемами мы можем столкнуться и как можно их побороть?
Тайминг, не более 30-40 минут
Тайминг - это вторая по важности вещь после правильных вопросов. Время обязательно должно быть ограничено. Ответы на вопросы не должны быть размером с том из "Война и мир", а если для полноценного ответа кандидату требуется продолжительное время (несколько минут), или тем более, таких вопросов много, то скорее всего стоит их пересмотреть, возможно подобным вопросам не место на скрининге.
Проговаривайте формат общения
Не стоит забывать, что для вашего собеседника слово скрининг может быть совершенно незнакомым, либо он может подразумевать под этим, нечто свое. Важно перед началом проговорить, формат в котором вы планируете общаться, тайминг и ваши ожидания от встречи.
Не извиняйтесь
Зачастую, в начале скрининга, я слышу от ведущего следующее:
"Судя по резюме ты крутой специалист, поэтому некоторые вопросы могут показаться тебе слишком легкими, сорян."
Подобные извинения являются серьезной ошибкой. Дело в том, что помимо проверки технических навыков, скрининг может проявить различные soft skills. В данном случае, если кандидат начинает возмущаться и показывать свое недовольство по причине того, что ему задают слишком легкие вопросы, то это повод задуматься, а нужен ли вам такой "гордый птыц", сможете ли вы сработаться с ним и его ЧСВ? Лично для меня подобные вещи - это уже важный звоночек, который нужно обязательно раскрыть на собеседовании.
Останавливайте кандидата
Если кандидат исчерпывающе ответил на вопрос, но при этом не может остановиться и продолжает развивать тему, или начинает офтопить, то не стесняйтесь прерывать его, так вы сэкономите ваше и его время. В объемных ответах совершенно нет никакого смысла.
Документируйте и делегируйте
Очень важно сделать процесс прозрачным и понятным не только для вас, важно чтобы любой член команды мог провести скрининг. Для этого нужно составить документ, который будет доступен команде, в нем должны быть описаны цели процесса, тайминг встречи, вопросы и предполагаемые ответы. Это позволит избежать "bus factor" так как все мы люди, нам свойственно болеть, ходить в отпуска, да и попросту выгорать. А если не делегировать, то последнее, с вероятностью 99% вам гарантированно, из-за того, что скрининги проходят довольно часто и каждый день будут занимать не мало времени у одного человека, тем самым будут выматывать.
HR не должен вести скрининг
Я сталкивался с желанием руководства сформировать универсальный скрипт скрининга, чтобы HR специалист мог в одиночку, без привлечения технического специалиста провести скрининг. Считаю, что так делать не стоит и этому есть несколько объяснений:
На один и тот же вопрос всегда можно ответить по разному;
Кандидат может ответить не целиком на весь вопрос, а только на его часть;
Отвечая на один вопрос, кандидат может ответить разом на несколько, поэтому задавать те вопросы на которые уже получен ответ, нет смысла;
Кандидат может волноваться и ему потребуется подсказать.
Ничего не хочу сказать плохого про HR, но думаю, что только технический специалист может дать грамотную оценку ответам на вопрос, либо помочь, подсказать, направить ответ в нужное русло.
Записывайте
Порой, я веду аудио или видео запись скрининга. Запись может потребоваться для формирования качественной обратной связи, так как могут появляться противоречия и потребность переслушать разговор, либо потребность запросить фидбек у членов команды. При этом, для соблюдения законности, в самом начале скрининга, необходимо получить согласие от всех участников на запись.
Скрининг не панацея
Я убежден в том, что к большинству специальностей в IT (особенно к техническим) можно успешно применять скрининг. Но все же не стоит делать из него панацею. Бывают случаи когда скрининг это совершенно точно - лишний шаг. К таким случаям я бы отнес то, когда вы уверены в навыках кандидата и у вас есть рекомендация которой вы можете доверять, также нет смысла проводить скрининг на специальности которые очень узкоспециализированные, а потенциальное количество кандидатов и так единицы.
В первую очередь скрининг - это процесс призванный экономить время сотрудников компании и не допускать на собеседования не релевантных кандидатов. Если же к вам на собеседование приходят исключительно релевантные кандидаты, (либо процент таковых стремится к 100%), при этом собеседования не занимают много рабочего времени, то у вас в компании и так все хорошо.
Метрики и выводы
Для того чтобы вышеописанное было подкреплено реальными метриками, давайте обратимся к статистике взятой из проекта, в который я успешно внедрил скрининги.
Ранее, все 100% кандидатов прошедших "Resume review" попадали на собеседование. После внедрения скрининга процент кандидатов, которые доходили до собеседования стал равен всего 34%, то есть 66% не проходили скрининг и дисквалифицировались из воронки найма.
Теперь давайте полученные из статистики данные переведем во что-то более понятное и очень дорогое - в рабочее время. Смоделируем следующую ситуацию:
наша компания не использует скрининги;
в воронку найма нам поступило 100 человек, а это 100 собеседований;
каждое собеседование занимает примерно 3 часа рабочего времени;
на собеседовании от компании будет присутствовать 4 человека.
Давайте посчитаем количество человеко-часов которые потребуются для проработки пула из 100 кандидатов.
В общем будет потрачено времени:
4 (чел) * 3 (часа) * 100 (собеседований) = 1200 чел. ч.
Если же в эти вводные добавить процесс скрининга, то итоговая картина сильно изменится в лучшую сторону.
Кол-во времени требуемое на скрининги:
1 (чел) * 1 (час скрининг и кофебрейк) * 100 (скринингов) = 100 чел. ч.Кол-во времени требуемое на собеседования:
4 (чел) * 3 (часа) * 34 (те кто успешно пройдут скрининг) = 408 чел. ч.В общем будет потрачено времени:
408 чел. ч + 100 чел. ч = 508 чел. ч.
Итого, как мы видим, в случае внедрения скринингов, экономия времени составит
692 человеко-часа.
Предлагаю вам посчитать какие затраты понесет ваша компания на оплату 692 часов сотрудников задействованных в собеседованиях, думаю, что получится очень внушительная сумма, которая возможно побудит пересмотреть flow найма.
P.S.: Надеюсь мне удалось показать ценность скринингов в процессе найма. С удовольствием отвечу на любые ваши вопросы в комментариях, буду рад конструктивной критике, а также историям из вашего опыта.
Спасибо за внимание.
