🎙 Запись мок-интервью на продуктового аналитика в Skyeng (продуктовые кейсы)

Вы просили – я делаю. Продолжаем серию моков на продуктового аналитика 🔥

Ринат – ведущий менеджер по продажам в команде монетизации Яндекс Еды. Последние 5 лет использует инструменты продуктовой аналитики и аналитики данных в своей работе.

На мок-интервью Ринат проверит свои силы в продуктовом мышлении на базе продукта Skyeng.

Сможет ли он перейти на полностью аналитическую позицию?

Ответ вы найдете в видео по ссылке:

🔗 https://youtu.be/YvIFEYjzkus

Следующий мок будет полностью посвящен А/В. А после него затроним live-кодинг на SQL и Python. Если хотите поучаствовать в моке, пишите мне в личку @pbukhtik.

И приятного просмотра!

📦 Что с продуктом? Duolingo для IT-скиллов – DevLog #3

В августе я делился первыми подробностями о своем продукте: телеграм мини-аппе для изучения профессиональных скиллов через интервальные микрозадания и геймификацию (раз и два).

За это время он претерпел очень много изменений. Если интересно узнать больше, то поставьте 🐳, поделюсь внутрянкой, инсайтами и рефлексией о создании своего продукта.

А сегодня я готов предложить попробовать продукт всем желающим!

📍 Легенда

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

- Вадим, CEO (Акула);
- Владимир, тимлид (Волк);
- София, коллега по команде (Сова);
- Тигран, старший продакт (Тигр);
- Гриша, младший продакт (Гиппопотам);
- Алиса, HR BP (Лиса).

📍 Два режима

-> История – это ежедневные прикладные мини-кейсы для инкрементального освоения выбранной темы. Подходит для регулярных занятий по 5-10 мин в день, которые незаметно приведут к экспертизе. Важно! Новая история открывается только на следующий день, после прохождения предыдущей.

-> Аркада – это блиц вопросы. Подходит для интенсивной подготовки к собеседованиям в моменте или просто проверки себя.

📍 Доступные скиллы

- Продуктовое мышление;
- А/Б тестирование;
- Теория вероятностей;
- SQL;
- Python (Pandas).

Аркадный режим пока доступен только для теорвера.

---

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

Чтобы получить доступ, отправьте заявку на вступление в группу:

🔗 https://xn--r1a.website/+J0xSr-7LxaJlNDAy

Как попадете внутрь – в закрепленном сообщении ищите детали по дальнейшим шагам.

Обязательно поделитесь впечатлениями и обратной связью 🔥

🎰 Как прохождение собесов перестало быть лотереей

Раньше я думал, что умею проходить собесы.

Полистал конспекты с курсов, порешал задачи на SQL и Python, повторил статистику, обновил резюме – готов.

Первый собес. Вопросы знакомые, но под другими углами. Отвечал «в целом правильно», а в деталях тонул. Отказ. Записал себе: «подтянуть стат. критерии в А/В». Подтянул.

Второй. Про А/В ничего не было. Зато были продуктовые кейсы. Снова «в целом» ответил, но без конкретики. В конце добили задачей по теорверу – завалил 🫠. Отказали в пользу более опытного кандидата. Добавил ещё пунктов в список.

Третий. Live-coding, таймер, тишина. Сильно волновался. Застрял на corner-кейсе и не довёл задачу до конца. Отказ. Внутри злость: «я же готовился!». Снаружи – всё тот же список «что подтянуть».

Так шло собес за собесом. Я латал дыры, но каждый новый собес подсвечивал новый «пробел дня». В какой-то момент понял: я уже 4 месяца “готовлюсь”, а всё ещё валюсь на первых этапах.

Через полгода я получил оффер. Можно подумать, что это был апогей моей системной подготовки. Но нет – так совпало. И если бы не повезло – снова бы провалился.

Сейчас, спустя 150 пройденных собесов и 700 проведённых как нанимающий менеджер, я понимаю, что в корне неправильно подходил к подготовке. Я пытался испечь синнабон, не зная рецепта. Мне не хватало не «секретного ингредиента», а понимания системы. А ведь можно было просто спросить рецепт у тех, кто уже печёт.

