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

Пример сильного ответа

INNER JOIN возвращает только совпадающие строки из обеих таблиц. LEFT JOIN — все строки из левой таблицы и совпадения из правой, если совпадений нет — NULL. FULL OUTER JOIN — все строки из обеих таблиц, с NULL там, где нет совпадений. В моей практике при сверке заказов и оплат моя задача — выявить расхождения. INNER JOIN показывает только оплаченные заказы. LEFT JOIN — все заказы с данными об оплате. FULL OUTER JOIN — и заказы без оплат, и оплаты без заказов. Такой подход позволяет найти около 200 расхождений на 50 тысячах транзакций.

• Чётко объясняет разницу между типами JOIN.
• Приводит конкретный пример из практики с цифрами.
• Демонстрирует понимание, как находить расхождения.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Когда мне приходится решать такую задачу, я использую оконную функцию ROW_NUMBER() с PARTITION BY по менеджеру и сортировкой по сумме заказа. Внешним запросом фильтрую номер строки до трёх. Если СУБД не поддерживает оконные функции, применяю коррелированный подзапрос или LATERAL JOIN. В одном проекте на 2 млн заказов такой подход даёт результат за пару секунд. Также важно учитывать ties — при равенстве сумм можно использовать RANK или DENSE_RANK, чтобы не терять заказы. Результат — отчёт по топ-3 заказам для каждого менеджера.

• Показывает знание оконных функций и альтернатив
• Упоминает обработку ties — важная деталь
• Есть конкретный пример объёма данных

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

RANK присваивает одинаковым значениям один номер, но следующий номер пропускает, а DENSE_RANK не пропускает. В отчётности это критично для топ-N и рейтингов. В одном проекте по продажам на 12 000 строк нужно было вывести топ-10 клиентов. Два клиента имели одинаковую выручку. RANK даёт места 1, 1, 3, а DENSE_RANK — 1, 1, 2. Для управленческого дашборда выбрали DENSE_RANK, чтобы не терять второе место и не сбивать нумерацию. А для поиска сотрудников с максимальными бонусами использую RANK — там важно видеть разрывы. Главное — понимать, нужен ли непрерывный рейтинг или честный пропуск.

• Чётко объясняет разницу на примере с одинаковыми значениями.
• Показывает понимание бизнес-контекста топ-N.
• Приводит конкретные цифры из своего опыта.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Когда запрос начинает работать медленно, первым делом смотрю план выполнения. Ищу узкие места: сканирование больших таблиц, отсутствие индексов, неудачные соединения или неявные преобразования типов. Проверяю статистику и актуальность индексов. Часто помогает переписать запрос: убрать коррелированные подзапросы, заменить на JOIN, добавить фильтры до агрегации. В одном случае удалось сократить время выполнения с 15 минут до 20 секунд за счёт составного индекса и переписывания подзапроса. Также рассматриваю материализацию или партиционирование для больших таблиц. В итоге время отклика падает в разы, и отчёт становится пригодным для интерактивной работы.

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

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

NULL в SQL означает неизвестное значение, а не пустую строку или ноль. Любое сравнение с NULL даёт неизвестный результат, поэтому используются IS NULL или IS NOT NULL. COUNT(*) считает все строки в выборке, а COUNT(column) — только строки, где в этом столбце есть значение, то есть не NULL. В одном отчёте по 5000 заказов в поле скидки у 1200 было NULL, и COUNT(скидка) возвращает 3800, а COUNT(*) — 5000. Поэтому для подсчёта заполненности поля всегда использую COUNT(column), а для общего числа строк — COUNT(*).

• Чётко объясняет трёхзначную логику и разницу функций
• Приводит конкретный пример с числами
• Показывает практическое применение в отчётности

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В моей практике с Power BI основная задача — строить отчётность для бизнеса. Обычно организую модель по схеме «звезда»: фактовая таблица с продажами и несколько измерений — клиенты, товары, время, менеджеры. Связи настраиваю по суррогатным ключам, чтобы избежать неоднозначностей. В Power Query привожу типы, убираю дубли, создаю справочники. Меры пишу на DAX для динамических расчётов, а вычисляемые столбцы — только когда нужно срезы или связи. Мой опыт включает проект с моделью на 12 таблиц и 5 млн строк, где обновление занимает 5 минут, а отчётами пользуются 40 человек.

• Показывает понимание схемы «звезда»
• Упоминает Power Query и DAX
• Есть конкретные цифры по объёму и пользователям

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Мера в DAX вычисляется на лету в зависимости от контекста фильтра и не хранится в модели. Вычисляемый столбец рассчитывается построчно при обновлении и занимает место в памяти. Меры использую для агрегатов: сумма продаж, средний чек, динамика. Столбцы — когда нужно использовать значение в срезах, связях или в строках отчёта. В модели на 5 млн строк вычисляемый столбец с категорией увеличивает размер файла примерно на 20%, а мера для той же суммы не добавляет объёма. Поэтому для интерактивных расчётов предпочитаю меры, а столбцы — только для атрибутов.

