Senior Data Scientist — Вопросы на собеседовании data scientist

Как спроектировать платформу экспериментов, обслуживающую несколько продуктовых команд, запускающих тесты одновременно?

Основная проблема — интерференция: команды, запускающие пересекающиеся эксперименты на одних и тех же пользователях, могут загрязнять результаты друг друга, поэтому нужна многослойная система назначения — ортогональные слои или хеш-based bucketing, позволяющий независимым экспериментам работать на одном трафике без коллизий, плюс guardrails, которые сигнализируют, когда два эксперимента затрагивают метрику способами, чреватыми взаимодействием. Помимо назначения, платформе нужны автоматическое обнаружение sample ratio mismatch, встроенный в флоу запуска стандартизированный расчёт мощности и пайплайн результатов, который никто не сможет тихо обойти, подглядывая в сырые цифры до завершения теста, — задача платформы сделать статистически правильный путь ещё и самым простым.

Стейкхолдер просит доказать, что маркетинговая кампания вызвала рост выручки, а рандомизированный эксперимент никогда не проводился. Как подступиться?

Берётся ближайшая квазиэкспериментальная схема, которую поддерживают данные: разность разностей, если есть сопоставимая необработанная группа и чистый допериод; синтетический контроль, если единой необработанной группы сравнения нет, но взвешенная комбинация других может её приблизить; или регрессионный разрыв, если кампания таргетировала пользователей выше некоторого порога. Каждая из них опирается на допущение — параллельные тренды, отсутствие эффектов ожидания, отсутствие одновременного конфаундера, — которое нельзя доказать, только аргументировать диагностикой допериода, и итоговая выдача обязана явно включать это допущение, а не подавать точечную оценку как решённый факт.

Как перевести расплывчатый бизнес-вопрос вроде «почему в прошлом квартале упал retention» в измеримый анализ?

Начните с того, чтобы заставить сформулировать точно «retention» и «упал» — какая когорта, какое временное окно, относительно какой базы, — потому что половина расплывчатых запросов рассыпается сразу, как только метрика реально определена, и часто оказывается, что стейкхолдер отреагировал на артефакт дашборда, а не на реальное изменение. Дальше метрику декомпозируют (падение сконцентрировано в одном сегменте, канале, релизе?) прежде чем тянуться к каузальным инструментам, потому что сегментация обычно превращает открытый вопрос в конкретную проверяемую гипотезу быстрее любой модели.

Как выстроить стандарты и практики ревью в растущей команде дата-сайенс, не превратившись в бутылочное горлышко?

Кодифицируйте повторяющиеся провалы, которые вы уже видели, — утечки данных, недостаточно мощные тесты, неверно прочитанные p-value, метрики, не совпадающие с бизнес-ценой, — в лёгкий чек-лист ревью вместо того, чтобы требовать личного прохождения каждого анализа через вас, потому что личное ревью не масштабируется дальше горстки людей и создаёт очередь, которая под дедлайнами учит всех его обходить. Дополните это общими инструментами (стандартной библиотекой расчёта мощности, шаблоном для описания экспериментов), чтобы правильная практика оказалась ещё и путём наименьшего сопротивления, а личное время ревью берегите для решений с реальным финансовым или стратегическим весом, а не рутинных анализов.

A/B-тест говорит, что изменение выигрывает; более длинный наблюдательный анализ — что оно вредит retention. Как это примирить?

Сначала проверьте механику, прежде чем доверять любой из цифр: эффекты новизны и первичности затухают за короткое окно теста, но проявляются в более длинных наблюдательных данных, а сдвиг метрики, сконцентрированный в сегменте, на который тест не был рассчитан по мощности, усредняется и теряется в итоговом результате. Ищите интерференцию — повлияло ли изменение на контрольную группу косвенно, через общий ресурс, маркетплейс или модель рекомендаций, переобученную на данных обеих групп, — потому что это ломает предположение о независимости, на котором держится A/B-тестирование. Если механика в порядке и конфликт реальный, доверяйте рандомизированному результату для причинного эффекта и наблюдательному — для того, на кого и почему это влияет, и говорите об этом прямо, а не выбирайте цифру, которая совпадает с уже принятым решением.