Технический раунд на собесе продакта: что готовить

Зачем PM технический раунд

Раньше PM-у достаточно было знать слова «когорта» и «retention». Сейчас, особенно в больших российских продуктах, без базовой техники не возьмут. Аналитики не хотят писать запросы за продакта, дата-сатанисты не хотят объяснять p-value на пальцах. Поэтому базу на тебе.

Технический раунд — не про то, чтобы ты переплюнул senior-аналитика. Он про то, чтобы ты не плыл, когда видишь дашборд, мог сам пощупать данные и понять результат A/B-теста. Дальше — что именно качать, с примерами и шаблонами ответов.

Что обычно проверяют на техническом раунде PM:

Блок	Глубина	Длительность
SQL	Уверенный middle	15–25 мин
A/B-тесты и статистика	Базовые понятия	10–15 мин
Метрики и юнит-экономика	Применение	10–15 мин
Чтение графика	Гипотезы вслух	5–10 мин

SQL для продакта

Минимум, который должен быть в пальцах:

• SELECT, WHERE, ORDER BY, LIMIT.
• GROUP BY с агрегатами (COUNT, SUM, AVG).
• JOIN: INNER, LEFT.
• Подзапросы и CTE (WITH).
• Оконные функции (ROW_NUMBER, LAG, SUM() OVER).
• Безопасное деление через NULLIF(denominator, 0).

Типичные задачи:

-- Топ-5 продуктов по выручке за месяц
SELECT product_id, SUM(revenue) AS total
FROM orders
WHERE created_at >= DATE_TRUNC('month', CURRENT_DATE)
GROUP BY product_id
ORDER BY total DESC
LIMIT 5;

-- Retention D7 по когорте регистрации
WITH cohort AS (
  SELECT user_id, DATE(created_at) AS reg_date
  FROM users
)
SELECT
  c.reg_date,
  COUNT(DISTINCT c.user_id) AS cohort_size,
  COUNT(DISTINCT CASE
    WHEN e.created_at::DATE = c.reg_date + 7 THEN e.user_id
  END)::NUMERIC
  / NULLIF(COUNT(DISTINCT c.user_id), 0) AS d7
FROM cohort c
LEFT JOIN events e ON e.user_id = c.user_id
GROUP BY c.reg_date;

-- Топ-N в каждой категории через оконку
WITH ranked AS (
  SELECT category, product_id, revenue,
         ROW_NUMBER() OVER (PARTITION BY category ORDER BY revenue DESC) AS rn
  FROM products
)
SELECT category, product_id, revenue
FROM ranked
WHERE rn <= 3;

Что часто заваливают:

• Деление целых на целые: 5 / 20 в Postgres = 0. Лечится ::NUMERIC или 100.0 * 5 / 20.
• Оконные функции в WHERE — нельзя, нужно через CTE с фильтром по колонке.
• COUNT(DISTINCT x) OVER (...) в Postgres не работает — нужен коррелированный подзапрос.
• Неэкранированные | в результирующих markdown-таблицах при описании задач.

Антипаттерн: писать SQL в один длинный SELECT с подзапросами на 4 уровня. CTE читаются проще, и интервьюер это оценит.

Базовая статистика и A/B

Что должен знать PM:

Гипотеза. H0: эффекта нет, H1: эффект есть. Тест проверяет H0.

p-value. Вероятность увидеть эффект минимум такой же сильный, если H0 верна. p < 0.05 — типичный порог отвержения H0. Это НЕ вероятность того, что H0 верна.

Ошибки. Type I — отвергли H0, когда она была верна (false positive). Type II — не отвергли H0, когда она была неверна (false negative).

Мощность. 1 минус P(Type II). Обычно целятся в 0.8.

MDE. Минимальный эффект, который тест способен задетектить. Зависит от выборки, базовой конверсии и параметров.

Размер выборки. Растёт квадратично при уменьшении MDE. Хотите ловить эффект в 2 раза меньше — нужно в 4 раза больше пользователей.

SRM. Sample Ratio Mismatch — перекос распределения по группам. Если 50/50 превратилось в 48/52, тест сломан, и результаты нельзя интерпретировать.

Готовый ответ на «расскажи про A/B-тест»:

1. Гипотеза в формате «изменение X улучшит метрику Y на Z%».
2. Основная метрика и контрольные.
3. MDE и базовая конверсия → размер выборки.
4. Срок теста (минимум одна неделя из-за weekly seasonality).
5. Запуск, проверка SRM, проверка a/a.
6. Анализ результата: эффект, доверительный интервал, сегменты.
7. Решение и план раскатки.

Антипаттерны:

• «Тест шёл 3 дня, p-value 0.04 — катим». Нет проверки SRM, мало времени, peeking.
• Сравнивать конверсию в группах через «глазами» без статтеста.
• Объявлять победителя по гипотезе, которая не была основной (множественное сравнение).

Метрики и юнит-экономика

Что должно быть в голове:

