Кейс «Байкал Сервис»: подбор семи IT-специалистов за 5 месяцев

1. «ИТ при складе». Многие разработчики представляли ИТ транспортной компании как 1С, Excel и поддержку пользователей на терминалах. Общие слова про масштаб и стабильность не помогали. Помогли вещи, которые кандидат может открыть сам: публичная документация API, модули для CMS, само приложение, отслеживание с фотографиями груза на этапах перевозки. Рекрутер на первом звонке давал ссылку на документацию и говорил: «вот этим будете заниматься, и у этого есть внешние пользователи». Для бэкендеров это работало сильнее любого описания.

2. Обратная совместимость как главный фильтр. Большинство кандидатов в Backend делали внутренние корпоративные системы, где все потребители API сидят в соседнем кабинете. В скрининг мы добавили вопрос: «в ответе калькулятора нужно поменять формат поля, а калькулятором через модули пользуются сотни интернет-магазинов; как вы это выпустите». Сильные кандидаты говорили про версионирование, период поддержки старого формата, мониторинг вызовов и уведомление интеграторов. Слабые предлагали «предупредить и поменять». Этот вопрос отсеял примерно треть тех, кто прошёл формальный скрининг по стеку.

3. Приложению уже шесть лет. Мобильное приложение работает с 2020 года, у него большая аудитория и своя история решений. Компании нужен был не человек, который в первый месяц предложит переписать всё на новом фреймворке, а разработчик, который умеет развивать живой продукт: аккуратно вводить новые сценарии (крупногабарит, новые статусы, уведомления), следить за стабильностью и выпускать релизы без провалов в рейтинге. На интервью спрашивали про самый неудачный релиз в карьере кандидата и о том, что он после него поменял в процессе. Ответ говорил больше, чем список технологий.

4. Данные из сотни с лишним филиалов. Данные по отправкам приходят из филиалов по всей стране: адреса, вес, габариты, статусы. Часть вводится вручную, ошибки неизбежны. Python-программист нужен, чтобы нормализовать и сверять эти данные, готовить выгрузки для партнёров и отчёты для операционного блока. Откликались в основном аналитики данных, которые хотели строить модели. Мы дали практическое задание: выгрузка на 2 000 строк с «грязными» адресами и габаритами, нужно предложить правила проверки и показать, как их автоматизировать. Ценили не красоту кода, а то, сколько видов ошибок человек нашёл сам.

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

6. Пауза между интервью и оффером. В крупной компании оффер требует нескольких согласований и проверки службой безопасности. В первый месяц от технического интервью до оффера проходило в среднем 19 дней, и за это время двое финалистов приняли другие предложения. Договорились с клиентом о трёх изменениях: фиксированные слоты технических интервью два раза в неделю, анкета для службы безопасности сразу после успешного технического интервью (с согласия кандидата), а не после финала, и еженедельный звонок каждому финалисту с честным статусом. Срок сократился до 9 дней, и до конца проекта на этом этапе мы больше никого не потеряли.