Система подбора и оценки персонала

План собеседования и система оценки: Product Manager (Middle–Senior), ООО «ФинТрейд»

Этап: 2-й (очный), после отборочного звонка с HR Длительность: 60 минут Участники: HR-менеджер, CPO, тимлид разработки Результат этапа: решение о переходе к финальному этапу или к офферу

0. Подготовка к встрече

Распределение ролей интервьюеров

Чек-лист до встречи

• Каждый интервьюер прочитал резюме и заметки HR с отборочного звонка.
• Выбраны 2–3 проекта из резюме, по которым будут уточняющие вопросы.
• Распечатаны или открыты: схема таблиц для SQL-вопроса и условие кейса.
• У каждого интервьюера есть пустая оценочная карта. Оценки ставятся независимо, до общего обсуждения.
• Согласовано, кто следит за временем. Рекомендуется HR.
• Кандидат заранее знает состав участников, длительность и формат. Кандидата предупредили, что будет кейс и технические вопросы, и что ноутбук не нужен.

Рекомендация. 60 минут для трёх интервьюеров, технического блока и кейса — плотный формат. Вопросы ниже поделены на обязательные (★) и резервные (○). Резервные задаются, если остаётся время или ответ на обязательный вопрос оказался неоднозначным. Если уверенно оценить SQL за 7 минут не получится, добавьте короткое домашнее задание (30–40 мин) или отдельный технический созвон. Об этом кандидата нужно уведомить заранее.

1. Профиль идеального кандидата: критерии успеха

2. Сценарий встречи (60 минут)

Блок 1. Знакомство (4 мин)

Скрипт HR:

«Добрый день! Спасибо, что пришли. Меня зовут [имя], я HR-менеджер. Со мной [имя], CPO, вы будете работать в его прямом подчинении, и [имя], тимлид команды разработки. У нас 60 минут. Сначала поговорим о вашем опыте, затем зададим вопросы о конкретных ситуациях из практики, немного обсудим аналитику и Scrum, разберём один рабочий кейс. В конце будет время для ваших вопросов. Мы будем делать заметки, это нужно для объективной оценки. Готовы начать?»

Блок 2. Опыт кандидата (8 мин)

★ 2.1. «Расскажите коротко о продукте, над которым вы работали последним: кто пользователи, какая бизнес-модель, какой была ваша зона ответственности и состав команды?»

★ 2.2. «Выберите одну фичу, которую вы довели от гипотезы до релиза. Что было исходной проблемой, как вы поняли, что её стоит решать, и какой результат получили в цифрах?»

○ 2.3. «С какими смежными подразделениями вы работали чаще всего? Что было самым сложным во взаимодействии с комплаенсом или безопасностью?»

3. Вопросы по компетенциям (метод STAR)

Как задавать. Попросите описать конкретную ситуацию из опыта, а не гипотетическую. Если ответ общий («обычно я…»), уточните: «Расскажите об одном конкретном случае». Разбирайте по структуре Situation → Task → Action → Result. Тайминг: ~12 минут, 3–4 вопроса. Обязательные отмечены ★.

3.1. Лидерство (влияние без формальной власти) ★

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

Уточняющие вопросы: Какие аргументы вы использовали? Какие данные? Что вы уступили? Чем закончилось?

3.2. Решение проблем ★

«Опишите случай, когда ключевая метрика продукта неожиданно просела. Как вы искали причину и что сделали?»

Уточняющие вопросы: Какие гипотезы проверяли первыми? Какими инструментами? Сколько времени ушло? Как предотвратили повторение?

3.3. Командная работа

«Расскажите о ситуации, когда разработчики или дизайнер не соглашались с требованиями, которые вы написали. Как вы поступили?»

3.4. Адаптивность ★

«Вспомните ситуацию, когда в середине работы над фичей резко поменялись вводные: приоритеты компании, регуляторное требование, запрос ключевого клиента. Что вы сделали?»

3.5. Разрешение конфликтов ○

«Опишите конфликт между двумя стейкхолдерами (например, продажами и поддержкой, или бизнесом и комплаенсом), в котором вы были посредником. Как вы его разрешили?»

4. Технический блок (10 мин)

Ведёт тимлид разработки, CPO дополняет. Цель — проверить практическое владение инструментами, а не заученные определения. Если кандидат не уверен, попросите рассуждать вслух.

4.1. SQL ★ (~4 мин)

