---
title: «Как подготовиться к собеседованию на менеджера продукта» — Илья Воробьев, менеджер Яндекс.Почты (Журнал Яндекс Образования)
source: https://education.yandex.ru/journal/kak-podgotovitsya-k-sobesedovaniyu-na-menedzhera-produkta
author: Илья Воробьев (менеджер Яндекс.Почты), публикация Яндекса
конспект: подготовлено 2026-10-06, TASK-48
статус: изнутри Яндекса (автор — действующий яндексовец). Конструкция продуктового ответа, пример реального вопроса, ожидание «формулы оценки идеи», культура экспериментов.
---

# Воробьев (Яндекс.Почта): как устроено продуктовое интервью в Яндексе

## Почему отобран

Первый источник «изнутри»: практикующий менеджер Яндекса описывает этапы отбора на менеджера продукта и что реально спрашивают. Ценность — подтверждение структуры продуктового ответа и культуры: «идею надо уметь оценить самому, до аналитика».

## Формат и ожидания (из статьи)

- Отбор состоит из этапов; на продуктовых вопросах ждут **рассуждение по конструкции: аудитория → проблема → варианты решения → метрики для каждого → ранжирование вариантов → выбор с объяснением**. Это наш скелет (methodology §2–3) — совпадает.
- Пример вопроса, который задают в Яндексе (проектирование): **«придумать будильник для двух людей, которые живут вместе»** — классический product design case. Автор советует репетировать по Glassdoor-примерам.
- На одном из этапов просят **составить формулу для оценки идеи продукта**: «прежде чем пару недель мучить вопросами аналитика, вы можете самостоятельно прикинуть, стоит ли оно того». → Для нас: уметь на лету собрать оценку эффекта (reach × impact × $$$ или экономия времени) и назвать её «грубой прикидкой».
- Техническая база для менеджера в Яндексе: архитектура сервиса — обязательно, **SQL — ожидают** (в командах по-разному; Почта не даёт секцию с кодом).
- Сравнение с западом: в Booking.com технологических вопросов нет, в Google пишут код вместе с разработчиками, Яндекс — посередине и зависит от команды.

## Советы автора (пересекаются с нашей методичкой)

1. **Изучить продукт и конкурентов заранее, принести 2–3 идеи по улучшению** — его у Яндекса спросили именно «как улучшить Почту», и он делал это потом три года. Для нас: выписать идеи по Codenv до секции (README папки уже это фиксирует).
2. Задавать вопросы интервьюеру — интервью двустороннее.
3. «Не бывает правильных или неправильных ответов — смотрят, как рассуждаете» (созвучно офиц. странице аналитиков).
4. **90% экспериментов либо не дают эффекта, либо неудачны** — норма; умение рассказать про провал (неверный A/B → как поняли → как исправили → выводы) — «практически самый важный скилл». → В наших кейсах есть место для истории провала: подготовить одну.
5. STAR для историй опыта.
6. «Лёгкое интервью — тревожный знак»: если секция проще, чем ожидалось, вероятно, команда не очень. Учитывать при вопросах в конце секции.

## Что переносим

1. methodology §3.1: добавить в KPI-скелет шаг «оценка эффекта формулой вслух» (грубая прикидка до запроса аналитики) — это ожидание яндексовцев.
2. training: вопрос «как бы вы улучшили Codenv/любимый продукт» — разминочный, держать 2–3 готовые идеи.
3. История провала эксперимента из опыта (КБ §9: voice bot — итерации до ~7%) — отрепетировать подачу по схеме «ошибка → диагностика → исправление → правило на будущее».