Кейс «Трансстройбанк»: подбор пяти разработчиков и риск-менеджера

1. Первый разработчик собирает остальных. Проводить технические интервью регулярно в банке было некому: ИТ-департамент занят сопровождением вендорских систем, а ИТ-директор мог взять на себя только первые встречи. Поэтому первого Java-разработчика искали с двойным профилем: сильный инженер плюс готовность нанимать и выстраивать команду. На финале он разбирал с ИТ-директором банка план интеграционного слоя на первый год. После выхода он подключился к нашим техническим интервью, и для Backend и второго Java время от скрининга до решения сократилось почти вдвое.

2. Строить вокруг коробки. Многие сильные кандидаты ждали новый проект с чистого листа. Мы прямо описывали реальность: вендорская АБС и ДБО остаются, задача в том, чтобы строить вокруг них свои сервисы и адаптеры. На скрининге спрашивали: «у вендора нет нужного метода API, а функция нужна клиентам через месяц, ваши варианты». Кандидаты с опытом работы с банковскими коробками предлагали несколько рабочих путей. Кандидаты из чисто продуктовой разработки чаще предлагали «уговорить вендора».

3. Криптография и российские сертификаты. Банк переходит на российские сертификаты Минцифры, платёжные документы подписываются по ГОСТ, а работа с криптопровайдерами для многих разработчиков терра инкогнита. Мы разделили требование: для одного из Java-разработчиков опыт с электронной подписью по ГОСТ был обязательным, а для Backend это навык, которому можно научиться внутри. Иначе поиск растянулся бы на месяцы ради навыка, который нужен одному человеку в команде.

4. Мобильная разработка без чистого листа. Мобильные приложения банка работают на решениях поставщика, и кандидатам надо было объяснить, что их ждёт: сначала новые функции для бизнеса через доступные механизмы расширения (загрузка документов по ВЭД-сделке, статусы гарантий и заявок), затем собственные модули. Это проговаривали на первом же звонке. Поток кандидатов от этого сократился, но человек, который вышел, знал, на что идёт, и не ушёл через три месяца разочарованным.

5. Риск-менеджер для госконтрактов, а не для розницы. В кредите на исполнение госконтракта главный риск не в балансе заёмщика, а в том, исполнит ли он контракт: опыт аналогичных поставок, заказчик, сроки, аванс, концентрация на одном контракте, история в реестре недобросовестных поставщиков. Риск-менеджеры из розницы и скоринга здесь не подходят. При подборе риск-менеджера мы искали кандидатов в гарантийных подразделениях других банков и в факторинговых компаниях и давали кейс: поставщик просит гарантию по контракту 44-ФЗ с авансом 30%, что проверите и при каких условиях откажете. Кандидаты, которые начинали с анализа контракта, а не отчётности, шли на интервью в департамент риск-менеджмента.

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