Sanity-check и оценка: вопросы для собеседования (часть 2)
Оценка порядка величины, проверка результатов на здравый смысл, Fermi-задачи — навыки, которые защищают от ошибок на порядки. На собеседовании могут спросить: «сколько данных генерирует Яндекс.Метрика за день?» или попросить проверить, правдоподобен ли результат запроса. Аналитик, который не делает sanity check, рискует принять решение на основе бага.
Вопросы 6–10 из 20
6Продукт работает только в стране с населением около 10 млн. В отчёте маркетинга указано 30 млн `MAU`. Какой `constraints` вывод наиболее корректен?
AЭто нормально: `MAU` всегда может быть больше населения, потому что люди заходят несколько раз.
BЭто доказывает, что продукт стал международным, даже если это не заявлено.
CНарушен `upper bound`: `MAU` не может превышать доступную популяцию, вероятно перепутали `units` (устройства vs люди) или не сделали дедупликацию.
DНужно просто разделить `MAU` на 30, чтобы получить `DAU`, и всё станет корректно.
Ответ: Проверка на `constraints` начинается с очевидных `upper bound` вроде размера популяции.
Если продукт ограничен одной страной, то `MAU` не должен превышать число потенциальных пользователей в этой стране. Значение выше `upper bound` обычно означает ошибку в `units` (например, устройства вместо людей), дубли между платформами или неверный метод подсчёта уникальности. Такой грубая прикидка `order of magnitude` чек помогает быстро поставить под сомнение отчёт до обсуждения причин роста. Затем нужно уточнить определение активного пользователя и ключ дедупликации.
7Продукт может отправить не более 3 пушей в день на одного пользователя по `constraints`. `MAU` = 10 млн. Какой `upper bound` на количество пушей в день вы можете поставить без дополнительных данных?
AОколо 3 млн пушей в день
BОколо 30 млн пушей в день
CОколо 300 млн пушей в день
DОколо 300 тыс пушей в день
Ответ: `upper bound` строят из явных `constraints`: максимум на пользователя умножить на максимум пользователей.
Если неизвестен `DAU`, вы всё равно знаете, что `DAU ≤ MAU`, значит максимум пушей в день ограничен 3 × 10 млн = 30 млн. Это грубый `upper bound`, но он сразу отсеивает фантастические значения при данных `constraints`. Дальше можно уточнять ожидание через `assumptions` о `DAU/MAU` и фактической частоте отправок.
8У продукта 200 тыс `DAU`. Доля платящих пользователей около 2%, а средний платёж в день на платящего — 500 ₽. Какая грубая прикидка оценка дневной выручки по `units` наиболее адекватна по `order of magnitude`?
AОколо 20 тыс ₽ в день
BОколо 200 тыс ₽ в день
CОколо 20 млн ₽ в день
DОколо 2 млн ₽ в день
Ответ: Для грубая прикидка оценки выручки держите `units` как `users × share × money per payer` и проверяйте `order of magnitude`.
Сначала оцените число платящих: 200 тыс `DAU` × 2% ≈ 4 тыс платящих в день. Затем умножьте на 500 ₽ и получите около 2 млн ₽ в день. Такой расчёт полезен как `sanity-check`: он быстро показывает, на сколько нулей отличается итог. Если в результате получились сотни миллионов при таких входных, это явный `order of magnitude` сбой.
9Нужно сделать `backfill` 2 млрд строк в хранилище. Пайплайн стабильно обрабатывает 50 тыс строк в секунду. Какая грубая прикидка оценка времени ближе всего?
AОколо 11 часов
BОколо 11 дней
CОколо 30 минут
DОколо 3 месяцев
Ответ: Оценка времени через `units` `rows` и `throughput` помогает быстро проверить план работ.
2 млрд / 50 тыс ≈ 40 тыс секунд, это около 11 часов по грубая прикидка. Такой `order of magnitude` чек помогает не перепутать секунды, часы и дни в планировании. Если оценка выходит на месяцы, скорее всего вы забыли про параллелизм или ошиблись в `units`. После грубой оценки можно добавить `upper bound` на непредвиденные простои.
10В каталоге всего 10 тыс `sku`. В отчёте за день показатель `unique_sku_sold` равен 12 тыс. Что говорит `constraints` `sanity-check`?
AЭто нормально: продажи могут быть выше размера каталога из-за возвратов.
BЭто означает, что каталог вырос в этот день, и метрика автоматически корректна.
CНужно умножить 12 тыс на средний чек, чтобы проверить `units`.
DНарушен `upper bound`: уникальных проданных `sku` не может быть больше размера каталога, значит вероятна ошибка джойна, фильтра или `dedup`.
Ответ: Если результат превышает очевидный `upper bound`, сначала ищите ошибку в расчёте, а не объяснение в данных.
При фиксированном каталоге максимум уникальных `sku` за день ограничен размером каталога. Значение выше этого `upper bound` обычно появляется из-за неверного `units` уровня уникальности (например, считаете `sku_id` вместе с `store_id`) или из-за дублей после джойна. грубая прикидка проверка `constraints` помогает быстро локализовать такие баги. После исправления стоит сверить ключи агрегации и логику `dedup`.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram