Вопросы для собеседования аналитика данных

Что хотим услышать

• WHERE фильтрует строки до группировки, HAVING фильтрует группы после
• В WHERE нельзя агрегаты, в HAVING можно
• Порядок: FROM, WHERE, GROUP BY, HAVING, SELECT
• Условия без агрегатов лучше писать в WHERE: меньше строк до группировки
• Пример: WHERE status = 'paid' и HAVING SUM(total) > 10000

Если ответил, копните глубже

Что хотим услышать

• Схема split-apply-combine
• agg сворачивает группу в одно значение, именованная агрегация
• transform возвращает результат формы исходной таблицы
• filter оставляет группы целиком по условию
• Ключ уходит в индекс, as_index=False или reset_index
• NaN в ключе по умолчанию выпадает

Если ответил, копните глубже

Что хотим услышать

• Объём данных, пропуски, явные ошибки
• Среднее и медиана вместе, их сравнение говорит о хвосте
• Разброс: std и IQR, квантили p5/p25/p75/p95/p99
• Гистограмма, лучше в логарифмической шкале для денег
• Выбросы: ошибка данных или реальные крупные клиенты
• Разрезы по сегментам, где распределение может отличаться

Если ответил, копните глубже

Что хотим услышать

• Когорты по моменту начала
• Классический N-day: активен ровно в день N
• Rolling: в день N или позже
• Bracket: активен в интервале
• Выбор по естественной частоте продукта
• Взвешенное среднее по когортам

Если ответил, копните глубже

Что хотим услышать

• Две-три стороны, а не список из десяти
• Каждая подкреплена примером
• Стороны связаны с вакансией
• Нет пустых слов вроде «стрессоустойчивый, коммуникабельный» без доказательств
• Уверенно, без хвастовства

Если ответил, копните глубже

Что хотим услышать

• INNER: только пары, где условие ON истинно
• LEFT/RIGHT: все строки одной стороны, у недостающей стороны NULL
• FULL: все строки обеих сторон
• CROSS: декартово произведение, N × M строк
• Связь один ко многим размножает строки «одной» стороны, два таких JOIN перемножают
• Строки с NULL в ключе не соединяются: NULL = NULL не true

Если ответил, копните глубже

Что хотим услышать

• shape, head, dtypes: правильно ли разобраны колонки
• Числа и даты не стали строками: sep, decimal, parse_dates
• ID с ведущими нулями прочитаны строкой
• Пропуски: isna().sum(), не съел ли парсер реальные значения вроде NA
• Кодировка: нет ли кракозябр
• Дубликаты и неожиданные значения

Если ответил, копните глубже

Что хотим услышать

• Предполагаем, что эффекта нет
• p-value: как часто случайность дала бы такую же или большую разницу
• Маленький p-value: случайностью объяснить трудно, отвергаем H0
• Не вероятность того, что гипотеза верна, и не размер эффекта
• Порог α выбран заранее, обычно 5%
• Большой p-value: эффект не доказан, а не доказано отсутствие

Если ответил, копните глубже

Что хотим услышать

• Определение активности через тренировку, а не открытие
• DAU, WAU, MAU и stickiness с учётом естественной частоты
• Частота: тренировок в неделю на активного
• Глубина: завершённые тренировки, длительность
• Распределение L28 или L7
• Связь с удержанием и подпиской

Если ответил, копните глубже

Что хотим услышать

• Назвал реальную слабость, а не штамп
• Слабость не критична для роли
• Рассказал, что делает, чтобы её компенсировать
• Есть пример прогресса
• Коротко, без самобичевания

Если ответил, копните глубже

Что хотим услышать

• Один запрос за списком и по запросу на каждый элемент за связанными данными
• Типично возникает из-за ленивой загрузки в ORM в цикле
• Заметить: число запросов растёт с размером списка, логи SQL, APM, счётчик запросов в тестах
• Исправить: JOIN, запрос по списку id (IN или ANY), eager loading, DataLoader в GraphQL
• Следить, чтобы JOIN не размножил строки и не тянул лишнее

Если ответил, копните глубже

Что хотим услышать

• Длинный формат против широкого
• pivot без агрегации и его ошибка на дублях
• pivot_table с aggfunc, fill_value, margins
• melt для колонок-месяцев
• stack/unstack для MultiIndex после groupby
• crosstab для частот двух признаков

Если ответил, копните глубже

Что хотим услышать

• UPDATE создаёт новую версию строки, старая остаётся с xmax; DELETE только помечает версию
• Каждая транзакция видит версии по своему снимку, поэтому чтение не блокирует запись и наоборот
• VACUUM удаляет версии, которые уже никому не видны, обновляет visibility map и замораживает старые строки
• Долгие транзакции и забытые слоты репликации мешают очистке и раздувают таблицы
• Autovacuum настраивают по таблицам: autovacuum_vacuum_scale_factor, лимиты стоимости; мониторинг через pg_stat_user_tables
• HOT-обновления и fillfactor уменьшают нагрузку на индексы

Если ответил, копните глубже

Что хотим услышать

• Copy-on-Write по умолчанию: результат индексации ведёт себя как копия
• Цепочное присваивание df["a"][0] = 1 больше не меняет df
• SettingWithCopyWarning ушёл вместе со старой моделью
• Строки по умолчанию получают dtype str вместо object
• Проверки dtype == object в коде надо пересмотреть
• Перед обновлением прогнать тесты на 2.x с включёнными опциями будущего поведения

Если ответил, копните глубже

Что хотим услышать

• Сначала понять природу: ошибка, бот, тест или реальный крупный клиент
• Ошибки и ботов исправить или исключить по правилу, записанному заранее
• Реальные значения не удалять: они часть бизнеса
• Для тестов: винзоризация или устойчивые метрики, правило до запуска
• Проверить чувствительность вывода: с выбросами и без
• Одинаковая обработка во всех группах

Если ответил, копните глубже

Что хотим услышать

• Last click недооценивает каналы знакомства
• Посмотреть пути и другие модели: first click, position-based
• Учесть качество клиентов: LTV по каналам
• Проверить инкрементальность экспериментом
• Предложить постепенное изменение с контролем
• Решение по приросту выручки, а не по отчёту

Если ответил, копните глубже

Что хотим услышать

• Назван масштаб: команда, нагрузка, пользователи или деньги
• Есть решения, которые повлияли дальше своего кода
• Есть метрики результата
• Упомянуто влияние на команду: менторинг, процессы, ревью
• Уложился в 2 минуты, не утонул в деталях

Если ответил, копните глубже

Что хотим услышать

• Deadlock это цикл ожидания: транзакции держат блокировки и ждут друг друга
• PostgreSQL проверяет цикл после deadlock_timeout (1 с по умолчанию) и откатывает одну из транзакций с ошибкой 40P01
• В логе есть оба запроса и тип блокировок; включаю log_lock_waits для долгих ожиданий
• Главное лечение: единый порядок взятия блокировок, короткие транзакции, блокировка заранее через SELECT ... FOR UPDATE в порядке ключа
• Приложение должно уметь повторять транзакцию при 40P01 и 40001

Если ответил, копните глубже

Что хотим услышать

• Динамика числа заказов и выручки по дням: провалы, всплески, неполные периоды
• Распределения ключевых чисел, часто в логарифме: хвосты, выбросы, нули
• Доли пропусков по колонкам
• Сравнение сегментов: boxplot или ECDF
• Связи: scatter или heatmap корреляций
• Проверка гипотез о качестве данных, а не красивые картинки

Если ответил, копните глубже

Что хотим услышать

• α и мощность задают цену ложного срабатывания и пропуска
• Стандарт 5% и 80% не догма
• Рискованное изменение (цены, платёжный поток): строже α, жёсткие guardrail
• Дешёвые обратимые изменения: можно мягче α ради скорости
• Пропуск эффекта дорог, если трафика мало и тестов мало
• Решение фиксируется до теста

Если ответил, копните глубже

Что хотим услышать

• Проверить данные и разметку событий
• Найти шаг между корзиной и оплатой, где выросли потери
• Срезы: платформа, версия, способ оплаты, регион, новые и старые
• Сопоставить с релизами, сбоями провайдера, изменениями цен и доставки
• Проверить окно конверсии и микс трафика
• Подтвердить гипотезу и исправить, поставить алерт

Если ответил, копните глубже

Что хотим услышать

• Акцент на масштаб и влияние, а не на список фич
• Метрики бизнес-эффекта
• Лидерство: менторинг, процессы, архитектурные решения
• Компактность: старый опыт свёрнут
• Понимание, что резюме под роль, а не под всё сразу

Если ответил, копните глубже

Что хотим услышать

• Индекс работает по левому префиксу: ведущие колонки должны быть в условии
• Сначала колонки с равенством, затем одна колонка с диапазоном или сортировкой
• После колонки с диапазоном следующие колонки для поиска уже не помогают
• Для примера: (tenant_id, status, created_at) закрывает и фильтр, и ORDER BY
• Учитывать, какие ещё запросы обслужит индекс, чтобы не плодить похожие
• Проверять на реальных данных через EXPLAIN ANALYZE

Если ответил, копните глубже

Что хотим услышать

• Три типа: MCAR (полностью случайные), MAR (зависят от наблюдаемых признаков), MNAR (зависят от самого значения)
• Среднее сжимает дисперсию и рвёт связи между признаками
• При MNAR любое заполнение смещает выводы: например, богатые не указывают доход
• Варианты: заполнение по группе, модельное (KNN, итеративное), флаг пропуска
• Статистики считать на train, без утечки
• Проверить чувствительность выводов к способу заполнения

Если ответил, копните глубже