• DAU, WAU, MAU и stickiness (DAU/MAU). Здоровый ориентир stickiness для соцсети — 0.5+, для утилитарных продуктов 0.1–0.2.
• Retention по когортам (D1, D7, D30).
• Воронка регистрации/покупки и конверсии шагов.
• LTV = ARPU × срок жизни × маржа.
• CAC и payback period. Здоровое правило — LTV/CAC от 3.
• Take rate для маркетплейсов.
• ARPU, ARPPU, конверсия в платящего.

Шаблон ответа на «как посчитать LTV»:

Цифры — порядки величин, не гарантия. На собесе важнее понимать механику, чем зазубрить бенчмарки.

Антипаттерны:

• «Хороший retention 40%» без указания продукта и дня — пустой звук.
• Считать LTV без маржи, потом удивляться, почему юнит-экономика не сходится.
• Игнорировать payback period: LTV/CAC может быть 5, но если payback 18 месяцев, бизнес не выживет.

Чтение графиков

Часто дают скрин дашборда и просят прокомментировать. Что искать:

• Резкие сдвиги во времени → релиз / маркетинг / сезонность.
• Расхождение метрик (DAU растёт, retention падает) → low-quality трафик.
• Странные пики/провалы → баг трекинга, дубликаты, отвалившийся пайплайн.
• Каннибализация: одна метрика растёт за счёт другой.
• Ступенчатые скачки → новый канал/гео/сегмент включили.

Шаблон комментария вслух:

1. Что вижу на оси X и Y, единицы измерения.
2. Базовый тренд: рост, падение, стагнация.
3. Аномалии: где, когда, насколько.
4. 3 гипотезы причин, начиная с самой вероятной.
5. Что бы ещё посмотрел, чтобы проверить.

Не молчи. Думай вслух. Интервьюера интересует не «правильный ответ», а ход мысли.

План подготовки на 4 недели

Если до собеса месяц и техническая база слабая:

• Неделя 1: SQL. 30–45 минут в день. JOIN, GROUP BY, простые подзапросы, базовые оконные функции.
• Неделя 2: SQL продвинутый + метрики. CTE, ROW_NUMBER, LAG, retention-запросы. Параллельно — базовые формулы метрик.
• Неделя 3: A/B и статистика. Гипотезы, p-value, MDE, мощность, SRM. Разобрать 5 кейсов вслух.
• Неделя 4: чтение графиков и микс. Брать публичные дашборды, комментировать на диктофон. Проходить mock-интервью.

Цифры — ориентир. Если база сильнее — двигаетесь быстрее.

Частые ошибки

• Лезть в SQL без NULLIF в делении. Деление на 0 — классика.
• Путать p-value и вероятность гипотезы. p — это не P(H0).
• Анализировать A/B без проверки SRM.
• Зубрить бенчмарки без понимания контекста. «Хороший retention 40%» — без указания продукта это пустой звук.
• Молчать у графика. Лучше сказать спорное, чем ничего.
• Забывать про маржу при подсчёте LTV. Выручка — не прибыль.
• Решать SQL «в один SELECT». CTE и читаются легче, и баги ловятся быстрее.

Связанные темы

• Структура собеса PM
• Продуктовый раунд
• Что такое A/B-тест простыми словами
• Кейс «метрика упала»
• Подготовка к собесу за месяц

FAQ

Дают ли live-coding?

Часто да: SQL на доске или в shared-документе. Реже — Python/pandas.

Нужен ли Python?

Для большинства PM-вакансий — нет. Для Senior/Group PM или data-heavy команд — желательно базово (pandas).

Какая глубина статистики нужна?

До уровня A/B-теста, p-value, MDE, мощности. Без вывода формул.

Что если не знаю SQL вообще?

Месяц практики на тренажёре закрывает базу для PM-собеса.

Как готовиться к чтению графиков?

Смотреть кейсы расследований падения/роста метрик и тренировать «думать вслух».

Спрашивают ли алгоритмы и LeetCode на PM?

Почти никогда. Это для разработчиков. На PM могут спросить логическую задачу, но не алгоритм.

Что делать, если зависаешь на SQL вживую?

Проговаривать вслух план: «делаю CTE с агрегатом, потом джойню, потом фильтрую». Интервьюер часто подсказывает.

Какие книги/курсы реально полезны?

Kohavi «Trustworthy Online Controlled Experiments» по A/B, Croll/Yoskovitz «Lean Analytics» по метрикам, для SQL — практика на задачах, не книги.

Что делать, если ошибся в SQL прямо во время собеса?

Признать ошибку вслух, исправить. Интервьюеры спокойно относятся к опечаткам — паника и упорство в неверном ответе режут сильнее.

Как понять, что готов к техническому раунду?

Можете без подсказок написать SQL для retention D7 и funnel-конверсии, объяснить SRM и MDE на пальцах, прокомментировать незнакомый дашборд за 2 минуты — готовы.

Сколько SQL-задач решить перед собесом?

50–100 разных задач — порядок величин для уверенного middle. Меньше — риск споткнуться на нестандартной формулировке.

Можно ли использовать ChatGPT для подготовки?

Для разбора задач и генерации тренировочных вопросов — да. Для решения «вместо себя» — нет, на собесе AI не подскажет.

---

Тренируйте вопросы для технического раунда PM — откройте тренажёр с 2500+ вопросами.