Покажите кандидату схему (распечатка или экран):

companies (company_id, registered_at, segment, acquisition_channel)
payments  (payment_id, company_id, created_at, amount, status)  -- status: 'success' | 'failed'

Вопрос:

«Нужно для каждой компании найти дату её первого успешного платежа и сколько дней прошло от регистрации до него. Затем посчитать медиану этого времени по каналам привлечения. Опишите или набросайте запрос».

Референсное решение (для интервьюера):

WITH first_payment AS (
    SELECT
        company_id,
        created_at,
        ROW_NUMBER() OVER (PARTITION BY company_id ORDER BY created_at) AS rn
    FROM payments
    WHERE status = 'success'
)
SELECT
    c.acquisition_channel,
    COUNT(*) AS companies_activated,
    PERCENTILE_CONT(0.5) WITHIN GROUP (
        ORDER BY fp.created_at::date - c.registered_at::date
    ) AS median_days_to_first_payment
FROM companies c
JOIN first_payment fp
    ON fp.company_id = c.company_id AND fp.rn = 1
GROUP BY c.acquisition_channel;

Уточняющий вопрос:

«Как изменится результат, если заменить JOIN на LEFT JOIN? Что это даст для анализа активации?»

○ Резервный вопрос: «Чем WHERE отличается от HAVING? Приведите пример, где нужен именно HAVING».

4.2. Продуктовая аналитика: воронки и когорты ★ (~3 мин)

«Мы запустили в приложении новый сценарий "выставление счёта клиенту". Как бы вы построили в Amplitude воронку этого сценария? Как поняли бы, влияет ли он на удержание компаний через 30 и 60 дней?»

4.3. A/B-тесты ★ (~2 мин)

«Вы запускаете A/B-тест нового онбординга для малого бизнеса. Трафик — около 800 новых компаний в неделю. Как вы спланируете тест и на что обратите внимание?»

4.4. Scrum: двухнедельные спринты (~2 мин)

★ Основной вопрос:

«Спринт идёт уже 5 дней из 10. Приходит руководитель продаж с "критически срочной" задачей для клиента. Ваши действия? И как в целом выглядит ваш процесс груминга и ретро?»

○ Резервный вопрос (требования):

«Сформулируйте user story и 3 acceptance criteria для фичи "уведомление о неуспешном платеже"».

Ориентир: «Как владелец малого бизнеса, я хочу получать уведомление о неуспешном платеже, чтобы вовремя повторить оплату и не сорвать сделку с контрагентом». Критерии: уведомление приходит в течение N минут; содержит причину отказа (понятную пользователю, без раскрытия чувствительных данных); содержит кнопку «повторить платёж»; не дублируется при повторных попытках.

5. Практический кейс (14 мин)

Кейс 1 (основной) ★: конфликт приоритетов перед конференцией

Условие (зачитать и выдать распечатку):

Вы — PM команды платежей в «ФинТрейд». Команда: 4 разработчика, дизайнер, аналитик. Спринты по 2 недели.

Ситуация:

• Через 3 недели компания участвует в конференции FinTech Russia. Там запланирована публичная демонстрация новой функции.
• Отдел продаж требует срочно сделать массовые выплаты (выплата сотрудникам или контрагентам по списку). Об этой функции просит крупный корпоративный клиент. Сделка на стадии подписания, и продажи хотят показать фичу на конференции.
• Тимлид разработки настаивает на завершении технического долга по безопасности платежей. Это доработка механизма подтверждения операций и логирования. По его словам, «без этого масштабировать платёжные операции небезопасно».
• Ресурсов на обе задачи в полном объёме за 3 недели не хватает.

Вопросы:

1. Какие вопросы вы зададите в первую очередь и кому?
2. Как вы расставите приоритеты? Какой инструмент используете?
3. Что вы предложите и как донесёте решение до продаж, тимлида и CPO?

Роли интервьюеров во время кейса:

• CPO играет роль руководителя продаж: «Клиент уйдёт к конкурентам, если не покажем на конференции!»
• Тимлид играет самого себя и защищает техдолг: «Если в массовых выплатах случится инцидент, будет гораздо хуже, чем пропущенная демонстрация».
• HR наблюдает за коммуникацией: как кандидат держит давление, слышит ли обе стороны.

Дополнительная вводная (дать, если кандидат спросит или на 6-й минуте):