Поэтому я создал интенсив по подготовке к собеседованиям на продуктового аналитика – чтобы вы не проходили через то же самое и не играли в лотерею.

Что внутри:

🔹 Детальный разбор всех видов секций;
🔹 Шаблоны ответов и структуры решений;
🔹 Типовые задачи-ловушки и как их обойти;
🔹 Практика в виде мок интервью для работы со стрессом;
🔹 Домашки с моей личной обратной связью.

Результат:

🔸 Оффер на 30% выше и в 2-3 раза быстрее;
🔸 Не «надеюсь, повезёт», а знаю, что отвечать на каждом этапе.

Пятый поток стартует через неделю. Осталось 16 мест.

Перестань играть в лотерею. Оставь заявку здесь:

🔗 https://nodatanogrowth.com/product-analyst-interview

Собеседования – не испытание удачи. Это навык, которому можно научиться.

🎙 Запись мок-интервью на продуктового аналитика в inDrive (кейсы на А/В)

Егор – старший аналитик данных. Он уже проводит А/В тесты на текущем месте, но хотел бы перейти на позицию продуктового (в идеале – growth) аналитика.

На мок-интервью Егор проверит ширину своих знаний в методологии проведения А/В экспериментов на базе inDrive как продукта.

Запись будет полезна как тем, кто готовится к А/В кейсам для собеседований, так и кто хочет больше узнать о подходах в тестировании.

Ссылка на видео:

🔗 https://youtu.be/0lpzZ0nw6-k

На какую тему хотите следующее мок-интервью? Поставьте посту реакцию:

⛄️ – live-кодинг на SQL;
🎄 – live-кодинг на алгоритмы на Python;
💅 – теория вероятностей и мат. задачи;
🐳 – больше продуктовых кейсов;
✍️ – больше кейсов на А/В.

И приятного просмотра!

⚖️ Как деление 90/10 может убить репрезентативность А/В теста

Предположим, мы хотим протестировать изменение в продукте с помощью А/В теста. Самый быстрый способ набрать выборку нужной мощности – сразу делить трафик 50/50 между A и B.

Но иногда это слишком рискованно: если в тесте окажется баг, мы в моменте поломаем опыт половине аудитории. Поэтому для управления рисками часто делят, например, 90/10.

Статистические критерии не требуют, чтобы A и B были одинакового размера. Но при делении 90/10 тесту нужно значительно больше времени, чтобы набрать ту же мощность при прочих равных, что при 50/50.

Чтобы не ждать вечность, обычно приходят к гибридному варианту – Ramp Up: постепенно наращиваем долю тестовой группы, чтобы ускорить набор данных.

И вот тут появляется соблазн «включить всех» и идти, например, по схеме: 90/10 → 70/30 → 50/50. Т. е. весь трафик участвует в эксперименте, просто меняются доли A и B.

Звучит логично, но есть ловушка 🕸

Если посмотреть на пример из картинки выше, видно, что при таком подходе (см. вариант 1) мы теряем репрезентативность. Доли временных когорт в контроле и тесте не будут совпадать.

Решение – наращивать трафик симметрично (см. вариант 2): 10/10 → 30/30 → 50/50. Т. е. отказаться от части пользователей в начале. Так мы всё ещё управляем рисками (подвергаем изменению лишь небольшую часть пользователей), но при этом сохраняем репрезентативность.

#абтесты

🎉 Пятый поток интенсива подготовки к собесам на аналитика стартует уже на следующей неделе

Собесы – это навык. И он не прокачивается на рабочих задачах. Поэтому даже опытные аналитики «сыпятся» на продуктовых кейсах, A/B, live-coding’е и мат. задачах.

Осталось 2 дня, чтобы занять оставшиеся 8 мест на потоке интенсива по подготовке к собесам и основательно прокачаться к горячему весеннему сезону найма.

На интенсиве ты научишься:

🔹 структурно отвечать на продуктовые вопросы;
🔹 уверенно подбирать метрики и гипотезы;
🔹 дизайнить корректные эксперименты, обходя ловушки;
🔹 щёлкать SQL и Python на live-кодинге, а не пугаться редактора;
🔹 решать задачи на тервер и статистику без флэшбеков с универа;
🔹 составлять резюме и презентовать себя, чтобы тебя приглашали.

Интенсив особенно зайдет, если ты:

🔸 хочешь вырасти в зарплате через смену работы;
🔸 переходишь в продуктовую аналитику из смежной роли (аналитики данных, маркетинговой, игровой);
🔸 прошел курсы, а хочешь проходить собесы;
🔸 возможно, доходишь до финалов, но без офферов.

Со следующего года цены на все программы вырастут ~ на 20%. Сейчас можно зайти по текущим.

Оставь заявку на интенсив по ссылке:

🔗 https://nodatanogrowth.com/product-analyst-interview

Если сомневаешься – тоже оставляй: созвонимся, разберём ситуацию и решим, подойдёт ли интенсив под твои цели.

🚀 Выступил на Матемаркетинге'25

Спасибо большое всем, кто пришел на мой доклад! ❤️‍🔥 Вас было так много, что вместе с полной посадкой, образовалось еще и несколько стоячих рядов. В след. раз нужен будет зал побольше.)

Тема доклада, конечно же, была про А/В: «Почему 9 из 10 А/В бесполезны».

По статистике компаний, которые активно проводят эксперименты, только 1 из 10 А/В дает положительный результат в виде роста бизнес метрик. Означает ли это, что остальные 9 из 10 – бесполезны?

В своем выступлении я раскрываю, как нужно относиться к своим А/В, чтобы выжимать максимум пользы из каждого. Надеюсь, что скоро доклад появится в открытом доступе, и я смогу поделиться записью с вами.

На выступлении я упоминал свой чеклист полного цикла А/В. Его можно найти по ссылке:

🔗 https://nodatanogrowth.com/ab-checklist

Веб. версия подходит для быстрой проверки теста. В конце чеклиста можно найти ссылку на Google Sheet формат – его легко адаптировать под себя. Там же есть шаблон дизайна А/В и пример его заполнения.

Чеклист включает в себя 64 пункта, которые нужно учитывать на разных этапах проведения теста. С одной стороны, он позволяет поддерживать корректность методологии А/В, с другой – стимулирует развитие аналитической культуры.

---

Сегодня я также весь день на конференции. Если хотите увидеться – пингуйте меня в личку @pbukhtik.

🤔 Как развивать продуктовое мышление

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

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

Откуда брать кейсы

Как база – из текущей работы: задачи текущей команды, эксперименты, фейлы, успешные релизы.

Но есть две проблемы:

1) Не у всех на работе есть такие задачи. А кто-то вовсе не на продуктовой роли.

2) Кейсы могут быть слишком узкими. Вы видите только один продукт и его часть, одну индустрию, один тип монетизации.

А между тем кейсы бывают очень разными:

- по индустрии: FinTech, Ecom, RideTech, EdTech и т. д.;
- по монетизации: подписка, транзакции, реклама, freemium;
- по стадии компании: поиск product-market fit, масштабирование, плато, pivot;
- по типу продукта: B2C / B2B / marketplace / платформы.

У вас может быть специализация. Это нормально. Но широкий кругозор:

- ощутимо упрощает переход между компаниями и индустриями;
- помогает находить неожиданные решения, комбинируя чужой опыт со своими задачами.

Второй путь: формировать насмотренность на чужих кейсах

Если своих кейсов мало, их можно «подсматривать» у других.

🔸 Смотреть продуктовые доклады и разборы с конференций / митапов. Обращать внимание не только на решение, но и на нюансы: формулировку проблемы, контекст, ограничения, метрики.

🔸 Читать продуктовые статьи и кейс-стади. Разбирать: какая была гипотеза, как её проверяли, почему выбрали именно такой подход, какие выводы сделали.

