Sanity-check и оценка: вопросы для собеседования (часть 4)
Оценка порядка величины, проверка результатов на здравый смысл, Fermi-задачи — навыки, которые защищают от ошибок на порядки. На собеседовании могут спросить: «сколько данных генерирует Яндекс.Метрика за день?» или попросить проверить, правдоподобен ли результат запроса. Аналитик, который не делает sanity check, рискует принять решение на основе бага.
Вопросы 16–20 из 20
16Известно, что в продукте 5 млн `sessions` в день, но нет данных, сколько `events` в среднем приходится на одну `session`. Какой подход к грубая прикидка оценке числа `events` в день наиболее адекватен?
AЖдать точные данные и не делать оценок, иначе любой ответ бесполезен.
BВзять ровно 1 `event` на `session`, потому что так проще, и считать это точным ответом.
CПостроить `bounds`: задать разумный `lower bound` и `upper bound` для `events per session` и получить диапазон для `events per day`.
DУмножить 5 млн `sessions` на `MAU`, потому что оба показателя про активность.
Ответ: Когда данных нет, полезно строить диапазон через `lower bound` и `upper bound`, а не одну точку.
В грубая прикидка оценке можно взять минимально возможное число событий на `session` как `lower bound` и реалистичный максимум как `upper bound`. Тогда вы получите диапазон, который легко сравнить с `constraints` системы и прошлым опытом. Такой подход лучше, чем придумывать одно точное число без оснований. Если позже появятся данные, вы сузите `bounds`.
17Коллега утверждает, что ежедневный объём выгрузки равен 5 `PB`. При этом вы знаете: 100 млн записей в день, средний размер записи около 200 `bytes`. Какой вывод `sanity-check` по `order of magnitude` наиболее верный?
A5 `PB` выглядит правдоподобно, потому что 100 млн — это очень много строк.
BДолжно быть около 5 `TB`, просто в отчёте перепутали букву.
CДолжно быть около 500 `GB`, потому что 200 `bytes` — это почти килобайт.
DДолжно быть порядка 20 `GB`, а 5 `PB` — это явная ошибка в `units` и `order of magnitude`.
Ответ: Сравнение с `order of magnitude` быстро выявляет перепутанные `units` вроде `bytes` и `KB/MB/GB`.
100 млн × 200 `bytes` ≈ 20 млрд `bytes`, то есть порядка 20 `GB`, а не `PB`. Разница в сотни тысяч раз почти всегда означает ошибку в `units` или лишние множители. Такой грубая прикидка `sanity-check` полезен, чтобы не обсуждать инфраструктуру на неверных входных. После выявления расхождения стоит уточнить, что именно считается записью и где мог появиться неверный коэффициент.
18Система пишет 1 `TB` логов в день. По `assumptions` размер одного события между 200 и 500 `bytes`. Какой диапазон для количества `events` в день по `bounds` наиболее разумен?
AОт 2 до 5 млн `events` в день
BОт 20 до 50 млн `events` в день
CОт 2 до 5 млрд `events` в день
DОт 200 до 500 млрд `events` в день
Ответ: Используйте `lower bound` и `upper bound` на размер объекта, чтобы получить `bounds` на количество объектов.
Если логов 1 `TB` в день, то при 500 `bytes` на событие получится около 2 млрд событий, а при 200 `bytes` — около 5 млрд. Это грубая прикидка расчёт, но он даёт правильный `order of magnitude`. Такой диапазон помогает проверить, не ошиблись ли вы в `units` или в оценке размера события. Затем можно уточнять средний размер и сжатие.
19Вам нужно прикинуть, сколько места займут новые `events`, но неизвестны точные `units`: сколько `events per user` в день и сколько `bytes` в одном событии. Какой подход к оценке наиболее правильный?
AНе оценивать, пока не появятся точные данные, иначе ответ будет неверным.
BВзять одно число наугад и считать его точным, чтобы быстрее принять решение.
CОпираться только на самый оптимистичный сценарий, потому что он приятнее для бизнеса.
DРазложить на `units` и построить `bounds` через `lower bound` и `upper bound` по частоте и размеру, фиксируя `assumptions` и проверяя `constraints`.
Ответ: Когда данных не хватает, лучше строить `bounds` через `lower bound` и `upper bound` и постепенно уточнять `assumptions`.
Начните с разложения на `units`: `users per day × events per user × bytes per event`. Затем задайте консервативные `assumptions` и получите `lower bound` и `upper bound` для итогового объёма. Такой грубая прикидка подход помогает принимать решения под неопределённость и быстро ловить несоответствия `constraints`. По мере появления данных вы сужаете `bounds`, не переписывая логику оценки.
20У вас 1 млн `sessions` в день. Максимально реалистичный рост `conversion` от фичи вы оцениваете как +1 процентный пункт, а маржа с одной покупки 100 ₽. Какой `upper bound` для дополнительной маржи в день даст грубая прикидка оценка?
AОколо 10 тыс ₽ в день
BОколо 100 тыс ₽ в день
CОколо 10 млн ₽ в день
DОколо 1 млн ₽ в день
Ответ: `upper bound` помогает быстро понять максимум эффекта по `constraints` даже до точного эксперимента.
Если рост `conversion` ограничен +1 п.п., то дополнительная доля покупок не превышает 0.01 от `sessions`. Умножив на 1 млн `sessions` и 100 ₽ маржи, получаем около 1 млн ₽ в день как `upper bound`. Это полезный грубая прикидка ориентир для приоритизации: если стоимость разработки больше возможного выигрыша, фича сомнительна. Дальше можно уточнять `assumptions` про реальный трафик и маржинальность.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram