Sanity-check и оценка: вопросы для собеседования (часть 3)
Оценка порядка величины, проверка результатов на здравый смысл, Fermi-задачи — навыки, которые защищают от ошибок на порядки. На собеседовании могут спросить: «сколько данных генерирует Яндекс.Метрика за день?» или попросить проверить, правдоподобен ли результат запроса. Аналитик, который не делает sanity check, рискует принять решение на основе бага.
Вопросы 11–15 из 20
11В отчёте `CTR` показан как 2.5. Команда утверждает, что это 2.5%. Какая проверка единиц самая правильная?
AУточнить хранение `CTR`: доля `0..1` или проценты `0..100`, и привести к одному формату везде
BПринять `2.5` и `2.5%` за одно значение: численное совпадение цифр снимает необходимость перепроверки
CДелить значение `CTR` на `100` по умолчанию: подстраховка от случая, если оно уже хранится в долях
DСравнивать `CTR` между днями без приведения единиц: метрика относительная, формат на сравнение не влияет
Ответ: Для метрик-долей важно фиксировать единицы: доля в диапазоне 0..1 или проценты в диапазоне 0..100.
Если `CTR` равен 2.5, это уже больше 1, значит в долях это невозможно и значение нужно интерпретировать как проценты. Хорошая грубая прикидка: доля кликов не может превышать 1 по определению. Чтобы избежать ошибок, договоритесь об одном формате хранения и отображения и делайте явное преобразование единиц на границах системы. Это типичная ловушка, которая даёт сбои порядка величины в отчётах.
Подробный разбор → 12В дашборде метрика конверсии определена как доля пользователей, совершивших хотя бы одну покупку за день. В отчёте вы видите 130%. Какая грубая прикидка по ограничениям метрики наиболее уместна?
AЭто нормально: значит пользователи в среднем покупают 1.3 раза в день, а доля просто отражает суммарное число покупок без учёта числа уникальных пользователей
BНужно умножить значение на 100, чтобы привести к правильному формату процента, и тогда метрика конверсии для дашборда станет интерпретируемой и сопоставимой
CДостаточно округлить до 100% и продолжать анализ, чтобы значение метрики не выглядело странно для стейкхолдеров и не вызывало лишних вопросов на ревью
DЭто нарушает верхнюю границу: доля пользователей не может быть больше 100%, проверьте единицы числителя и знаменателя (пользователи против событий) и фильтры
Ответ: Для доли пользователей верхняя граница — 100%, поэтому значение выше почти всегда указывает на ошибку в единицах измерения или определении метрики.
Быстрая прикидка помогает сразу проверить ограничения метрики: доля пользователей с событием не может превышать 100%. Если получилось 130%, часто перепутаны единицы: в числителе посчитали события (покупки), а в знаменателе — пользователей. Ещё типичный источник — дубли, неверные соединения или фильтры по времени. Сначала исправьте определение, потом интерпретируйте результат — округлять до 100% или умножать на 100 значит замаскировать ошибку.
Подробный разбор → 13Каждое событие занимает примерно 1 КБ в логах, а в день приходит 50 млн событий. Какой порядок величины суточного объёма данных ближе всего при грубой прикидке по единицам измерения?
AОколо 50 МБ: получается, если события сжимаются в среднем в 1000 раз и в логи попадает только малая часть
BОколо 5 ГБ: получается, если из 50 млн событий в логи реально доходит примерно одна десятая часть
CОколо 50 ГБ: простое произведение 50 млн событий на 1 КБ даёт порядок десятков гигабайт за сутки
DОколо 50 ТБ: получается, если каждое событие занимает не 1 КБ, а порядка 1 МБ в логах
Ответ: При грубой оценке объёма умножайте количество объектов на размер одного и проверяйте порядок величины.
50 млн умножить на 1 КБ даёт порядка 50 млн КБ. Это примерно 50 тыс МБ, то есть около 50 ГБ при десятичном приближении. Такая оценка по порядку величины полезна, чтобы быстро поймать ошибки в планировании хранилища. Дальше можно уточнять средний размер события и долю сжатия как отдельные допущения.
Подробный разбор → 14ETL-задача обработала 120 млн строк за 2 часа. Какая грубая прикидка пропускной способности в строках в секунду ближе всего?
AОколо 17 тыс строк в секунду
BОколо 170 строк в секунду
CОколо 170 тыс строк в секунду
DОколо 1.7 млн строк в секунду
Ответ: Перевод времени в секунды и расчёт строк в секунду помогают быстро проверить реалистичность скорости обработки.
2 часа — это 7200 секунд, поэтому 120 млн / 7200 ≈ 17 тыс строк в секунду по грубой прикидке. Такая проверка единиц измерения помогает поймать ошибки вроде перепутанных минут и секунд. Если получилось 1,7 млн строк в секунду, стоит пересчитать, не потеряли ли вы ноль или не перепутали строки и пакеты. На интервью важно уметь сделать такую оценку без точного калькулятора.
Подробный разбор → 15Вы видите 300 млн событий в день. Коллега заявил, что `DAU` равен 250 млн. Вы знаете, что у активного пользователя минимум 5 событий в день. Какая прикидка верхней границы корректна?
AСравнить 300 млн событий и 250 млн `DAU` напрямую: раз цифры одного порядка, значит данные согласованы и проверять нечего
BПостроить нижнюю границу: `DAU` точно больше 300 млн / 5 = 60 млн, поэтому 250 млн выглядит заниженным относительно событий
CПостроить верхнюю границу: `DAU` не может превышать 300 млн / 5 = 60 млн, значит 250 млн противоречит ограничению на минимум событий
DИгнорировать минимум 5 событий на пользователя, потому что это правило про активность не влияет на оценку числа уникальных людей
Ответ: Если известен минимум событий на пользователя, можно поставить верхнюю границу `DAU` через общее число событий.
Если у каждого активного пользователя минимум 5 событий, то общее число событий ограничивает максимум пользователей: `DAU` не может быть выше 300 млн / 5 = 60 млн. Поэтому заявленные 250 млн противоречат этому ограничению, и расчёт нужно перепроверить — скорее всего, проблема в дедупликации пользователей или в определении активного дня. Прямое сравнение цифр без модели не ловит эту ошибку, нижняя граница построена с обратным знаком неравенства, а игнорирование правила активности убирает сам инструмент проверки.
Подробный разбор →