Техническое интервью является практически неотъемлемым этапом трудоустройства на ИТ-вакансию. Его цель состоит в первую очередь в оценке технических знаний и навыков кандидата. Его проводят, чтобы понять, насколько кандидат соответствует требованиям открытой вакансии.
О том, как проводить техническое интервью системного аналитика, сказано много. В интернете можно найти записи публичных интервью. Действующие системные аналитики запускают свои «школы» и консультируют «начинашек», рассказывают, как успешно пройти техническое интервью, причём иногда сразу на уровень middle/ middle+.
Разбор типовых вопросов и рекомендации по успешному прохождению остаются за бортом. Под катом я поделюсь опытом того, как из локального решения, подходящего для конкретной команды/системы/платформы, сделать унифицированное техническое интервью, работающее в масштабе департамента крупнейшего частного банка России. Данное решение позволяет сократить как время закрытия текущих вакансий, так и затраты на поддержание технического интервью, в частности, базы вопросов, в актуальном состоянии.
В чём проблема
До 2022 в Альфа-Банке существовала Дирекция разработки цифровых сервисов. Сотрудники Дирекции были объединены в Центры компетенций. Каждый выстраивал процессы, внедрял инструменты, отвечал за развитие сотрудников в рамках своей компетенции.
Структура хорошо подходила для решения открытых вопросов и развития сотрудников в рамках заданной компетенции. Все носители компетенции жили по единым правилам, использовали единые инструменты, обменивались опытом на общих встречах.
Например, если кандидат успешно прошёл техническое интервью на одну из вакансий центра компетенций, но ему по каким-то причинам не сделали оффер, то могли предложить другую вакансию без повторной оценки технических знаний и навыков. При наличии противоречий или конфликтов сотрудники решали их при поддержке руководителя центра компетенций — своего непосредственного руководителя, выступающего в роли арбитра.
Несмотря на свои достоинства, структура также обладала недостатками, которые мешали эффективному решению управленческих и бизнес-задач. Например, при наличии неустранённых командами развития дефектов в системах, развитием которых занималась Дирекция, поручения на их устранение часто падали на руководителей центров компетенций. Но сами руководители не обладали полным перечнем ресурсов для устранения дефектов.
Так, в распоряжении руководителя центра компетенций аналитики удалённых каналов доступа, из которого вышел автор, были только системные аналитики. Разработчики и QA-инженеры находились в других центрах компетенций. Поэтому для устранения дефектов требовалось дополнительное время на согласование с другими руководителями выделения необходимых ресурсов.
Также стоит отметить наличие большого числа заказчиков от бизнеса. От одного только корпоративного бизнеса было три ключевых заказчика: цифровой бизнес юридических лиц, малый и микробизнес, крупный инвестиционный бизнес. А про розницу я вообще молчу. Дирекции необходимо было отрабатывать запросы множества бизнес-заказчиков, причём точкой входа были либо руководители центров компетенций, которые не обладали достаточными ресурсами, как было указано выше, либо руководитель Дирекции, которого могло не хватать на все запросы.
С учётом имеющихся недостатков и сильного роста численности (в том числе из-за растущего количества запросов от бизнес-заказчиков) в 2022 была проведена реорганизация Дирекции. Появился Департамент разработки цифровых сервисов. На смену Центрам компетенций пришли Дирекции.
Теперь каждая Дирекция работает со своим бизнес-заказчиком. А в распоряжении руководителей внутри Дирекций появились кросс-функциональные команды, которые самостоятельно способны решать большой спектр задач, в том числе выполнять поручения на устранение выявленных дефектов. Фактически все команды развития, ответственные за системы, в полном составе были закреплены за соответствующими руководителями.
Новая структура позволила устранить недостатки предыдущей, однако она оказала не самое позитивное влияние на развитие компетенций. Внутри каждой Дирекции стали появляться свои правила и инструменты. Например, в Дирекциях начали появляться локальные правила проведения технического интервью.
Теперь, если кандидат успешно прошёл техническое интервью на вакансию в Дирекцию 1, но по какой-то причине ему не сделали оффер, чтобы претендовать на вакансию в Дирекцию 2, ему требовалось пройти ещё одну оценку технических знаний и навыков.
Более того, кейсы повторного интервью возникали даже внутри одной Дирекции. Как следствие — увеличение времени закрытия вакансий и недовольство кандидатов необходимостью прохождения очередной оценки, в ходе которой задают во многом похожие вопросы.
Мы прожили в данной ситуации весь 2023 год. В декабре на планировании инициатив по развитию компетенций технические лидеры системного анализа практически от всех Дирекций заявили, что техническое интервью «болит»: задания устаревают и требуют актуализации, команды используют разные подходы к оценке кандидатов, закрытие вакансий занимает слишком много времени. С этим надо что-то делать.
На этом месте внимательный читатель может стряхнуть пыль с шапки капитана:
«Тоже мне проблема! У вас были единые правила проведения технического интервью по компетенциям в старой структуре. Могли бы их и переиспользовать. Зачем изобретать велосипед?»
Переиспользование правил из старой структуры могло бы помочь решить обозначенную проблему для компетенций, носители которых были сосредоточены лишь в одном Центре компетенций. Однако в части системных аналитиков ситуация была сложнее: в старой структуре существовало несколько Центров компетенций с системными аналитиками, со своими правилами и инструментами. Чьё техническое интервью лучше? Какое переиспользовать?
Плюс в процессе реорганизации в новую структуру были включены системные аналитики из других подразделений банка, ранее не входившие в старую структуру. А они привыкли жить по своим правилам и использовать свои инструменты.
Всё сводилось к тому, что старые решения нам не подходили. Требовалось что-то новое.
Как решали
Внедрение изменений в крупной организации требует времени. И описанная проблема не исключение. Её решение заняло целых четыре квартала (этапа) — считайте, весь 2024 год. На каждом этапе своя цель и образ результата. Далее кратко по ним пройдусь.
Этап I. Создание модели
На первом этапе была сформирована рабочая группа. В неё вошли представители большинства Дирекций. Основная цель состояла в разработке унифицированной модели оценки технических знаний и навыков, которая покрывала бы всех системных аналитиков Департамента.
Для этого были проанализированы существующие материалы (профили системных аналитиков, существующие варианты технических интервью, модель компетенций). По результатам анализа было выделено четыре интересующих нас блока знаний:
-
Требования и нотации.
-
Архитектура и интеграции.
-
Базы данных.
-
Безопасность.
Для каждого блока рабочая группа сформировала набор теоретических вопросов и практических задач. Каждый элемент был сопоставлен с одним из трёх технических уровней: junior, middle, senior. Чтобы подтвердить уровень, кандидат должен справляться с вопросами и задачами этого уровня.
Этап II. Валидация модели внутри
Второй этап состоял в валидации вопросов и задач модели: понятно ли они сформулированы, соответствуют ли заявленному техническому уровню, достаточно ли их для оценки знаний и навыков системного аналитика.
Для ответа на поставленные вопросы мы привлекли действующих интервьюеров и системных аналитиков, которые интервью не проводят, и попросили их провалидировать унифицированную модель. В результате было проведено две волны технических интервью, собрана обратная связь от участников, внесены изменения в вопросы и задачи.
Примечание: важно было не ухудшить текущий опыт интервьюеров при проведении технического интервью.
Этап III. Апробация модели вовне
С подключением рекрутеров унифицированная модель оценки знаний и навыков системного аналитика была апробирована на кандидатах, откликнувшихся на открытые вакансии банка. Этап во многом напоминал предыдущий, за исключением того, что кандидаты были внешними, а интервью — боевым.
Особенностью работы с вакансиями в нашем подразделении является завязка на интегральную оценку технического уровня (junior, middle, senior) без её разбивки по компонентам. Поэтому был предложен алгоритм определения общего уровня кандидата на основе оценок по блокам знаний.
Алгоритм: Каждому техническому уровню присваивается число: junior — 1, middle — 2, senior — 3. Итоговая оценка есть сумма оценок по блокам знаний, делённая на количество блоков с учётом стандартного правила округления. Например, при оценках кандидата
Senior, Middle, Senior, Junior, его итоговая оценкаMiddle: (3 + 2 + 3 + 1) / 4 = 2,25.
В процессе апробации модель показала достаточно неплохое распределение кандидатов: одна половина из них оказалась специалистами уровня Middle и Senior, другая — Junior и Intern.
Примечание: Оценка Intern означает, что кандидат не справился с вопросами и задачами уровня Junior.
Также интервьюеров просили оставить субъективные оценки кандидатов. Эти оценки на 70% совпали с моделью, а в 27% присутствовали незначительные отклонения, выраженные в добавлении плюсов и минусов к уровням: «Этот кандидат уже перерос Junior, но немного не дотягивает до Middle, поэтому моя оценка — Junior+/Middle-».
Этап IV. Добавление технического профиля
Использование универсальной модели неизбежно приводит к размытию специфики конкретной команды/системы/платформы. В результате кандидат, успешно прошедший техническое интервью на вакансию заданного уровня, не всегда оказывается релевантным самой вакансии. Для наглядности приведу пример.
Рассмотрим две вакансии. Одна — в команду, занимающуюся развитием API для внешних партнёров банка. К решениям, выставленным наружу, предъявляются повышенные требования информационной безопасности, поэтому успешный кандидат на позицию системного аналитика уровня Middle должен обладать знаниями и навыками в информационной безопасности на уровне не ниже Middle. Вместе с тем высокого уровня по базам данных от него не требуется, достаточно уровня Junior.
Вторая вакансия в команду, занимающуюся развитием одной из бэк-систем. Ожидается, что системный аналитик будет активно работать с базой данных, писать запросы на выборку данных, даже иногда разрабатывать хранимые процедуры. В этом случае от успешного кандидата уровня Middle ожидаются знания и навыки по базам данных на уровне не ниже Middle. Что касается информационной безопасности, ему достаточно продемонстрировать хотя бы уровень Junior.
Пусть по остальным темам для обеих вакансий нужно получить оценку Middle. Тогда рассматриваемые вакансии в команду развития API для внешних партнёров (Middle SA API) и в команду развития бэк-системы (Middle SA Back) можно представить множествами оценок:
-
Middle SA API = (
Middle, Middle, Junior, Middle). -
Middle SA Back = (
Middle, Middle, Middle, Junior).
Если оперировать только одной интегральной оценкой Middle, то с учётом вышеописанного алгоритма на обе вакансии могут предлагать нерелевантных кандидатов, например, Middle SA Applicant = (Senior, Middle, Junior, Junior) не подходит ни на одну из двух вакансий.
Также кандидат, прошедший по нижней границе на вакансию Middle SA API, не пройдёт на вакансию Middle SA Back из-за несоответствия требованиям по базам данных. И наоборот, успешный кандидат на вакансию Middle SA Back не пройдёт на первую вакансию из-за несоответствия требованиям по информационной безопасности.
Всё это привело к добавлению в модель технических профилей системных аналитиков. Технические профили зависят от технического уровня и системы, развитием которой будет заниматься системный аналитик. Фактически они представляют собой требования к аналитику, указываемые на этапе создания вакансии, по аналогии с указанием общего технического уровня.
На этапе технического интервью происходит проверка соответствия знаний и навыков кандидата техническому профилю:
-
Если кандидат по каждому блоку знаний получил оценку равную или выше оценке технического профиля, он проходит дальше.
-
В противном случае рекрутеры прекращают процессинг кандидата на данную вакансию и пытаются подобрать ему новую с учётом результатов технического интервью.
Что получили
Подводя итог, можно сказать, что получившаяся модель позволяет:
-
Учитывать специфику конкретной команды/системы/платформы за счёт добавления технического профиля.
-
Передавать успешных кандидатов между Дирекциями и направлениями внутри одной Дирекции без необходимости в повторной оценке технических знаний и навыков.
-
Сократить затраты на поддержание вопросов и задач технического интервью в актуальном состоянии за счёт работы с единой базой вопросов и задач, а не с множеством локальных решений, задания в которых часто перекликаются между собой.
В конце 2024 года мы запросили данные по среднему времени закрытия вакансий у наших рекрутеров. Их анализ показал, что подразделения, использующие передачу кандидатов (рассмотрение кандидатов без повторного проведения технического интервью), закрывают вакансии на 24–37% быстрее. А это значительное вэлью для бизнеса: теперь опытные специалисты могут тратить меньше времени на проведение технических интервью, уделяя больше внимания работе в командах и техническому развитию.
Примечание: Конечно, мы не утверждаем, что именно внедрение унифицированной модели оценки знаний и навыков системного аналитика позволило получить такой выигрыш во времени. Скорее, сыграла совокупность факторов. Однако положительная закономерность прослеживается.
В настоящее время в рамках плана развития компетенции на 2025 модель раскатывается на весь Департамент. В перспективе планируем охватить ею все ИТ-подразделения банка.
Таков наш опыт унификации технического интервью системного аналитика. Если вы сталкивались с подобной проблемой или пытались внедрить похожее решение, поделитесь в комментариях. Это будет полезно.
Статьи, которые могут быть интересны:
-
Как у нас почти получилось сделать автономного робота для «Битвы Роботов»
-
Куда и как развиваться системному аналитику, если «потолок» уже близко
Подписывайтесь на блог и Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.
Автор: alobzov
