HR-блог про IT рекрутинг от ИТ Кадрового агентства

Подбор Backend-разработчика: как проверить опыт до технического интервью

Управление персоналом Вопросы для собеседования
Подбор Backend-разработчика часто начинается с длинного списка языков, баз данных и инфраструктурных инструментов. Но наличие ключевых слов в резюме не показывает, какие системы человек создавал, какие решения принимал и насколько его опыт соответствует будущей задаче.
До технического интервью можно проверить значительную часть контекста: тип продукта, архитектуру, нагрузку, базы данных, интеграции, production-ответственность и личный вклад. Это не технический экзамен и не попытка заставить рекрутера изображать архитектора. Задача — отделить релевантный опыт от поверхностного совпадения.
Ниже разобраны критерии первичной оценки Backend-разработчика и вопросы, которые помогают подготовить качественное представление для команды.

Сначала определите тип Backend-роли

Backend-разработчик в платёжном продукте, игровой платформе, маркетплейсе и внутренней корпоративной системе решает разные задачи. Даже одинаковый язык программирования не делает опыт автоматически взаимозаменяемым.
Важно определить, что будет занимать основную часть работы: бизнес-логика, API, высоконагруженные сервисы, интеграции, данные, legacy, безопасность, инфраструктурное взаимодействие или архитектура.
Для поиска специалистов под конкретную архитектуру и продукт можно подключить подбор Backend-разработчиков: профиль и карта рынка строятся вокруг задач, а не только вокруг языка.

Что проверить по последнему релевантному проекту

  • Что представлял собой продукт и кто им пользовался.
  • Какую часть системы развивал кандидат.
  • Какой была команда и распределение ответственности.
  • Какие решения человек принимал самостоятельно.
  • С какими ограничениями и инцидентами сталкивался.
  • Как измерялся результат его работы.
Последний проект не всегда самый сильный, поэтому полезно отдельно спросить о наиболее похожей задаче. Но описание должно быть конкретным, а не состоять из названий технологий.

Архитектурный контекст

До техинтервью можно уточнить общую структуру: монолит, микросервисы, событийная модель, набор сервисов или другая среда. Важно не оценивать, какая архитектура «лучше», а понять, в каком контексте работал кандидат.
Спросите, участвовал ли человек в выборе решений, миграциях, декомпозиции и обсуждении компромиссов. Разница между поддержкой готового сервиса и ответственностью за архитектурное изменение влияет на уровень.

Нагрузка и масштаб

Слово highload часто используется без контекста. Рекрутеру не нужно проверять точные расчёты, но можно уточнить порядок нагрузки, критичность доступности, характер пиков и последствия отказа.
Если цифры раскрывать нельзя, кандидат может описать относительный масштаб: рост, сезонные пики, число сервисов, географию, объём данных или требования к времени ответа.

Базы данных и работа с данными

Совпадение названия базы не показывает глубину. Важно понять, что делал человек: проектировал схемы, оптимизировал запросы, участвовал в миграциях, работал с репликацией или использовал готовый слой доступа.
Для роли с высокой ответственностью за данные стоит уточнить, как команда решала консистентность, отказоустойчивость и изменения схем. Техническую правильность ответа оценит инженер, но рекрутер соберёт контекст.

Интеграции и API

Backend часто связан с внешними системами, платёжными провайдерами, партнёрами и внутренними сервисами. Уточните, какие интеграции были у кандидата, насколько они критичны и какую часть он реализовывал.
Полезно узнать, работал ли человек с версионированием API, ошибками внешних систем, повторными запросами и наблюдаемостью. Не нужно требовать терминов, важнее реальный опыт решения проблем.

Production и эксплуатация

Сильный Backend-разработчик может участвовать не только в написании кода, но и в мониторинге, инцидентах, логировании, релизах и анализе производительности. Глубина зависит от организации команды.
Спросите, что происходило после релиза и как разработчики узнавали о проблемах. Это помогает понять ответственность за результат, а не только за pull request.

Безопасность и ограничения домена

Для fintech, healthtech, e-commerce и других чувствительных областей важны права доступа, персональные данные, аудит и регуляторные ограничения. Кандидат не обязан раскрывать закрытые детали, но может описать тип ответственности.
Если домен критичен, его нужно вынести в must-have осознанно. Иногда сильный инженер из смежной отрасли быстрее адаптируется, чем кандидат с названием нужного домена, но поверхностной ролью.

Как проверить личный вклад

Фразы «мы сделали» и «команда внедрила» требуют уточнения. Спросите, за какую часть отвечал кандидат, какое решение предложил, кто согласовывал и что изменилось после его работы.
Личный вклад не означает работать в одиночку. Умение принимать решение совместно, аргументировать компромиссы и доводить изменение до production также показывает зрелость.

Как различать уровни до технического интервью

  • Junior. Выполняет ограниченные задачи с поддержкой и объясняет базовый контекст.
  • Middle. Самостоятельно ведёт типовые задачи, понимает последствия решений и отвечает за сервис или функцию.
  • Senior. Работает с неопределённостью, сложными компромиссами, рисками и влияет на технические решения.
  • Lead. Координирует решения команды, развивает инженеров и отвечает за целостность направления.
Эти признаки нельзя превращать в универсальную шкалу. В разных компаниях titles отличаются, поэтому уровень сравнивается с задачей вакансии.

Что должен проверить рекрутер, а что — команда

Рекрутер проверяет факт и контекст опыта, карьерную логику, мотивацию и условия. Техническая команда оценивает качество решений, глубину знаний, system design и практические навыки.
Такое разделение полезно и в общем подборе IT и digital-специалистов: каждый участник отвечает за свою область, а интервью не дублируют друг друга.

Красные флаги на первичном этапе

  • Кандидат не может объяснить продукт и свою часть системы.
  • Все достижения описываются только на уровне команды.
  • Технологии перечисляются без примеров применения.
  • Уровень ответственности не соответствует заявленному title.
  • Опыт highload не содержит никакого контекста масштаба.
  • Ожидания по роли расходятся с фактическими задачами вакансии.
IT and Digital проводит первичную оценку и подбор Backend-разработчиков под конкретный продукт, масштаб и архитектурный контекст.

Частые вопросы

Может ли рекрутер оценить Backend-разработчика?

Он может оценить соответствие опыта и собрать доказательства. Техническую глубину должен проверять профильный эксперт.

Обязательно ли точное совпадение языка?

Зависит от срочности и задачи. Для некоторых ролей сильная инженерная база и похожий контекст важнее, для других быстрый старт требует точного стека.

Нужно ли спрашивать точные цифры нагрузки?

Полезно получить масштаб, но не все кандидаты могут раскрывать цифры. Можно использовать относительные показатели и описание критичности.

Как проверить архитектурный опыт?

Соберите примеры участия в выборе, миграциях и компромиссах, а техническую корректность разберите на профильном интервью.

Стоит ли отказывать без опыта нужного домена?

Только если доменная специфика объективно критична. Иначе стоит оценить переносимость опыта и скорость адаптации.

Вывод

До технического интервью можно проверить не знания по учебнику, а контекст: систему, масштаб, данные, интеграции, production и личный вклад. Это заметно повышает качество воронки.
Профессиональный подбор Backend-разработчика не заменяет техническую команду, а приводит к ней кандидатов, чей опыт уже подтверждён на уровне задачи и ответственности.