Техдолг закрывает известную уязвимость в подтверждении операций. Её выявил внутренний аудит, и срок устранения по плану аудита — 2 месяца. Массовые выплаты в полной версии команда оценивает в 5 недель. Клиент готов подписать договор, если увидит рабочий прототип и получит сроки запуска.

Эталонная логика сильного ответа (для интервьюеров):

1. Уточняет вводные, прежде чем решать:

   • Насколько критична уязвимость? Есть ли требования регулятора или аудита, есть ли зафиксированные сроки?
   • Связан ли техдолг с массовыми выплатами? (Ключевой инсайт: массовые выплаты — это кратное увеличение объёма денежных операций. Небезопасный механизм подтверждения в этой фиче многократно умножает риск.)
   • Что именно нужно клиенту для подписания: продакшен-функция или демонстрация и роадмап?
   • Что показывается на конференции: рабочий продукт или демо на тестовом стенде?
   • Можно ли декомпозировать обе задачи?

2. Приоритизирует осознанно:

   • Использует RICE/ICE или матрицу «ценность/риск», но признаёт, что безопасность и комплаенс в финтехе — это ограничение, а не пункт для сравнения по баллам.
   • Учитывает стоимость задержки (Cost of Delay) для обеих задач.

3. Предлагает компромиссное решение, например:

   • Недели 1–2: закрыть критическую часть техдолга, которая непосредственно влияет на подтверждение платежей. Параллельно дизайнер и 1 разработчик делают MVP массовых выплат: загрузка реестра, валидация, предпросмотр.
   • Неделя 3: MVP массовых выплат на исправленном механизме подтверждения, демонстрация на стенде с тестовыми данными.
   • Для клиента: демонстрация, зафиксированные сроки полного запуска, возможно пилот с лимитами и ручным подтверждением.
   • Явно фиксирует, что не войдёт в релиз: интеграции, сложные сценарии, отчётность.

4. Коммуницирует:

   • Встреча со всеми сторонами, а не переговоры «по отдельности».
   • Показывает варианты с последствиями каждого (trade-offs), решение согласует с CPO.
   • Фиксирует договорённости в Confluence и держит стейкхолдеров в курсе прогресса.
   • Держит под контролем риск «демо-обещаний»: публичное обещание на конференции должно быть реалистичным.

Кейс 2 (резервный или домашний): падение конверсии в подключение

«После релиза нового онбординга конверсия из регистрации в первый платёж упала с 34% до 27% за 2 недели. Продажи говорят, что виноват новый онбординг, дизайнер — что изменился канал привлечения. Как вы найдёте причину и что предложите?»

Сильный ответ: проверяет трекинг и корректность данных; сегментирует по каналам, платформам, типам бизнеса; учитывает, что при длинном цикле активации 2 недели могут быть недостаточным окном (эффект правой цензуры); проверяет влияние изменений в KYC/комплаенсе на воронку; если онбординг выкатывался без теста, предлагает откатить часть аудитории или провести A/B.

Кейс 3 (резервный): unit-экономика

«Стоимость привлечения компании (CAC) — 6 000 ₽, ARPU — 900 ₽ в месяц, валовая маржа — 70%, средний срок жизни клиента — 14 месяцев. Выгоден ли этот канал? Какие рычаги вы бы рассмотрели в первую очередь?»

Ориентир: LTV ≈ 900 × 0,7 × 14 = 8 820 ₽, LTV/CAC ≈ 1,47. Это ниже распространённого ориентира ~3. Окупаемость ≈ 6 000 / 630 ≈ 9,5 месяца. Рычаги: retention (срок жизни), ARPU (допродажи: выплаты, эквайринг), снижение CAC, сегментация по каналам. Сильный кандидат считает быстро, проговаривает допущения и спрашивает, как LTV распределён по сегментам.

6. Мотивация, стиль работы и культурное соответствие (5 мин)

★ 6.1. «Что вас привлекает в работе над продуктом для малого бизнеса и финтеха? Что вы уже знаете о проблемах наших пользователей?»

• Сильный: конкретный интерес к боли пользователей; изучил продукт компании, возможно, даже попробовал его.
• Слабый: «Финтех — перспективная отрасль» без конкретики, с продуктом не знаком.

★ 6.2. «Что для вас идеальная рабочая неделя PM? Как вы распределяете время между командой, пользователями, стейкхолдерами и аналитикой?»

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

○ 6.3. «Какой стиль работы руководителя помогает вам быть наиболее эффективным? А что мешает?»

