Собеседование BI-аналитика: дашборды, Excel, SQL и бизнес-кейсы

Коротко

Сильный BI-ответ начинается с пользователя дашборда. Кто смотрит экран, как часто, какое решение принимает и какой уровень детализации ему нужен? Только после этого выбирай KPI, фильтры, периодичность обновления и визуальный тип.

• Не смешивай выручку, заказы и маржу без определения зерна и денежных правил.
• Для каждого KPI покажи формулу, источник, владельца и допустимую задержку.
• Дашборд должен помогать заметить отклонение и перейти к причине.
• Проверяй дубли, пропуски, период и сверку с финансовым источником.
• В кейсе отделяй “что произошло” от “почему” и “что делать”.

Задача 1: спроектировать дашборд для руководителя

Промпт: “Сделай дашборд продаж для CEO”. Не начинай с десяти графиков. Спроси, какие решения нужно принимать: понять план-факт, увидеть проблемный канал, проверить маржу или найти задержку в воронке. Затем раздели экран на слой состояния, слой диагностики и слой действий.

На первом экране оставь несколько KPI с периодом сравнения и явным статусом данных. Ниже покажи тренд и разложение отклонения. Детализацию вынеси в drill-down. Если всё поместить на один экран, дашборд превратится в каталог цифр, а не в рабочий инструмент.

Задача 2: выбрать KPI и не перегрузить экран

Если бизнес просит “все метрики”, верни вопрос к решениям. Для e-commerce могут понадобиться GMV, net revenue, orders, conversion, average order value и returns. Но на главном экране достаточно тех, которые меняют решение. Остальные должны быть доступны через детализацию или отдельный лист.

У каждого KPI должен быть контракт: название, формула, зерно, период, фильтры, источник, владелец и дата последнего обновления. ARPU на активного пользователя и revenue per account могут выглядеть похожими, но отвечают на разные вопросы. Без контракта команда будет спорить о цифре вместо решения.

Задачи 3–5: SQL-слой под дашбордом

BI-задача часто скрывает вопрос о модели данных. Нельзя соединять таблицу заказов, позиции и платежи без понимания, сколько строк получится. Для регулярного отчёта заранее подготовь слой на нужном зерне: например, одна строка на заказ с net revenue, каналом и статусом, а затем агрегируй его для графика.

Если один виджет считает revenue по orders, а другой — по order_items, цифры могут расходиться. На собеседовании назови единый источник истины и контрольную сверку. Для финансовых показателей добавь правила возвратов, скидок, валют и закрытых периодов.

with item_totals as (
  select order_id, sum(quantity * price) as gross_revenue
  from order_items
  group by order_id
), normalized_orders as (
  select o.order_id, o.channel, o.status,
    o.discount,
    coalesce(i.gross_revenue, 0) - coalesce(o.discount, 0) as net_revenue
  from orders o
  left join item_totals i using (order_id)
)
select date_trunc('month', created_at)::date as month,
  channel, sum(net_revenue) as net_revenue,
  count(*) filter (where status = 'paid') as paid_orders
from normalized_orders
where created_at < current_date
group by 1, 2;

Задача 6: Excel и ручная проверка

Даже если вакансия ориентирована на BI, могут спросить про Excel: сводные таблицы, XLOOKUP, SUMIFS, обработку ошибок и проверку выгрузки. Отвечай через сценарий. Если нужно быстро проверить небольшую таблицу — Excel удобен. Если расчёт регулярный, большой или критичный, перенеси логику в SQL/BI и оставь Excel как контрольный срез, а не единственный источник.

Любой lookup проверяй на уникальность ключа. Если справочник содержит два соответствия для одного клиента, формула может вернуть первое и скрыть качество данных. Для ручной сверки используй контрольные итоги, условное форматирование и отдельный лист с исключениями.

• Проверить типы дат и чисел после импорта.
• Сверить количество строк и сумму с исходной выгрузкой.
• Найти дубли ключа до XLOOKUP или JOIN.
• Отдельно показать пропуски и unmatched значения.
• Зафиксировать дату выгрузки и фильтры отчёта.

