--- title: Продуктовое интервью — тренировочные кейсы и протокол самотренировки source: подготовлено 2026-10-06, TASK-47; кейсы смоделированы под Codenv (внутренний продукт для разработчиков, AI-first) и под темы из брифа рекрутера; кейсы №13–№14 и быстрые вопросы из канона — TASK-49 (materials/08–14) --- # Тренировка: кейсы и протокол Протокол — как в `../../system-design/training/` (эталоны → самопрогон на таймере → разбор → лог). Кейсы №1–№5 — основные (закрывают бриф рекрутера), №6–№10 — вариативные, «быстрые вопросы» — конвейер. Все кейсы — про Codenv-контекст, чтобы одновременно тренировать знание продукта. --- ## Протокол самотренировки **Раунд** (~45–60 мин): 2 кейса на выбор → на каждый 20 мин с таймером вслух (запись голосом — обязательно, слышны паузы и слова-паразиты) → 10 мин разбор по рубрике → запись в лог `round-NN-<дата>/round.md` (шаблон ниже). **Рубрика самооценки (0–3 по каждому пункту, цель средняя ≥ 2.5):** | # | Критерий | 0 | 3 | |---|----------|---|---| | 1 | Уточнение | Сразу полез в решение | 3–4 вопроса, изменивших ход ответа | | 2 | Структура | Поток сознания | Назвал план, шаги слышны, вернулся к плану после ответвлений | | 3 | Данные и метрики | Ванити-метрики, одна метрика | Primary + guardrails, baseline, критерий успеха до запуска | | 4 | Приоритизация | «Сделаем всё» или интуиция | Явный критерий (RICE/пара-антагонисты) с числами вслух и чувствительностью | | 5 | Эксперименты | «До/после посмотрим» | Метод по контексту, MDE/выборка/недели, ловушки, альтернативы если A/B нельзя | | 6 | Завершение | Оборвался на деталях | Итог одной фразой + главная неопределённость | | 7 | Тайминг | > 25 мин или < 12 | 18–22 мин | **Порог готовности**: два раунда подряд со средней ≥ 2.5 и без пунктов ≤ 1 → готовы; иначе — точечная докрутка слабых пунктов (разделы KB). --- ## Основные кейсы ### Кейс 1. Аналитика жалоб + приоритизация (тема А, эталонный прогон) > Разработчики Яндекса жалуются в внутренний канал Codenv: «окружения тормозят при сборке», «не хватает общего доступа к окружению», «иногда всё висит по 10 минут». Как анализируете? Что и почему берёте в работу? Каркас сильного ответа: уточнить масштаб (сколько пользователей/команд, как давно) → источники beyond канала (метрики latency p95, шаркинг-сессии) → кластеризация: это 3 разные проблемы или одна (медленная инфраструктура)? → квантификация: частота × затронутые × потерянное время → поведение: кто из жалующихся перестал пользоваться → RICE вслух по 3 темам, Kano (тормоза = базовое, шаринг = performance) → выбрать, сформулировать требования+AC, метрика до/после (p95 создания/сборки; guardrail — стоимость), метод: rollout с контрольными командами → закрыть цикл: ответ в канале с планом. ### Кейс 2. Требования к фиче (тема А) > Сформулируйте требования к «шарингу окружения»: второй разработчик подключается к уже настроенному окружению первого. Каркас: уточнить сценарий (дебаг парный? ревью? передача смены?) и пользователей → user story + scenario → функциональные (подключение, права, изоляция секретов!) + NFR (latency подключения p95, доступность, совместимость версий образа) + AC примеры («подключение ≤ 5 c, при отключении хоста гостю — сообщение и переподключение») → метрика успеха: adoption шаринга, число сессий парной работы; guardrails: инциденты с секретами = 0 → риски: безопасность (доступ к переменным окружения), конфликт правок; минимальная версия (read-only) как первый шаг → как валидируем: пилот с 2–3 командами. ### Кейс 3. KPI для Codenv (тема Б) > Какие KPI вы бы выбрали для Codenv? Как измерите, что продукт полезен? Каркас: цель стадии (adoption vs надёжность) → north star: WAU разработчиков, для которых Codenv — основной способ работы (исход, не «число созданных окружений») → дерево: активация (регистрация → первый коммит ≤ N мин, %) → вовлечённость (доля рабочих дней с активной сессией) → удержание когорт (команды не возвращаются на локаль) → guardrails (инциденты/недоступность, p95 операций, стоимость на окружение, CSAT) → пары-антагонисты: рост adoption vs стабильность → как считаем: продуктовые события + когорты; полезность = комбинация retention + экономия времени (оценка через time-to-first-commit diff vs локаль) + качественные опросы. ### Кейс 4. Конверсия (тема Б) > Конверсия «создал окружение → сделал первый коммит в тот же день» = 40%. Что делаете? Каркас: сравнить с бенчмарком/историей (упала или всегда так?) → воронка внутри: создание → открытие IDE → клонирование → сборка → коммит; где теряем → сегменты (язык/размер репо/шаблон окружения) → качественно: шаркинг 5–7 не-конвертировавшихся → гипотезы: долгая сборка (трение), неясный next step (ценность), ошибки сборки вне окружения (блокер) → решения: шаблоны с прогретым кэшем, подсказка next step, диагностика ошибок → приоритизация RICE → проверка: A/B на потоке новых пользователей (трафик есть), primary — доля «первый коммит в день 0», guardrails — p95 создания, удовлетворённость. ### Кейс 5. Эксперимент (тема Б) > Хотим добавить AI-агента, который сам настраивает окружение под задачу (AI-сценарий Codenv). Как поймёте, что это работает? Каркас: гипотеза («агент сократит time-to-ready с ~15 до ~3 мин, не ухудшив качество окружения») → метрики: primary time-to-ready p50/p95; secondary: доля задач с агентом, adoption; guardrails: доля брошенных окружений, ошибки агента, satisfaction → рандомизация: пользователи; но мало трафика? → staged rollout с контрольным сегментом + switchback невозможен (эффект накопительный — note: если эффект быстрый по времени настройки, switchback ок; если привычка — нужен период) → выборка/MDE: посчитать вслух, признать если нереально → ловушки: новизна, состав задач в группах → критерий решения заранее → после: база знаний экспериментов. --- ## Вариативные кейсы ### Кейс 6. Ловушка «метрика выросла — успех?» > После релиза DAU вырос на 10%. Успешен ли релиз? Ожидание: нет контрольной группы → сезонность/тренд/маркетинг-выброс; что ещё изменилось; guardrails; состав пользователей (новые vs старые); «на какие деньги» (стоимость на пользователя). Ответ-структура: перечислить альтернативные объяснения → как проверить каждое → только потом вывод. ### Кейс 7. Приоритизация бэклога платформы > Бэклог: (а) ускорение создания окружений, (б) AI-harness для агентских сценариев, (в) надёжность при отключении ДЦ, (г) интеграция с внутренним каталогом сервисов. Приоритизируйте. Ожидание: выяснить цель квартала и данные (сколько команд ломает (в)? сколько пользователей ждёт (а)?) → RICE/WSJF вслух → dependences ((г) может разблокировать adoption других) → балланс: надёжность молодого сервиса против роста → ответ с критерием и неопределённостями. ### Кейс 8. Конфликт качественных и количественных > Громкий пользователь просит фичу, но метрики показывают, что ею не будут пользоваться. Что делаете? Ожидание: проверить данные (может, метрика не о том), копнуть причину запроса (JTBD), Kano, стоимость запроса vs альтернативы; решение с ответственностью («в бэклог с низким приоритетом + объяснить пользователю»); системный выход: правила приёма запросов. ### Кейс 9. Измерение экономии времени > Как докажете руководству, что Codenv экономит время разработчиков? Ожидание: baseline до перевода (time-to-first-commit, время на настройку по тикетам), после — на когортах; diff-in-diff с командами, оставшимися на локали; опрос self-reported + объектные метрики; честно про допущения. ### Кейс 10. Запуск фичи без A/B > Новая версия образа окружения (все переводятся автоматически). Как оценить, что не стало хуже? Ожидание: обязательная фича — классический A/B невозможен → staged rollout с контрольным сегментом, канарейки по техническим метрикам (p95 сборок, error rate), до/после по когортам с поправкой на сезонность, быстрый откат. Ключ: технический guardrails-набор + план отката. --- ## Реальные вопросы из эмпирики (TASK-48, 2026-10) Собраны из источников в [`../materials/`](../materials/) — пометка источника у каждой группы. Это вопросы/форматы, зафиксированные в отчётах, моках с яндексовцами и официальных страницах Яндекса — в отличие от смоделированных кейсов выше. ### Прямо наш формат (официальный банк Яндекса, materials/01) Дословное совпадение с брифом рекрутера — базовые формулировки секции: 1. «Пользователи жалуются, что в сервисе X не хватает фичи Y. Как провести аналитику этих жалоб? Как их приоритизировать? Как измерить качество продукта или фичи до и после запуска?» → наши кейсы №1, №2, №8. 2. «Какие стоит выбрать KPI для сервиса? Как улучшать конверсию? Как проводить эксперименты?» → наши кейсы №3, №4, №5. 3. Проектная рамка того же банка (если секция шире часа или уводят в проекты): «Перед анонсом фичи обнаружен баг — что делать?»; «Смежники жалуются, что их задачи долго делаются — как диагностировать?»; «Запуск сервиса X: шаги и оценка сроков». ### Диагностика метрик (моки Solvery, materials/04) 4. «Ввели календарь ежедневных наград: DAU +30%, рекламная выручка не изменилась, 45% „активных“ не играют. Что происходит? Что делать?» — эталонный ход: определения активного → гипотезы проблемы пронумеровать → как проверить → решение-сравнение по явным критериям → питч с риском. 5. «A/B лендинга дал +25% лидов — раскатываем?» Дожим: статзначимость, p-value/мощность/нормальность; потом «лиды выросли, продажи нет» → capacity следующего звена, мислиды/фрод, каналы. 6. «Какую цену назначить новому продукту, если A/B и fake door недоступны, прямых конкурентов нет?» — референсы через JTBD, когортный анализ, ценностный/cost-based подход, «±20% от референса, если нужна цифра сегодня». 7. Кейс людей/доставки (лид-специфика): «Ключевой разработчик просит отпуск за 2 недели до релиза, дата в договоре со штрафами». ### Классика продуктовых секций (Чёрный, materials/05; Воробьев, materials/03) 8. «Вот [продукт компании] — как улучшите?» Валидный первый ход: «можно посмотреть метрики и кто ЦА?» (90% падают в интерфейс). 9. Оценочный: «Сколько людей прямо сейчас X?» — отвечать долями и предположениями, не абсолютами. 10. «Придумайте [будильник для двоих / продукт для парковки]» — аудитория → проблема → решения → метрики → ранжирование. 11. «Что будете делать с продуктом за 6–12 месяцев?» — цель → декомпозиция → приоритеты; зрелый продукт — малые изменения, новый — крупные. 12. Ролевая игра: «Я твой нерадивый разработчик, завалил 3 релиза, ты потерял премию — уволь меня». Переводить в рациональное русло, не выходить из роли молчком. 13. «Как измерите эффективность [фичи] до разработки?» + умение собрать формулу оценки идеи самому, до аналитика. ### Быстрые форматы из банков (materials/07) 14. «Метрика X упала на 5% — что делать?» (сегменты → внутреннее/внешнее → баги аналитики → гипотезы → проверка). 15. «Зачем существует [X] в нашем продукте? Какие цели?» 16. «Разработчик предлагает идею: показывать [Y] в [Z]. Что будете делать?» — спрос → RICE → пилот. 17. «Дизайн метрики»: «Как мерить качество [сервиса]? Как понять, что он работает лучше или хуже за неделю?» — North Star → декомпозиция → guardrails (жанр вопросов, типичный для Яндекса). ### Новые кейсы для тренировки (из эмпирики) ### Кейс 11. «Метрика выросла — выручка нет» (тема Б, по мотивам мока яндексовца) > После запуска календаря ежедневных наград в приложении DAU вырос на 30%, но рекламная выручка не изменилась; 45% «активных» пользователей не совершают основное действие. Разберите. Каркас: уточнить определения (кто «активный», где показывается реклама) → найти противоречие в цифрах → пронумеровать гипотезы проблемы (награда самодостаточна; дисбаланс ломает ретеншн; короткие сессии) → как проверить каждую (разрезы сессий, воронка вокруг награды) → варианты решения и сравнение по явным критериям (выручка, гибкость докрутки, уверенность, удовлетворённость) → финальный питч 2 мин с названным риском. Тренирует: нумерованные гипотезы, критерии выбора, дожим интервьюера «что за критерий?». ### Кейс 12. «Лиды есть — продаж нет» (тема Б, цепочка воронки) > A/B новой посадочной страницы показал +25% лидов (статзначимо). Раскатали. Через месяц: продаж столько же, сколько было. Что происходит? Каркас: не принимать «+25%» на веру → проверка корректности теста (сплит, выборка, сезонность, каналы, фрод-боты) → воронка глубже: лид → квалификация → продажа; capacity следующего звена (отдел продаж физически не может больше) → качество лидов (мислиды из нового оффера) → решения по каждому варианту. Тренирует: «метрика середины воронки ≠ результат», capacity-мышление, статтерминологию (p-value, мощность, нормальность). ### Кейс 13. Чистый прогон CIRCLES на design-вопросе (тема А→Б, по канону) > «Придумайте функцию для Codenv, которая уменьшит контекст-свитчинг разработчика между задачами». Случайный аналог классики («будильник для двоих», «будильник для слепых») — генерировать можно любой. Каркас (канонический CIRCLES, materials/09; свернуть где у нас сильнее): Comprehend — цель (фокус/скорость), ограничения, контекст (что сейчас отвлекает: тикеты, ревью, CI?) → Identify — пользователь: разработчик в потоке / тимлид с прерываниями / дежурный → Report needs — по сегментам: «не терять нить задачи», «откладывать, но не терять» → Cut — приоритизировать потребности (RICE) → List — 3–6 вариантов (режим «не беспокоить» с автосводкой; связка задач+окружений; AI-агент-ассистент очереди) → Evaluate — трейдоффы каждого, включая AI-специфику (ошибки агента, стоимость) → Summarize — выбор + метрика (число прерываний/день, time-to-resume) + риск. Тренирует: полный канонический фреймворк без пропусков; сравнить с собственным скелетом §2 — где свернуть, чтобы уложиться в 20 мин. ### Кейс 14. Интервью с пользователем по Мом-тесту (тема А, follow-up) > «Разработчики жалуются на медленные сборки. Вам дают 30 минут на интервью с одним из них — какие вопросы зададите?» Каркас (правила Мом-теста, materials/10): цель — правда о проблеме, не реакция на идею → вопросы о жизни и прошлом: «расскажите про последнюю сборку: когда, сколько ждали, что делали пока ждали» → конкретика и цифры прошлого, не мнения («нужна ли вам кнопка X?» — запрещённый жанр) → работать через: комплименты не принимать за сигнал, копать в workarounds («что делаете, когда совсем горит?») → завершение: конкретный следующий шаг (участие в пилоте, разрешение позвать ещё двоих). ### Кейс 15. Вывод внутреннего приложения на внешний рынок (🟢 реальный вопрос с секции 06.10.2026, этап 3) > Существует внутреннее приложение компании: фиксация дежурств, расписания. Используется внутри. Задача: вывести его на внешний рынок. Как действовать? Каркас (жанр «productize internal tool», перекликается с позиционированием Codenv): уточнить, зачем выходим (стратегия: новая выручка vs экономия на поддержке vs витрина) → валидация внешнего спроса: у кого вне компании та же боль, как они решают сейчас (конкуренты: on-call/scheduling-сервисы) → сегменты ЦА: размер команды, зрелость процессов → ценность и упаковка: что из внутреннего реально универсально, а что — специфика компании (снять кастомный слой, оставить ядро) → модель монетизации и каналы (self-serve SaaS vs enterprise-продажи) — от этого зависит метрика активации → смена системы метрик: у внутреннего — экономия/ёмкость (cost center), у внешнего — платящие клиенты, retention/churn, CAC/LTV, NRR → риски: двойной roadmap (внутренние заказчики vs рынок), SLA/поддержка, безопасность данных при выходе за периметр → MVP на узком сегменте, продать 3–5 пилотов до масштабных вложений. Тренирует: смену рамки «экономия → выручка», PMF заново, метрики стадии. > Примечание: вопрос прозвучал на реальной секции 06.10.2026 — прогон кандидата прошёл успешно; при желании дополни разбор деталями своего ответа (что спрашивали глубже, где провоцировали). Тренирует: правило «жалоба ≠ проблема» на уровне техники разговора; вероятный follow-up интервьюера после нашего ответа на аналитику жалоб. ## Быстрые вопросы (конвейер, 3–4 мин на каждый) 1. Чем продуктовое мышление отличается от выполнения задач по ТЗ? (пример из своей практики) 2. Одна метрика для Codenv — какая и почему? 3. Что такое guardrails-метрики, приведите 3 примера для Codenv. 4. Как понять, что фича провалилась? Когда её убираете? 5. p-value по-простому; что значит «значимо» на практике? 6. Что такое MDE и почему без него нельзя планировать эксперимент? 7. Пользователи просят фичу-конкурента (как у другой платформы) — копировать? 8. Как собрать обратную связь, если пользователи молчат? 9. North star метрика и vanity метрика — в чём разница, пример. 10. Что делаете, если эксперимент показал незначимый эффект, но очень хочется? 11. (из эмпирики, Чёрный) Сколько людей прямо сейчас спит в Москве? — отвечайте долями и предположениями. 12. (из эмпирики, Solvery) Какой критерий называется «уверен, потому что протестировали», в сравнении двух решений? (Confidence в RICE — назовите связку.) 13. (канон, Doshi) Что такое product sense? (Определение: правильные решения при значимой неопределённости + три элемента: эмпатия, знание домена, креативность — materials/11.) 14. (канон, Мом-тест) Три правила разговора с пользователем? (О его жизни, не о вашей идее; конкретика прошлого, не мнения; слушайте больше — materials/10.) 15. (TASK-49) Чем ваш продуктовый ответ как лида отличается от PM-ответа? (Двусторонние product/engineering трейдоффы, платформенное умножение, delivery-слой, ответственность за результат без PM — materials/12–13, methodology §5.) 16. (канон, Orosz) Приведите фичу, где вы работали как product-minded engineer — какие черты из девяти покажете? (materials/12.) --- ## Шаблон лога раунда ```markdown # Раунд NN — <дата> Кейсы: №X, №Y ## Кейс X — <тема> Время: M мин · Запись: <ссылка/файл> Самооценка: [уточнение, структура, метрики, приоритизация, эксперименты, завершение, тайминг] Что упустил: Что докрутить (раздел KB/methodology): ## Кейс Y — ... Итог раунда: средняя = /3 · Порог ≥ 2.5: да/нет ``` ## Связанные документы - [`../methodology.md`](../methodology.md) — скелеты ответов, тимлид-приёмы §5 и карточка §7 - [`../knowledge-base.md`](../knowledge-base.md) — знания под каждый шаг - [`../../system-design/training/`](../../system-design/training/README.md) — протокол этапа 2 (взят за основу) - [`demo-protocol.md`](demo-protocol.md) — методика демо-прогонов (ассистент играет все роли, ты — наблюдатель; пассивный формат — старт перед самостоятельной тренировкой вслух); готовый прогон №1 — `demo-run-01-complaints-priority-kpi-experiment.md`