• Сравните с реальным стилем CPO. Важна честность и совместимость, а не «правильный» ответ.

○ 6.4. «Расскажите о решении по продукту, о котором вы сожалеете. Что вы из него вынесли?»

• Сильный: рефлексия, ответственность за результат, конкретные выводы.
• Слабый: перекладывает вину на других или «не было таких решений».

★ 6.5. «Что для вас важно в следующем месте работы? Что может стать причиной, по которой вы откажетесь от нашего предложения?»

• Проверяем совпадение ожиданий: роль, рост, формат, задачи. Вопросы о зарплате — по согласованной в компании процедуре (обычно их обсуждает HR на отборочном звонке).

Ценности команды для сверки (адаптируйте под реальные ценности «ФинТрейд»)

• Ответственность за результат, а не за выполнение задач.
• Прозрачность: плохие новости сообщаются рано.
• Безопасность денег клиентов — не предмет компромисса.
• Уважение к команде: решения обсуждаются, а не спускаются.
• Решения на основе данных при здоровом внимании к качественным инсайтам.

7. Вопросы кандидата и завершение (7 мин)

Вопросы кандидата (5 мин)

Качество вопросов — тоже сигнал.

Завершение (2 мин)

Скрипт HR:

«Спасибо за разговор! Следующий шаг: мы обсудим встречу внутри команды и вернёмся с обратной связью до [конкретная дата, рекомендуется не позже 3–5 рабочих дней]. Если будет финальный этап, он пройдёт в формате [описание]. Если у вас появятся вопросы, пишите мне на [контакт]».

8. Оценочная карта

8.1. Шкала оценки (единая для всех областей)

8.2. Карта оценки

Кандидат: ________________ Дата: ________ Интервьюер: ________________

Формула: Итоговый балл = (Т × 0,30) + (Р × 0,25) + (К × 0,20) + (Кул × 0,15) + (П × 0,10)

8.3. Детализация технической компетентности (для тимлида и CPO)

8.4. Правила принятия решения

Блокирующие факторы (отказ независимо от итогового балла):

• «Техническая компетентность» или «Решение проблем» < 3.
• SQL < 3 (обязательное требование вакансии).
• Любой подтверждённый красный флаг из категории «критичные» (см. раздел 9).
• Расхождение оценок интервьюеров ≥ 2 балла по одной области без согласования на калибровке. Такое расхождение не блокирует найм автоматически, но требует обсуждения.

8.5. Процесс калибровки

1. Каждый интервьюер заполняет карту самостоятельно в течение часа после встречи.
2. Общее обсуждение (15–20 мин): сначала каждый озвучивает оценки с доказательствами, потом идёт дискуссия.
3. Решение принимается по доказательствам, а не по общему впечатлению («понравился/не понравился»).
4. CPO принимает итоговое решение как будущий руководитель. Мнения HR и тимлида фиксируются.

9. Чек-лист красных флагов и уточняющих вопросов

🔴 Критичные (как правило, основание для отказа)

🟠 Требуют уточнения

⚪ Не являются красными флагами (не учитывать при оценке)

• Волнение в начале встречи.
• Синтаксические ошибки в SQL при верной логике.
• Отсутствие профильного образования при подтверждённом опыте (требование только желательное).
• Паузы на обдумывание перед ответом на кейс. Это скорее хороший знак.
• Незнание внутренних процессов «ФинТрейд».

10. Шаблоны обратной связи

10.1. Внутренний отчёт интервьюера (заполняется каждым)

**Кандидат:** [ФИО]
**Позиция:** Product Manager (Middle–Senior)
**Интервьюер / роль:** [ФИО, должность]
**Дата:** [дата]

**Итоговый балл:** [X,X] / 5
**Рекомендация:** Сильный найм / Найм / Сомнительно / Отказ

**Сильные стороны (с доказательствами):**
1. [Факт или цитата из интервью]
2. …

**Зоны развития / риски (с доказательствами):**
1. [Факт или цитата из интервью]
2. …

**Красные флаги:** нет / [описание]

**Что осталось непроверенным и требует внимания на следующем этапе:**
- …

**Если нанимаем — фокус онбординга на первые 3 месяца:**
- …

10.2. Итоговое решение по кандидату (заполняет HR после калибровки)

