Никита Воронов: Be a rockstar
Плохие способы собеседовать разработчика
- Хард скрининг, в процессе которого рекрутер просто задает кандидату вопросы с листочка и сверяет ответы. Единственное, что проверяет этот способ — то, насколько уверенно кандидат отвечает на вопросы. При этом адекватность человека можно понять и по общению в почте, а для оценки знаний лучше смотреть в Гитхаб или CV.
- Тестовые задания, потому что они не дают возможности объективно оценить умения разработчика. Большую часть времени разработчик сопровождает код, а не пишет его с нуля. К тому же, плохое выполнение тестового может быть связано с недостатком знаний о продукте или времени на выполнение.Если разработчик отказывается от тестового задания — это значит, что он уже достаточно опытный, чтобы понимать неэффективность такого метода.
- Вайтбординг, во время которого разработчика просят написать код на маркерной доске или специальном сервисе без вспомогательных инструментов. Задача этого способа— лишить разработчика привычных инструментов. Но то, какими инструментами умеет пользоваться разработчик, тоже важно. Итоговый код, написанный в таких условиях, не дает понять, всегда ли разработчик так пишет или только в сложных условиях.
- Брейнтизеры — абстрактные задачи на логику. Недостаток этого метода в том, что к десятому собеседованию легко выучить все ответы и просто повторять их каждому рекрутеру. Такие задачи подвешены в вакууме — можно понять мышление разработчика, но не понятно, насколько хороший он специалист. Это непривычные задачи, а компании не ищут разработчика, для которого все задачи будут в новинку.
- Тесты — это вопросы по специальности, но задают их разработчики, а не рекрутеры. К десятому собеседованию нормальный разработчик выучит ответы. При этом большинство из этих вопросов можно не задавать напрямую, а сделать это в обычном общении.
Хорошие способы собеседовать разработчика
- Решение реальных задач из тех, которые уже были реализованы в компании. Не обязательно, чтобы кандидат предложил такое же решение — главное посмотреть на то, какие методы он использует и что предлагает. Это помогает понять образ его мышления и оценить бэкграунд. А у самого кандидата есть возможность познакомиться с будущими задачами.
- Свободное общение с разработчиком. Это может звучать банально, но простой рассказ о себе и о своем опыте действительно хорошо работает. Так рекрутер может понять бэкграунд кандидата, его вовлеченность и коммуникационные навыки.
- Код-ревью. Для такого собеседования нужно взять реальный код компании или написать новый — так, чтобы в нем учитывались задачи, ради которых вы нанимаете разработчика.
Правила хорошего тона в коммуникации с разработчиком
- Не отказывайте кандидату сразу, даже если он провалил собеседование. Лучше дать ответ на следующий день, чтобы разработчик понимал, что над решением думали, а не приняли его моментально.
- На собеседовании уточните у кандидата, нужен ли ему фидбек. Если да, то вне зависимости от решения о приеме на работу, расскажите о сильных и слабых местах. Идеально, если слабые места будут сопровождаться ссылками на материалы по теме — чтобы человек мог расти и развиваться.
Виталий Калинин: Какие люди нужны скрам-команде или еще раз про soft skills
В отделе разработки «Додо Пиццы» 71 человек и 0 руководителей. Работники сами формируют бэклог, выбирают архитектурные решения и разбираются с приоритетами задач. При этом бизнес доверяет разработке принятие таких решений, но может указать на какие-то важные вопросы.
Есть исследование, которое показывает прогностическую валидностью методов оценки. Самые высокие показатели — у тестового задания (0,54) и структурированного интервью (0,51). Это значит, что кандидат, отобранный этими методами, подойдет примерно в половине случаев.
В «Додо Пицце» совместили два этих метода. Для структурированного интервью понадобилось составить свой фреймворк.
- Определили, что оценивать. Для этого опросили сотрудников и выделили важные характеристики, которые должны быть у кандидатов. После этого CTO оценил весь отдел разработки по шкале от 5 до 10 по этим же критериям — чтобы понять, какие из них играют наибольшее значение в нынешней команде. Учитывали и срок работы компании — это помогло оценить, какие навыки должны быть у нового сотрудника, а какие формируются благодаря команде.
- Определить, как оценить. Для этого разработчиков попросили рассказать о реальных паттернах, которые демонстрируют эти компетенции в работе.
- Подобрать нужные вопросы. Важно, чтобы вопросы не звучали в лоб и не показывали кандидату, что именно от него хотят услышать. Поэтому в «Додо Пицце» решили использовать систему кейсовых интервью. В кейсе сначала узнают полный контекст, затем цель, действия и результат. Параллельно фиксируют, какие паттерны поведения кандидат демонстрировал в той или иной ситуации.
- Оценить результаты. На этом шаге эйчар группирует все плюсы и минусы кандидата и оценивает их общий вес.
Метод структурированного интервью эффективен примерно в 50% случаев, поэтому в «Додо Пицце» его комбинируют с тестовым днем. Обычное тестовое задание не подходит, так как по его итогам появляется еще больше вопросов у обеих сторон, а разработчики часто отказываются выполнять подобные тесты.
Во время тестового дня разработчик приходит в команду «Додо Пиццы» на 5-6 часов. К нему прикрепляется работающий член команды, который проводит его по рабочему процессу: от стендапа до решения реальных задач из бэклога.
Такой способ выгоден и для компании, и для кандидата: рекрутер может оценить, насколько эффективно разработчик работает в реальной среде, а кандидат понимает, что его ждет.
За полтора года использования этого метода в команду «Додо Пиццы пришли более 40 разработчиков. При этом трое разработчиков из старой команды покинули компанию, а ошибка найма случилась всего один раз.
Ярославна Медведева: Оценка разработчиков глазами компаний vs разработчиков
Общие проблемы оценки разработчиков
- Нет стандартизации на рынке: в большой технологической компании и мелкой веб-студии по-разному определяют компетенции сениор-разработчика, но называют его одинаково;
- Нет единых целей, метрик, критериев оценки в разработке — у каждого человека свои представления о том, чем должен заниматься разработчик определенного уровня. Эти представления могут различаться даже внутри самой компании;
- Интуитивная оценка кандидатов и сотрудников. Из-за того, что нет четко определенных правил оценки компетенции и уровня, это делается «на глаз».
Проблемы оценки разработчиков со стороны руководителей разработки
- Отсутствие единых KPI между разными отделами разработки;
- Ограниченность представлений о необходимом уровне знаний собственной личностью, знаниями и опытом;
- Hard skills не оцениваются «вширь», как совокупность знаний и навыков;
- Вынесение вердиктов по кандидату без правильной оценки soft skills;
- Стереотипы по отношению к HR.
Проблемы оценки разработчиков со стороны эйчаров
- Мало кто из эйчаров разбирается в процессах разработки, поэтому они не могут структурировать требования и критерии, унифицировать их для компаний и помочь руководителям разработки с оценкой hard и soft skills кандидатов в соответствии с уровнем разработчика.
Проблемы самооценки разработчиков
- Инфополе, которое говорит о том, что сениор разработчиком можно стать после прохождения месячного курса — из-за этого кандидаты неадекватно оценивают свой уровень;
- Бедный инструментарий для самостоятельной оценки — не существует тестов и экзаменов, которые помогли бы оценить уровень разработчика;
- Экстраполяция тестовых заданий на деятельность в компании — разработчики считают, что если они справились с тестовым заданием, значит смогут решить любые проблемы разработки;
- Недостаток soft skills: разработчики хотят вырасти в тим-лида или менеджера продукта, но при этом не знают о «не-технических» компетенциях и навыках, которые для этого нужны;
- Рынок перегрет, поэтому даже за слабого разработчика начинается борьба — это тоже способствует неоправданному завышению самооценки.
Что делать эйчарам для решения этих проблем
- Открыто говорить на собеседованиях о специфике корпоративной культуры и требованиях к soft skills;
- Записывать все, что обсуждается на собеседование — позже это поможет сформулировать критерии оценки совместно с руководителем разработки;
- Аргументируйте руководителям компании и разработки необходимость унификации требований к уровням по всем навыкам;
- Создавайте карьерный путь до сениоров и выше, с четко определенными критериями и условия роста;
- Проверяйте, чтобы тестовые задачи соответствовали искомому уровню, охватывали максимальный спектр требующихся навыков и не отпугивали лучших кандидатов.
