Sanity-check и оценка: вопросы для собеседования (часть 2)
Оценка порядка величины, проверка результатов на здравый смысл, Fermi-задачи — навыки, которые защищают от ошибок на порядки. На собеседовании могут спросить: «сколько данных генерирует Яндекс.Метрика за день?» или попросить проверить, правдоподобен ли результат запроса. Аналитик, который не делает sanity check, рискует принять решение на основе бага.
Вопросы 6–10 из 20
6Продукт работает только в стране с населением около 10 млн. В отчёте маркетинга указано 30 млн `MAU`. Какой вывод о границах значения наиболее корректен?
AНарушение верхней границы: `MAU` выше численности страны указывает на путаницу единиц или отсутствие дедупликации
BДопустимая ситуация: один человек может заходить в продукт много раз в течение календарного месяца
CДоказательство международного запуска: аудитория вышла за границы заявленной страны раньше анонса
DНормализация делением на 30: после пересчёта на день показатель уйдёт в ожидаемые границы для страны
Ответ: Проверка ограничений начинается с очевидных верхних границ — например, размера популяции страны, в которой работает продукт.
Если продукт ограничен одной страной, то `MAU` не должен превышать число потенциальных пользователей в этой стране. Значение выше верхней границы обычно означает ошибку в единицах измерения (например, устройства вместо людей), дубли между платформами или неверный метод подсчёта уникальности. Такая грубая прикидка по порядку величины помогает быстро поставить отчёт под сомнение до обсуждения причин роста. Затем нужно уточнить определение активного пользователя и ключ дедупликации.
Подробный разбор → 7Продукт может отправить не более 3 пушей в день на одного пользователя по правилам. `MAU` = 10 млн. Какой верхний предел на количество пушей в день вы можете поставить без дополнительных данных?
AОколо 30 млн пушей в день: 3 пуша на пользователя умножить на максимум 10 млн активных
BОколо 3 млн пушей в день: 3 пуша на пользователя умножить на ожидаемые 1 млн активных
CОколо 300 млн пушей в день: 30 пушей на пользователя умножить на максимум 10 млн активных
DОколо 300 тыс пушей в день: 0,03 пуша на пользователя умножить на максимум 10 млн активных
Ответ: Верхний предел строят из явных ограничений: максимум на пользователя умножить на максимум пользователей.
Если неизвестен `DAU`, вы всё равно знаете, что `DAU ≤ MAU`, значит максимум пушей в день ограничен 3 × 10 млн = 30 млн. Это грубый верхний предел, но он сразу отсеивает фантастические значения при заданных правилах. Дальше можно уточнять ожидание через предположения о соотношении `DAU/MAU` и фактической частоте отправок на одного пользователя.
Подробный разбор → 8У продукта 200 тыс DAU. Доля платящих пользователей около 2%, а средний платёж в день на платящего — 500 ₽. Какая грубая оценка дневной выручки наиболее адекватна по порядку величины?
AОколо 20 тыс ₽ в день: порядок занижен на два знака относительно произведения числа платящих и среднего платежа
BОколо 200 тыс ₽ в день: порядок занижен на один знак, как если бы средний платёж разделили на 10
CОколо 20 млн ₽ в день: порядок завышен на один знак, как если бы число платящих удвоили
DОколо 2 млн ₽ в день: корректный порядок 200 тыс × 0.02 × 500 ₽ ≈ 4 тыс платящих × 500 ₽
Ответ: Оценка «на коленке»: пользователи × доля платящих × средний платёж — даёт правильный порядок величины выручки.
Сначала оцените число платящих: 200 тыс DAU × 2% ≈ 4 тыс платящих в день. Затем умножьте на 500 ₽ и получите около 2 млн ₽ в день. Такой расчёт полезен как быстрая проверка: он сразу показывает, на сколько нулей отличается итог от ожидаемого. Если бы при таких входных получились сотни миллионов, это явный сбой по порядку величины и сигнал искать ошибку в формуле или в единицах.
Подробный разбор → 9Нужно сделать дозагрузку 2 млрд строк в хранилище. Пайплайн стабильно обрабатывает 50 тыс строк в секунду. Какая грубая оценка времени ближе всего?
AОколо 11 дней
BОколо 30 минут
CОколо 11 часов
DОколо 3 месяцев
Ответ: Грубая оценка времени через единицы измерения помогает быстро проверить план работ по объёму данных и пропускной способности.
2 млрд / 50 тыс ≈ 40 тыс секунд, это около 11 часов в первой грубой прикидке. Такой порядок величин помогает не перепутать секунды, часы и дни в планировании. Если оценка выходит на месяцы, скорее всего, вы забыли про параллелизм или ошиблись в единицах измерения. После грубой оценки можно добавить запас сверху на непредвиденные простои.
Подробный разбор → 10В каталоге всего 10 тыс товаров. В отчёте за день показатель уникальных проданных позиций равен 12 тыс. Что говорит проверка ограничений на адекватность?
AЭто нормально: продажи могут быть выше размера каталога из-за возвратов и повторных оформлений за один и тот же день одной и той же позицией
BЭто означает, что каталог вырос в этот день за счёт новых поступлений, и метрика автоматически корректна без дополнительной проверки и сверки
CНужно умножить 12 тыс на средний чек, чтобы перевести количество в выручку и проверить, попадает ли результат в ожидаемый диапазон по выручке
DНарушена верхняя граница: уникальных проданных позиций не может быть больше размера каталога, значит вероятна ошибка джойна, фильтра или дедупликации
Ответ: Если результат превышает очевидную верхнюю границу, сначала ищите ошибку в расчёте, а не объяснение в данных по бизнесу.
При фиксированном каталоге максимум уникальных позиций за день ограничен размером каталога. Значение выше этой верхней границы обычно появляется из-за неверного уровня уникальности (например, считаете `sku_id` вместе с `store_id`) или из-за дублей после джойна. Грубая проверка ограничений помогает быстро локализовать такие баги. После исправления стоит сверить ключи агрегации и логику дедупликации.
Подробный разбор →