Вопросы для скрининга/ТИ/команды
Примеры вопросов, которые можно задать HR на скрининге, а также собеседующему на техническом интервью и при знакомстве с командой.
Примеры вопросов, которые можно задать на HR-скрининге
На скрининге не надо уходить в глубину архитектуры, тут больше про организационные вопросы, вопросы про контекст роли, ожидания, зрелость найма. Можно задать пару технических, но если HR с трудом на них отвечает, не надо допытывать, просто скажите: “Да, ничего страшного, задам этот вопрос на техническом интервью”.
Почему вакансия открыта именно сейчас?
Показывает, что ты оцениваешь не только “что делать”, но и в каком контексте ты в это заходишь: рост, замена, конфликт, текучка, новая функция, проваленный проект.
Что можно услышать полезного:
новая роль из-за роста — чаще больше свободы;
замена человека — можно понять, что не сработало раньше;
“очень срочно ищем” — иногда сигнал о хаосе.
Как вы поймёте через 3 месяца, что человек на этой позиции справляется хорошо?
Это вопрос про критерии успеха, а не про красивые обещания.
Что даёт:
Показывает:
есть ли у компании внятные ожидания;
оценивают по результату или по “субъективно нравится/не нравится”;
ждут от аналитика документацию, фасилитацию, решение проблем или еще что то.
Где у этой роли проходит реальная граница ответственности между системным аналитиком, бизнес-аналитиком, PO и архитектором?
Очень быстро вскрывает, понимают ли они вообще, кого ищут.
Что даёт:
Если ответ расплывчатый, есть риск, что под “системным аналитиком” у них скрывается:
BA + PM + QA;
“универсальный солдат”;
“тот, кто всё оформит, но ни на что не влияет”.
Какие ожидания у команды именно от сильного аналитика на этой роли?
Хороший HR часто может передать, какой профиль реально нужен менеджеру.
Что даёт:
Можно услышать:
“нужен сильный по API/интеграциям”;
“нужен человек, который наведёт порядок в требованиях”;
“нужен фасилитатор между бизнесом и разработкой”.
Какие дальнейшие этапы нашего взаимодействия? На чём чаще всего “проваливаются” кандидаты на следующий этап?
Показывает зрелость кандидата и желание точно попасть в ожидания следующего этапа.
Что даёт:
Можно вытащить очень полезную информацию:
что для них критично;
чего они боятся;
чего не хватает у большинства кандидатов.
Примеры вопросов, которые можно задать в конце технического интервью
Здесь уже можно и нужно копать глубже.
Сильные вопросы на техинтервью показывают, что ты думаешь как аналитик: про требования, архитектуру, поток изменений, риски, интеграции, эксплуатацию и ответственность.
На каком этапе аналитик обычно подключается к инициативе: когда задача уже придумана или когда решение ещё можно формировать?
Показывает, будет ли у тебя влияние на решение, либо ты будешь только “оформлять готовое”.
Что даёт:
Один из самых показательных вопросов по зрелости продуктовой/проектной культуры.
Какие типы задач будут доминировать в первые месяцы: новые фичи, интеграции, стабилизация, legacy, регуляторка?
Показывает, что ты думаешь не общими словами, а через реальный состав работы.
Что даёт:
Позволяет понять, не продали ли тебе “интересную продуктовую роль”, а по факту там 90% разборов инцидентов и ручного сопровождения.
Есть ли у команды сейчас узкие места в процессе: качество входящих требований, согласования, зависимости между командами, документация?
Ты показываешь мышление через системные ограничения, а не через обязанности по вакансии.
Что даёт:
Это один из лучших вопросов, чтобы понять реальную боль команды.
Что в этой роли чаще всего оказывается неожиданностью для людей после выхода?
Редкий, взрослый вопрос.
Он проверяет, насколько честно компания говорит о сложностях.
Что даёт:
Иногда именно здесь всплывает настоящее:
много legacy;
тяжёлый контур согласований;
низкая автономность;
огромная коммуникационная нагрузка.
Как у вас обычно рождается решение: от бизнес-гипотезы до технической реализации?
Показывает интерес к сквозному процессу, а не только к фазе “написал ТЗ”.
Что даёт:
Сразу видно:
кто реально влияет на решение;
как устроен discovery;
есть ли место для аналитики, а не только для формализации.
Что в вашей практике считается хорошей аналитической проработкой задачи?
Ты уточняешь критерии качества, а не просто формат документации.
Что даёт:
Можно понять, ценят ли они:
ясность требований;
проработку альтернатив;
edge-cases;
трассировку;
продуманность интеграционных контрактов.
Где у вас чаще всего ломаются задачи: на сборе требований, в согласованиях, на интеграциях, в тестировании или уже в проде?
Он про системные точки отказа.
Что даёт:
Позволяет быстро понять зрелость SDLC и реальные боли команды.
Какие артефакты аналитика для вас обязательны, а какие зависят от типа задачи?
Показывает, что ты понимаешь: документация должна быть достаточной, а не одинаковой на всё.
Что даёт:
Сразу поймёшь, это команда “здравого смысла” или “религиозного документооборота”.
Как вы определяете границу между “достаточно проработано, можно в разработку” и “ещё рано”?
Очень зрелый вопрос про Definition of Ready без прямого употребления термина.
Что даёт:
Если ответа нет, значит задача может регулярно улетать в разработку сырой.
Как аналитик у вас участвует в технических компромиссах?
Показывает, что ты не хочешь быть только “передатчиком требований”.
Что даёт:
Если ответ: “аналитик в это не лезет”, надо понимать, устраивает ли тебя такая модель.
Есть ли у вас единые практики по моделированию: sequence, BPMN, ERD, event-flow, state-модели — или всё зависит от команды?
Хорошо показывает, насколько организация стандартизировала аналитическую работу.
Что даёт:
Позволяет понять:
есть ли аналитическая культура;
будет ли онбординг легче;
насколько команды совместимы между собой.
Что у вас считается самым сложным кейсом для аналитика в этом домене?
Ты просишь не “пример задачи”, а пример предельной сложности.
Что даёт:
Сразу вскрываются:
тяжёлые бизнес-правила;
сложные расчёты;
критичные интеграции;
высокая цена ошибки.
Какой один процесс или артефакт вы бы хотели улучшить в вашей аналитической практике уже сейчас?
Почему сильный вопрос:
Очень сильный финальный вопрос.
Что даёт:
Если собеседующий честный, он сам расскажет главную боль команды.
А ты покажешь, что думаешь уже не как кандидат, а как человек, который способен усиливать функцию анализа.
Примеры вопросов, которые можно задать на знакомстве с командой
На какой проект меня рассматривают? Какой его срок?
Опишите пользователей вашего продукта.
Какие цели и задачи продукта?
На какой стадии реализации продукт?
Сколько команд работает над продуктом?
Могу ли я переходить из команды в команду?
Какие артефакты аналитик должен производить в вашем проекте?
Как часто придется работать с БД?
Какой у вас технологический стек?
Что требуется от аналитика и кто ставит ему задачи?
Что нужно сделать, чтобы пройти испытательный срок?
Сколько аналитиков в команде и какой состав команды? Будет ли команда расширяться?
Как часто проходят митинги и другие встречи?
Есть ли встречи 1:1?
Как может расти аналитику в компании?
Есть ли у вас перфоманс ревью?
Есть ли у вас коммьюнити аналитиков?
Какой график: возможно гибрид или удаленка?
Какой у вас SDLC на проекте?
Почему из команды ушел предыдущий аналитик?
Будет ли у меня ментор? Буду ли я менти для кого-то?
Есть ли у вас онбординг и как он устроен?
Устанавливаются ли цели и роадмапы развития участникам команды?
Есть ли внутреннее обучение в компании и если есть, то как оно организовано?
Что вы ожидаете от меня в первые 30/60/90 дней?
Как вы оцениваете сотрудников: KPI, OKR, assessment, PR? Как часто?
Опишите портрет идеального аналитика в вашей команде.