Приветствую коллеги.
В этой статье я расскажу о своем опыте проведения технических проверок разработчиков, о том, как я их успешно реализовал в одной из компаний, а также о результатах, которые я получил в итоге.
Что это и почему?
Если вам знакомо ощущение, когда через 30 минут после начала собеседования коллеги активно пишут в корпоративном чате: " Давайте закончим ", " Еще пара вопросов и хватит » и вам становится непонятно, как кандидат попал на техническое собеседование на должность Senior backend разработчика и при этом не может рассказать о том, что это такое Внедрение зависимости чем они отличаются друг от друга SQL И NoSQL , то с вами точно что-то не так.
Возможно, вам или отделу кадров следует подумать о введении проверок в процесс найма.
Скрининг это процесс, который помогает фильтровать кандидатов перед основным техническим собеседованием.
Обязательными условиями успеха являются сжатые сроки и четкий набор вопросов, требующих простых и быстрых ответов, которые точно отвечают на вопрос, подходит ли кандидат на открытую позицию или нет.
Проблемы и случаи
Несколько лет назад мне, как разработчику, часто приходилось ходить на собеседования.Иногда я наблюдал такую картину: на совещании собиралось 3-6 человек (удаленная работа еще не была мейнстримом), это мог быть тимлид, архитектор, разработчики и даже продакт-менеджер (то, что делал последний во время технического собеседования, — для меня до сих пор загадка, но не будем об этом).
Иногда после короткого разговора становилось понятно, что кандидат не подходит. И хорошо, если собеседование прерывалось досрочно, но иногда этого не происходило и трата времени всех участников встречи, включая кандидата, продолжалась.
Уже тогда я понимал, что так быть не должно.
Тогда на помощь пришел HRD; она рассказала о таком замечательном процессе, как скрининг (за что ей спасибо).
Изначально я отнесся к этому предложению скептически, так как мне казалось, что отбор применим только для вакансий с линейным персоналом, но, забегая вперед, я ошибался.
Да простят меня коллеги, но разработчики — это тот же линейный персонал, только в IT-сфере и очень специфический.
В течение года я пробовал новый формат общения с кандидатами, изучал тонкости, подбирал вопросы, сроки и т. д. Главное, чтобы этот процесс работал.
Собеседования стали реже, а неподходящих кандидатов стало меньше.
.
Несколько лет спустя, когда я присоединился к другой компании в качестве разработчика, я увидел похожую ситуацию.
На собеседованиях присутствовало до 10 человек, разработчики всей команды, архитектор, продакт-менеджер, всего 10 человек Карл! Давайте подсчитаем, общее время, потраченное одним участником, равно времени самого собеседования (до 2 часов), плюс подготовка к нему, обратная связь, вход и выход из рабочего контекста, а также один небольшой перерыв на кофе займет другой.
1-2 часа.
Получается, что каждый участник тратит около 3-4 часов рабочего времени.
Нетрудно догадаться, что 10 человек проведут 30-40 часов.
В то же время реалии рынка диктуют высокую стоимость времени ИТ-специалистов; каждое такое интервью обходится компании в копеечку.
А если предположить, что к ним придут кандидаты, точно не соответствующие требованиям вакансии, то это грозит компании серьезными денежными потерями.
Проблема ясна - Пока «заблудшие» кандидаты проходят собеседования, время сотрудников, а значит и деньги компании, тратятся не лучшим образом.
Как сделать скрининг рабочим процессом?
После десятков просмотров у меня сформировался список рекомендаций, следуя которым, думаю, можно будет внедрить его в любой компании с любым потоком найма.
Определить границы
Прежде чем начать писать вопросы, важно понять, кто такой супергерой, который вам нужен, что он должен знать и уметь.Другими словами, вам необходимо, исходя из портрета кандидата и требований, описанных в вакансии, записать все важные навыки, технологии и уровень их знаний, которые вы точно ожидаете от кандидата, и если он им не соответствует, тогда вы точно не сможете продолжать с ним общение.
При составлении вопросов необходимо в первую очередь отталкиваться от полученного списка навыков и технологий.
Вопросы коротко и по делу
Составление правильных вопросов – это, пожалуй, самая важная часть, на которую вам следует обратить особое внимание, это ваш ключ к успеху.Вопросы должны быть по существу и не слишком длинными, вы должны четко понимать, зачем каждый из них нужен, действительно ли он соответствует списку требований к кандидату, составленному в предыдущем пункте? Важно не забывать главную цель скрининга — понять, готовы ли вы пригласить кандидата на полноценное техническое собеседование.
В свою очередь, это означает, что вопросы, связанные с технологиями и навыками, которые не являются для вас приоритетными, слишком узкими или, наоборот, слишком абстрактными, лучше отложить для полноценного собеседования и не использовать при отборе.
Мой план проверки содержит около 20 вопросов.
Сначала это обычно легкие и быстрые вопросы, затем появляются более крупные и сложные вопросы, в конце концов это может быть небольшая задача или какой-то код, который нужно пересмотреть, поскольку он имеет определенные недостатки.
Вот примеры некоторых вопросов, которые я использую:
1) Что такое черта? В каких случаях вы его используете? 2) В чем разница между абстрактным классом и интерфейсом? Можно ли создать объект абстрактного класса? 3) Как изменить значение частной собственности объекта? 4) Являются ли инверсия зависимостей и внедрение зависимостей синонимами? Объясните, почему вы так думаете.5) Можно ли при использовании MySQL и необходимости минимального простоя добавить столбец в таблицу размером 100Гб? Если возможно, то как? 6) Как добавить столбец в коллекцию MongoDB? (хитрый вопрос) 7) Коллега прислал вам этот код на проверку, что вы можете о нем сказать? 8) Представьте, что у нас есть REST API и, например, конечная точка «/users/125» получает большое количество запросов на PATCH. С какими проблемами мы можем столкнуться и как их преодолеть?
Хронометраж, не более 30-40 минут.
Время — вторая по важности вещь после правильных вопросов.Время должно быть ограничено.
Ответы на вопросы не должны быть размером с том из «Войны и мира», а если кандидату нужно много времени (несколько минут), чтобы полностью ответить, или тем более, таких вопросов очень много, то, скорее всего, стоит их пересмотреть; возможно, таким вопросам не место при проверке.
Озвучьте формат общения
Не забывайте, что слово «скрининг» может быть совершенно незнакомо вашему собеседнику, либо он может подразумевать под этим что-то свое.Прежде чем начать, важно обсудить формат, в котором вы планируете общаться, сроки и ваши ожидания от встречи.
Не извиняйся
Часто в начале показа я слышу от ведущего следующее: " Судя по вашему резюме, вы крутой специалист, поэтому некоторые вопросы могут показаться вам слишком простыми, извините." Подобные извинения являются серьезной ошибкой.
Дело в том, что помимо проверки технических навыков скрининг позволяет выявить различные мягкие навыки.
В этом случае, если кандидат начинает возмущаться и показывать свое недовольство тем, что ему задают слишком легкие вопросы, то это повод задуматься, нужна ли вам такая «гордая птица», можно ли с ним работать и его резюме.
? Лично для меня подобные вещи уже являются важным сигналом, который необходимо раскрыть на собеседовании.
Остановите кандидата Если кандидат исчерпывающе ответил на вопрос, но не может остановиться и продолжает развивать тему, либо начинает уходить не по теме, то не стесняйтесь перебивать его, так вы сэкономите свое и его время.
Длинные ответы вообще не имеют смысла.
Документирование и делегирование Очень важно сделать процесс прозрачным и понятным не только для вас, важно, чтобы проверку мог провести любой член команды.
Для этого вам необходимо составить документ, который будет доступен команде; в нем должны быть описаны цели процесса, время проведения встречи, вопросы и ожидаемые ответы.
Это позволит вам избежать «фактора автобуса», поскольку все мы люди, склонны болеть, ездить в отпуск и просто выгорать.
А если вы не делегируете, то последнее с вероятностью 99% вам гарантировано, в связи с тем, что просмотры проходят довольно часто и каждый день будет отнимать у одного человека довольно много времени, тем самым утомляя его.
.
HR не должен проверять Я столкнулся с желанием руководства создать универсальный сценарий скрининга, чтобы HR-специалист мог проводить скрининг самостоятельно, без привлечения технического специалиста.
Я считаю, что этого делать не следует и этому есть несколько объяснений:
- На один и тот же вопрос всегда можно ответить по-разному;
- Кандидат может ответить не на весь вопрос, а только на его часть;
- Отвечая на один вопрос, кандидат может ответить сразу на несколько, поэтому нет смысла задавать те вопросы, на которые уже были даны ответы;
- Кандидат может нервничать, и ему потребуется некоторое руководство.
Записывать
Иногда я делаю аудио- или видеозапись показа.Запись может потребоваться для формирования качественной обратной связи, так как могут возникнуть противоречия и необходимость повторного прослушивания разговора, либо необходимость запросить обратную связь у членов команды.
При этом для соблюдения закона в самом начале показа необходимо получить согласие всех участников на запись.
Скрининг – не панацея Я убеждён, что скрининг можно успешно применить к большинству ИТ-специализаций (особенно технических).
Но все же не стоит делать из этого панацею.
Бывают случаи, когда проверка является абсолютно дополнительным шагом.
Я бы включил такие случаи, когда вы уверены в навыках кандидата и у вас есть рекомендация, которой можно доверять; нет также смысла проводить отбор по очень узкоспециализированным специальностям, а потенциальное число кандидатов уже составляет единицы.
Прежде всего, отбор – это процесс, призванный сэкономить время сотрудников компании и не допустить присутствия на собеседовании нерелевантных кандидатов.
Если к вам на собеседования приходят только релевантные кандидаты (или процент их стремится к 100%), и собеседования не отнимают много рабочего времени, то в вашей компании все в порядке.
Метрики и выводы
Чтобы сказанное подтверждалось реальными метриками, обратимся к статистике, взятой из проекта, в котором я успешно реализовал скрининги.
Раньше все 100% кандидатов, прошедших «Просмотр резюме», попадали на собеседование.
После введения скрининга процент кандидатов, дошедших до собеседования, стал всего 34%, то есть 66% не прошли скрининг и были дисквалифицированы из воронки найма.
Теперь переведем данные, полученные из статистики, во что-то более понятное и очень затратное – в рабочее время.
Смоделируем следующую ситуацию:
- наша компания не использует отсевы;
- Мы приняли в воронку подбора 100 человек, что означает 100 собеседований;
- каждое собеседование занимает около 3 часов рабочего времени;
- На собеседовании от компании будут присутствовать 4 человека.
В целом время будет потрачено: 4 (человека) * 3 (часа) * 100 (интервью) = 1200 человек.Если мы добавим к этим исходным данным процесс отбора, конечная картина сильно изменится в лучшую сторону.час
Количество времени, необходимое для просмотра: 1 (человек) * 1 (часовой показ и кофе-брейк) * 100 (показы) = 100 человек.Итого, как мы видим, если ввести скрининги, экономия времени будет 692 человеко-час.час Количество времени, необходимое для собеседований: 4 (человека) * 3 (часа) * 34 (успешно прошедших отбор) = 408 человек.
час В целом время будет потрачено: 408 чел.
ч + 100 чел.
ч.
= 508 чел.
ч.
Предлагаю вам посчитать, какие затраты понесет ваша компания на оплату 692 часов сотрудников, задействованных на собеседованиях, думаю, что вы получите весьма внушительную сумму, которая может побудить вас пересмотреть свой поток найма.
P.S. : Надеюсь, мне удалось продемонстрировать ценность проверок при приеме на работу.
Буду рад ответить на любые ваши вопросы в комментариях, буду рад конструктивной критике, а также историям из вашего опыта.
Спасибо за внимание.
Теги: #Разработка стартапов #HR #Карьера в IT-индустрии #Интервью #Финансы в IT #Управление персоналом #Статистика в IT #найм в IT #HR-процесс #найм персонала #найм разработчиков #HR-технологии #найм #скрининг #найм программистов
-
Программное Обеспечение Сапр
19 Oct, 24 -
Новости Игровой Индустрии (11-25 Марта 2019)
19 Oct, 24 -
Проект Тукан
19 Oct, 24 -
Codraw — Стартап За Неделю
19 Oct, 24 -
Обновление Windows Xp И Права Пользователя.
19 Oct, 24 -
Представляем Kohana 3.0 — Части 7, 8, 9
19 Oct, 24 -
Луч Ненависти – На Этот Раз Билайн
19 Oct, 24
