Какой опыт работы в продуктовых компаниях
Что проверяют
Понимаете ли вы, чем работа над своим продуктом отличается от заказной разработки: метрики, постоянные релизы, ответственность за код, который живёт годами. Следом часто спрашивают, как ваша фича повлияла на цифры и откуда вы это узнали.
Как отвечать
Каркас строится на вашем опыте, с опорой на то, что видно именно в Android-продукте:
- продукт и зона: что за приложение, какая аудитория, за что отвечали вы (оплата, онбординг, офлайн-режим);
- метрики: какие смотрели сами. Crash-free users в Firebase Crashlytics, ANR и крэши в Android vitals (порог плохого поведения в Google Play: 0,47% для ANR и 1,09% для крэшей), конверсия воронки, retention;
- эксперименты: фича за флагом через Firebase Remote Config или свой сервис, A/B-тест, решение по результату;
- релизы: поэтапная раскатка в Play Console, остановка раскатки при росте крэшей, hotfix;
- долгая жизнь кода: переход с XML-вёрстки на Jetpack Compose, вынос legacy, поддержка старых версий Android.
Цифры берите только свои и такие, которые готовы объяснить: «crash-free вырос с 99,2 до 99,7%, потому что мы починили восстановление после process death». Если вы работали только в аутсорсе, так и скажите и покажите продуктовое мышление там: как спорили с заказчиком о метрике, следили ли за приложением после сдачи, какие данные хотели бы видеть.
Где спотыкаются
Путают продуктовую компанию с компанией, у которой просто есть приложение, и пересказывают задачи из тикетов без связи с пользователем и цифрами.
Называют круглые проценты роста загрузок, за которые на самом деле отвечал маркетинг. Первый же вопрос «как вы отделили эффект фичи от рекламы» ломает ответ.
Молчат о провалах. Эксперимент, который не взлетел и был откатан, для продуктовой компании нормальный опыт, его стоит рассказать вместе с выводом.