**Кандидат:** [ФИО]
**Средний итоговый балл:** [X,X] (HR: __ / CPO: __ / Тимлид: __)
**Решение:** Оффер / Финальный этап / Доп. проверка [какая] / Отказ
**Обоснование (2–3 предложения):** …
**Ответственный за коммуникацию и срок:** [ФИО], до [дата]

10.3. Письмо кандидату: переход на следующий этап

Здравствуйте, [Имя]!

Благодарим вас за встречу [дата]. Команде было интересно обсудить ваш опыт [конкретно: например, запуск платёжной фичи в X / подход к приоритизации в кейсе].

Мы рады пригласить вас на следующий этап: [формат, участники, длительность]. Предлагаем варианты времени: [варианты].

Если у вас есть вопросы, будем рады на них ответить.

С уважением, [ФИО], HR-менеджер ООО «ФинТрейд»

10.4. Письмо кандидату: отказ

Здравствуйте, [Имя]!

Спасибо, что нашли время встретиться с нами и поделились своим опытом. Мы высоко ценим ваш интерес к «ФинТрейд».

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

[Опционально, если кандидат запросил обратную связь и это соответствует политике компании: 1–2 конкретных наблюдения о профессиональных навыках. Например: «Нам понравился ваш структурный подход к кейсу; для этой роли мы искали более глубокий опыт самостоятельной работы с SQL и продуктовой аналитикой».]

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

Желаем успехов! С уважением, [ФИО], HR-менеджер ООО «ФинТрейд»

Правила обратной связи:

• Сообщать решение в оговорённый срок, даже если он сдвигается. В этом случае сообщить о новом сроке.
• Говорить только о профессиональных навыках, наблюдаемых на интервью.
• Не сравнивать с другими кандидатами и не раскрывать их данные.
• Письменная формулировка отказа согласовывается с HR. Причина отказа должна быть связана с деловыми качествами.

11. Рекомендации для решения о найме

1. Решайте по доказательствам, а не по впечатлению. Каждый балл в карте должен подкрепляться конкретным фактом из интервью.
2. Проверяйте обязательные требования отдельно. Высокий общий балл не компенсирует отсутствие SQL или непонимание значимости безопасности в финтехе.
3. Балансируйте «навык сейчас» и потенциал. Для Middle–Senior допустимы пробелы в желательных требованиях (платёжные API, английский, образование), если есть сильная база и обучаемость.
4. Сверяйте стиль с CPO. Прямое подчинение CPO означает, что совместимость стилей работы критична. Но совместимость не должна подменять профессиональные критерии и становиться поиском «похожих на себя».
5. Используйте дополнительные источники при баллах 3,0–3,5: домашнее задание (SQL и разбор метрик), встреча с представителями продаж или комплаенса, рекомендации с прежних мест работы (только с согласия кандидата).
6. Снижайте предвзятость: одинаковые обязательные вопросы для всех кандидатов, независимые оценки до обсуждения, фиксация доказательств. Проводите калибровку после каждых 3–5 интервью.
7. Планируйте онбординг заранее. Выявленные зоны развития нанятого кандидата становятся фокусом его плана на испытательный срок.

12. Правовые и этические напоминания

• Недискриминация. Вопросы задаются только о деловых и профессиональных качествах. Не задавайте вопросы о возрасте, семейном положении, наличии или планировании детей, беременности, здоровье (если оно не связано напрямую с выполнением трудовой функции), национальности, религии, политических взглядах, месте жительства, членстве в общественных объединениях. Если кандидат сам затрагивает эти темы, не развивайте их и не учитывайте при оценке.
• Персональные данные. Резюме, заметки и оценочные карты содержат персональные данные. Нужны согласие кандидата на обработку, ограниченный доступ и соблюдение сроков хранения. Запрос рекомендаций возможен только с согласия кандидата.
• Обоснованность отказа. Фиксируйте в документах, что решение основано на деловых качествах. Будьте готовы сообщить причину отказа по запросу кандидата в форме, предусмотренной законодательством.
• Единый стандарт. Все кандидаты на позицию проходят сопоставимый процесс с одинаковыми критериями оценки.

⚠️ Важно. Приведённые рекомендации носят общий характер и не являются юридической консультацией. Перед применением сверьте процесс с действующим трудовым законодательством РФ (в частности, с положениями Трудового кодекса о запрете дискриминации и о порядке заключения трудового договора), законодательством о персональных данных, а также с внутренними политиками «ФинТрейд». При необходимости проконсультируйтесь с юристом компании.