Задача 7: почему показатель на дашборде изменился

Кейс “маржа упала” требует такой же декомпозиции, как продуктовый DAU. Сначала проверь дату обновления, формулу и источник. Затем раздели показатель на цену, объём, mix товаров, скидки, возвраты и комиссии. После этого найди сегмент или период, который объясняет большую часть изменения.

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

Задача 8: сделать дашборд понятным

Попроси интервьюера назвать пользователя и контекст просмотра. CEO и операционный менеджер не должны видеть одинаковую детализацию. Для руководителя важны отклонение, тренд и риск. Для операционной команды — очередь, причины и список объектов, с которыми нужно работать.

Используй заголовки, которые отвечают на вопрос, а не только называют поле. “Выручка по каналам” слабее, чем “Падение net revenue пришло из paid social”. Не подменяй вывод цветом: подпиши период, единицы, фильтры и состояние данных. Пустой результат должен отличаться от нулевого.

Коммуникация BI-аналитика

BI-аналитик часто получает конфликтующие запросы: бизнес хочет данные “прямо сейчас”, финансы требуют точности, а команда продукта меняет определение показателя. На собеседовании расскажи, как фиксируешь приоритет, согласуешь контракт и показываешь ограничения. Не обещай одновременно мгновенную скорость и идеальную историческую сопоставимость, если для этого нет данных.

Хороший ответ содержит договорённость: временный оперативный график с пометкой качества, затем финальный слой после сверки. Так ты не блокируешь решение, но не превращаешь черновик в источник истины. Это особенно важно при миграции источников и изменении схемы.

• Сначала выяснить решение и срок, затем выбирать форму отчёта.
• Зафиксировать owner метрики и критерий готовности.
• Показать известные ограничения прямо на дашборде.
• Разделить оперативную и финансовую версии показателя.
• Оставить ссылку на методологию и контрольную сверку.

Семантический слой и модель данных

В BI-интервью часто проверяют, умеешь ли ты отделить сырые таблицы от слоя, который читают отчёты. Если каждый дашборд по-своему считает active customer, расхождения неизбежны. Опиши семантический слой: сущности, измерения, факты, календарь, статусы и определения KPI. Для каждой метрики зафиксируй grain и допустимые фильтры.

Простой пример: факт orders на уровне заказа, dim_customer на уровне клиента, dim_date для календаря, а возвраты либо отдельный факт, либо нормализованная транзакция с отрицательным amount. Нельзя бездумно складывать строки разных фактов. Если нужно совместить продажи и возвраты, сначала приведи их к общей экономической единице.

Мини-кейс: руководитель не верит дашборду

Не защищай график внешним видом. Сначала попроси два конкретных примера расхождения и сравни определения, период, фильтр и источник. Часто “дашборд врёт” означает, что в Excel использовали дату оплаты, а в BI — дату создания заказа, или один отчёт вычитает возвраты, а другой показывает gross revenue.

После локализации подготовь reconciliation table: показатель в источнике, показатель в модели, разница, причина и решение. Если исправление требует времени, пометь текущую версию и не скрывай ограничение. Доверие к BI восстанавливается прозрачной сверкой, а не ещё одной визуальной настройкой.

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

Как объяснить визуальный выбор

На собеседовании могут попросить выбрать график для тренда, сравнения категорий или распределения. Отвечай через вопрос. Линия нужна для изменения во времени, горизонтальные бары — для сравнения объектов, scatter — для связи двух числовых признаков, histogram или boxplot — для формы распределения. Не используй pie chart, если категории трудно сравнить или их слишком много.

Объясни, какие единицы и период будут видны, где появится baseline и как пользователь найдёт исключение. Хорошая визуализация не обязана быть эффектной. Её задача — сократить путь от сигнала к следующему действию.

Как подготовить портфолио к BI-собеседованию

Возьми один бизнес-кейс и покажи не только скриншот дашборда. Добавь краткий вопрос заказчика, схему источников, KPI-контракт, SQL-слой, контроль качества и два решения, которые поддерживает экран. Объясни, какие графики ты убрал и почему. Это показывает мышление сильнее, чем галерея из десяти страниц.

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