🔸 Изучать продукты: какие фичи есть и как они устроены, что работает хорошо и что плохо, какие подходы используются. В блогах и changelog'ах продуктов можно также найти много полезностей.

🔸 Изучать отчётность публичных компаний (earnings calls, презентации для инвесторов). Это топ-уровень продуктового мышления: какие сегменты растут, куда компания смещает фокус, как она объясняет свои продуктовые решения.

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

Развитие продуктового мышление – это бесконечный процесс. Но, как и любой навык, он растёт только там, где вы регулярно сталкиваетесь с разными кейсами, осознанно их разбираете, фиксируете выводы и применяете их на практике.

Хотите подготовлю конкретные упражнения для развития продуктового мышления? Тогда поддержите пост огоньком 🔥

🔥 Сборник популярных софтовых вопросов с разборами

Когда на собеседовании задают заезженные софтовые вопросы, порой хочется отвечать примерно так:

– Кем ты видишь себя через 5 лет?
– Сейчас мне 27. Вероятно, 32-летним человеком.

– Как ты относишься к переработкам?
– У меня есть компостер для органики.

– Расскажи о конфликте на работе и как ты его решил.
– Перенёс дедлайн. Конфликт решился естественным путём.

– Почему ты ушёл с прошлой работы?
– Они перестали платить, я перестал работать.

– Твоя самая большая ошибка?
– Согласился катить А/В в пятницу. Зато со всеми познакомился.

Шутки шутками, но их задают. И отвечать на эти вопросы всё равно нужно уметь:

🔹 Какими-то вопросами вас проверяют на риски;
🔹 Через какие-то вы можете классно раскрыть свой опыт;
🔹 А какие-то сами по себе – красный флаг о работодателе.

Я собрал в одном месте разбор 20-ти самых популярных софтовых вопросов. Для каждого вопроса есть описание того, что хочет услышать интервьюер, а также как стоит и не стоит отвечать с примерами.

Сборник доступен по ссылке:

🔗 https://docs.google.com/spreadsheets/d/1VyLDhiHsm2sLa2Rhfh_x23O7MMakwuFnMCS5Qm2Hq_A

Это первая версия сборника, и вы можете помочь его наполнить. Каких вопросов в нем не хватает? Поделитесь в комментариях 👇

💡 Как простой трюк избавляет от подглядывания в А/В

Продакты любят «подглядывать» в А/В тесты:

День 3: «О, p-value 0.049, может выкатим?»
День 4: «Эээ, уже 0.12… Ладно, подождём»
День 7: «0.01! Завершаем 🚀»

При таком «мониторинге» теста ошибка первого рода становится гораздо больше заявленных 5%.

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

Но часто этого оказывается недостаточно. И вот лайфхак, который не раз выручал меня против слабой аналитической культуры:

Спрятать p-value на время эксперимента.

Что это значит на практике:

🔹 Не отображать в дашборде во время теста p-value, значимо / не значимо и зелёных / красных маркеров успешности;

🔹 Вместо этого показывать трафик по веткам, метрики и прогресс до нужного объёма выборки (например: набрали 63% от плана);

🔹 Показывать p-value только после того, как наберется выборка и можно подводить итоги.

Таким образом мы стимулируем соблюдение методологии, а также избегаем вредных триггеров и дискуссий.

Типовые возражения можно парировать так:

❓ «Но мне нужно знать, как идёт тест!»

– Без проблем: вот метрики и графики. На них видна реальная картина. Просто без преждевременного ярлыка значимо / незначимо.

❓ «Вы же специально скрываете информацию!»

– Нет, мы показываем все данные, просто откладываем решение по статистической значимости до момента, когда тест действительно дозрел. Собственно, как диктует методология.

❓ «А если тест очевидно провален / успешен? Зачем тянуть?»

– Можем предусмотреть правила ранней остановки. Но они должно быть определены на этапе дизайна.

Объяснения и симуляции – это про обучение. Не показывать лишнего – это про систему, которая учитывает человеческую природу. И пока менеджер не открыт к обучению – временно поможет второй подход.)

#абтесты