• Ясно разделяет контекст вычисления и хранения
• Приводит пример влияния на размер модели
• Даёт практические рекомендации по применению

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В моей работе CALCULATE — основной инструмент управления контекстом. Он принимает выражение и фильтры, которые переопределяют текущий контекст: можно добавить условие, убрать его через ALL или изменить. Зачем нужен? Чтобы считать показатели в разрезах, которых нет в визуале: долю категории, сравнение с прошлым периодом. Пример: мне приходилось вести отчёт по продажам, где требовался расчёт доли каждой категории в общем объёме. Я применяю CALCULATE с ALL, чтобы снять фильтр категории, и DIVIDE. В итоге 15 метрик удалось сократить до 5, а скорость обновления выросла на 40%.

• Чётко объясняет механику фильтров и контекста.
• Приводит практический пример с конкретными цифрами.
• Показывает знание ALL и DIVIDE.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Моя задача — не нарисовать красиво, а сделать инструмент для решений. Начинаю с вопросов: какие решения принимаются, как часто, кто смотрит и что делает, если показатель отклонился. Дальше — прототип на бумаге и согласование метрик до разработки, чтобы не переделывать логику потом. Первый экран ограничиваю пятью-семью ключевыми показателями, остальное убираю в детализацию. После запуска смотрю возвращаемость: по одному из дашбордов доля еженедельных пользователей среди целевой аудитории выросла примерно с тридцати до семидесяти процентов, а число разовых запросов к аналитику снизилось почти вдвое.

• Начинает с решений, а не с графиков
• Прототип и согласование метрик до разработки
• Меряет успех возвратом пользователей, а не красотой

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Чаще всего в работе — выручка и маржа, воронка и конверсии, retention, средний чек, unit-экономика. Главный риск не в расчёте, а в определении: у двух команд одна метрика может означать разное. Поэтому веду глоссарий: формулировка, знаменатель, фильтры, владелец, источник. Перед публикацией сверяю итоги с финансовой отчётностью и проверяю расчёт на исторических данных. В одном проекте расхождение по выручке между отделами доходило до восьми процентов, а после согласования глоссария на шестьдесят метрик оно сократилось примерно до одного процента.

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

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Выбор инструмента для меня всегда начинается с задачи, а не с личных предпочтений. Смотрю на три вещи: источник данных и объём, кто будет пользоваться отчётом и как часто, и как результат встроится в процессы. Например, для регулярной управленческой отчётности по продажам с ежедневным обновлением мне приходилось собирать модель на несколько десятков показателей и десятки источников — там важнее управляемая семантическая модель, права доступа и обновление по расписанию. Если нужен быстрый исследовательский дашборд для команды, беру инструмент, где скорость подготовки выше. В одном проекте такой подход сократил время подготовки отчёта с двух дней до пары часов. Главное — чтобы пользователь получал ответ на свой вопрос, а не изучал новый интерфейс.

• Показывает критерии выбора, а не спор о брендах
• Есть конкретный результат: с двух дней до пары часов
• Ответ опирается на потребности пользователя отчёта

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Хранилище — это отдельный слой для аналитики: данные собираются из разных систем, приводятся к общим справочникам и хранятся с историей, чтобы можно было смотреть динамику и сравнивать на любую дату. Схема обычно звёздная или снежинка, оптимизированная под чтение больших выборок. Операционная база — про транзакции: она нормализована, быстрая на записи и хранит в основном текущее состояние, а тяжёлые аналитические запросы её тормозят. На одном проекте в операционной базе шли сотни операций в секунду, а в хранилище лежали витрины с историей за пять лет по десяткам миллионов строк.

• Разделяет назначение: аналитика против транзакций
• Упоминает историю и схему хранения
• Подкрепляет объяснение примером объёмов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Схема «звезда» — это когда в центре таблица фактов, а вокруг неё измерения. Факт хранит измеримые события: сумму продаж, количество, маржу — и ключи, по которым связан с измерениями. Измерения описывают контекст: клиент, товар, точка продаж, дата. Структура получается денормализованная, но понятная: меньше соединений, выше скорость запросов, аналитик собирает любые срезы, не зная деталей учётной системы. Мне приходилось переводить отчётность на такую модель: около двадцати источников, а подготовка сводного отчёта сократилась с нескольких часов до минут, и бизнес самостоятельно начал строить срезы в дашборде.

• Сразу даёт определения факта и измерения — видно понимание терминов.
• Есть пример из практики с измеримым результатом, а не только теория.
• Показана польза для бизнеса: скорость запросов и самостоятельность пользователей.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

ETL — это конвейер: забираю данные из источников, привожу к нужному виду и загружаю в витрины, обычно инкрементально, по ключу и времени изменения. Качество контролирую на каждом шаге: проверки на уникальность ключей, полноту за период, ссылочную целостность справочников, свежесть загрузки и резкие отклонения от обычного уровня. Критичные проверки останавливают загрузку и отправляют алерт, остальные попадают в отчёт о качестве. В одном конвейере настроено больше двухсот автотестов, и доля инцидентов, которые находили пользователи, а не система, снизилась примерно втрое.

• Описывает шаги конвейера простыми словами
• Перечисляет конкретные виды проверок
• Показывает эффект на числе инцидентов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Называет реальные порядки объёмов данных
• Перечисляет практические приёмы оптимизации
• Заканчивает измеримым ускорением отчёта

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.