Собеседование на BI-разработчика

Проверь себя · 1/3разбор после ответа

В таблице orders поле promo_code может быть NULL. Что произойдёт со строкой, где promo_code = NULL, при фильтре WHERE promo_code <> 'NONE'?

Что спрашивают

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

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

Продвинутый SQL — главный навык BI

SQL для BI-разработчика — это не «SELECT с парой JOIN», а инструмент, на котором вы каждый день собираете витрины. Спрашивают оконные функции (ROW_NUMBER, RANK, LAG/LEAD, SUM OVER), многошаговые запросы через CTE, агрегации с правильной гранулярностью и, главное, оптимизацию: как ускорить тяжёлый отчёт, что покажет план выполнения, когда поможет индекс, а когда — предрасчёт. На этой секции отсеивают чаще всего, потому что слабый SQL означает медленные витрины и дашборды, которые тормозят.

Моделирование данных и DWH

BI-разработчик должен понимать, как разложить данные в схему, удобную для отчётности. Базовый вопрос — разница между схемой «звезда» и «снежинка», когда какую выбирать и чем они платят за свои плюсы. Сюда же относятся понятия факта и измерения, гранулярность таблицы фактов, медленно меняющиеся измерения (SCD) и общее устройство хранилища: зачем отдельный слой витрин поверх сырых данных и почему аналитические запросы не гоняют по продакшен-базе приложения.

BI-инструменты

Один инструмент нужно знать глубоко, а не «мышкой по верхам». В российских компаниях это чаще DataLens (Яндекс, Lamoda, ВкусВилл) или Power BI с языком DAX, в классическом enterprise и банках — Power BI, в стартапах — open-source Superset или Metabase, в зарубежных и исторических стеках — Tableau и Looker. Спрашивают про модель данных инструмента, расчётные поля и меры, кэширование, права доступа и про то, как вы решали конкретные задачи именно в нём.

ETL для витрин

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

Дизайн дашбордов

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

Оптимизация запросов и витрин

Отдельный пласт вопросов — про производительность. Дашборд, который открывается полминуты, бизнес просто перестаёт открывать. Поэтому спрашивают, как ускорить отчёт: предрасчёт агрегатов, материализованные представления, инкрементальное обновление витрины, партиционирование, колоночные хранилища вроде ClickHouse, перенос тяжёлых вычислений из инструмента в SQL-слой. Важно уметь объяснить trade-off каждого подхода, а не просто перечислить приёмы.

Метрики и расчёты

BI-разработчик постоянно переводит размытые формулировки заказчика в точные определения метрик. Здесь проверяют, умеете ли вы зафиксировать, что именно считается, на какой гранулярности и из какого источника. Классические темы — разница между метрикой (мерой) и измерением, расчёт конверсии и удержания, безопасное деление, чтобы не получить ноль или падение на делении на ноль, и согласованность одной метрики между разными дашбордами.

Этапы собеседования

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

Дальше идёт техническая SQL-секция примерно на час. Вам дают схему из нескольких таблиц и просят вживую написать запросы — с оконными функциями, агрегациями и нередко с просьбой подумать про оптимизацию. Оценивают не только итоговый результат, но и ход мысли: проговаривайте, почему берёте именно такой JOIN, что будет с NULL и как запрос поведёт себя на больших данных.

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

Затем обычно следует секция по конкретному BI-инструменту на сорок-шестьдесят минут — глубокий разбор DataLens, Power BI или Tableau в зависимости от стека компании. Завершает цикл поведенческое интервью по STAR-формату: как вы общались с заказчиками, разрешали конфликты приоритетов и доводили дашборд от запроса до внедрения.

Почему проваливают

Технически грамотные кандидаты регулярно срезаются на одних и тех же местах. Эти ловушки повторяются из собеседования в собеседование, и почти все они про разрыв между «знаю инструмент» и «решаю задачу бизнеса».

«Я только SQL, BI-инструмент быстро освою». На собесе хотят глубину хотя бы в одном инструменте. Поверхностное «кликал в Tableau пару раз» читается мгновенно и закрывает оффер.
Дашборд без бизнес-вопроса. Кандидат сразу рисует графики, не спросив, кто и какие решения будет принимать. Красивый, но бесполезный дашборд — типичный провал кейс-секции.
Игнор производительности. Решение собрано правильно, но витрина не оптимизирована, дашборд грузится полминуты. В реальности таким никто не пользуется, и интервьюер это знает.
Слабое моделирование. Путаница между фактом и измерением, неумение объяснить выбор между звездой и снежинкой или отсутствие понятия гранулярности выдаёт, что человек собирал дашборды поверх чужих витрин, не понимая их устройства.
Игнор принципов визуализации. Перегруженный дашборд с десятком виджетов на экране, где невозможно найти главную цифру. Дашборд должен читаться за секунды, а не впечатлять количеством графиков.

Примеры вопросов с разбором

Попробуйте ответить сами, прежде чем читать разбор.

Чем схема «звезда» отличается от «снежинки»? В звезде таблица фактов окружена денормализованными измерениями — все атрибуты лежат прямо в таблице измерения. В снежинке измерения нормализованы и разбиты на подтаблицы. Звезда даёт меньше JOIN и более быстрые запросы ценой избыточности; снежинка экономит место и упрощает поддержку справочников, но усложняет запросы. Для BI обычно выбирают звезду — скорость отчётов важнее экономии хранилища.
В чём разница между мерой и измерением? Мера (measure) — числовой агрегируемый показатель: выручка, число заказов, средний чек. Измерение (dimension) — атрибут, по которому меру режут: дата, регион, категория товара, канал. На дашборде меры попадают в значения графиков, измерения — в оси, фильтры и легенды. Путаница между ними — частая причина неправильной модели данных.
Что такое медленно меняющиеся измерения (SCD)? Это подход к хранению атрибутов измерения, которые меняются со временем, — например, регион менеджера или сегмент клиента. Type 1 просто перезаписывает значение и теряет историю. Type 2 добавляет новую строку с датами действия и флагом актуальности, сохраняя всю историю. Type 3 хранит предыдущее значение в отдельной колонке. Для исторической отчётности почти всегда нужен Type 2.
Как ускорить медленную витрину для дашборда? Сначала смотрят план выполнения, чтобы найти узкое место. Дальше типовые приёмы: предрасчёт агрегатов и материализованные представления вместо тяжёлых вычислений на лету, инкрементальное обновление вместо полного пересчёта, партиционирование больших таблиц, колоночное хранилище для аналитики и перенос логики из BI-инструмента в SQL-слой. Главное на собесе — объяснить trade-off каждого варианта.
Чем материализованное представление отличается от обычного? Обычное представление (view) — это сохранённый запрос, который пересчитывается при каждом обращении, поэтому всегда отдаёт свежие данные, но медленно на тяжёлой логике. Материализованное представление хранит уже вычисленный результат на диске и читается быстро, но требует обновления по расписанию и потому может отдавать слегка устаревшие данные. Для дашбордов это классический компромисс между скоростью и свежестью.
Что такое расчётное поле и DAX? Расчётное поле — это метрика, которую вы определяете внутри BI-инструмента поверх модели данных. В Power BI для этого используют язык DAX: меры вроде Total Sales = SUM(Sales[Amount]) и функцию CALCULATE, которая меняет контекст фильтрации. Ключевая идея DAX — различие контекста строки и контекста фильтра; именно непонимание этого ломает расчёты. В Tableau аналогичную роль играют calculated fields.
Как бы вы спроектировали дашборд для коммерческого директора? Сначала уточнить, какие решения он принимает и как часто смотрит отчёт. Затем вынести наверх две-три ключевые цифры — выручка, динамика к плану, маржа, — добавить тренд по времени и разрезы по продуктам и регионам через фильтры. Детализацию убрать на второй уровень или в drill-down, чтобы первый экран читался за секунды. И заложить производительность: руководитель не будет ждать загрузку.
Зачем нужен отдельный слой витрин, если есть сырые таблицы? Сырые данные нормализованы под запись и приложение, запросы по ним медленные и сложные. Витрина — это предрасчитанный, удобный для чтения слой под конкретные отчёты: нужная гранулярность, понятные имена, уже посчитанные метрики. Она ускоряет дашборды, снимает нагрузку с продакшен-базы и даёт единый источник правды для метрик.
Чем ETL отличается от ELT? В ETL данные извлекают, преобразуют на отдельном движке и только потом грузят в хранилище. В ELT их сначала загружают в мощное хранилище, а преобразуют уже внутри него средствами SQL. ELT выигрывает на современных колоночных DWH, где вычисления дешевле делать на месте; ETL остаётся там, где преобразование тяжёлое или источник нельзя грузить целиком.
Как посчитать конверсию, чтобы не получить ноль или ошибку? Приводить числитель к дробному типу и защищать делитель от нуля: SUM(converted)::NUMERIC / NULLIF(COUNT(*), 0). Без приведения типа целочисленное деление в Postgres усечёт результат до нуля, а без NULLIF запрос упадёт на делении на ноль, когда знаменатель пуст. Это базовая, но очень частая ловушка в витринах с метриками.

Главные темы по разделам

SQL и оптимизация

Моделирование данных и DWH

BI-инструменты

ETL и витрины

Дашборды и визуализация

Метрики и бизнес-понимание

Как готовиться

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

Третью неделю отведите на BI-инструмент целевой компании: разберите его модель данных, расчётные поля или DAX, кэширование и права доступа, соберите пару дашбордов руками. Четвёртую — на моделирование: звезда и снежинка, факты и измерения, SCD, агрегаты под витрины. Пятую посвятите кейсам «спроектируй дашборд»: возьмите пять-десять бизнес-задач и проговорите вслух, какие метрики, фильтры и источники нужны. Последнюю неделю оставьте на мок-собесы и поведенческие вопросы, чтобы натренировать структуру ответа и спокойную подачу.

Частые ошибки

Главная ошибка на кейс-секции — сразу проектировать дашборд, не выяснив, кто им будет пользоваться и какие решения принимать. Без бизнес-вопроса любой набор графиков выглядит произвольным, и интервьюер это считывает. Вторая частая ошибка — недооценивать производительность: правильно собранная, но медленная витрина в реальной работе бесполезна, поэтому про скорость стоит думать с самого начала, а не «потом оптимизирую».

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

Другие темы

FAQ

BI-разработчик или аналитик данных — в чём разница?

BI-разработчик больше про инфраструктуру отчётности: витрины, моделирование данных, дашборды и их производительность. Аналитик данных больше про разовые исследования, гипотезы и презентацию выводов. Карьерные пути пересекаются, и многие переходят из одной роли в другую, но на собесе BI глубже копают SQL, моделирование и сам BI-инструмент.

Какой BI-инструмент учить первым?

Ориентируйтесь на рынок, на который целитесь. В России чаще всего просят DataLens (стек Яндекса и многих крупных компаний) или Power BI с языком DAX, особенно в банках и классическом enterprise. Для зарубежных компаний и исторических стеков актуальны Tableau и Looker. Учить лучше один инструмент глубоко, чем три поверхностно.

Нужен ли Python для BI-разработчика?

Базовый — желателен: Pandas для подготовки данных и автоматизации рутинных выгрузок встречается часто. Глубокий Python или ML обычно не требуют — это уже территория дата-инженера и дата-сайентиста. На собесе по BI Python почти всегда вторичен по сравнению с SQL.

Сколько этапов обычно в цикле собеседования?

Чаще всего четыре-пять: скрининг с рекрутером, техническая SQL-секция, кейс с дашбордом, секция по конкретному BI-инструменту и поведенческое интервью. Весь цикл занимает от одной до трёх недель в зависимости от компании и уровня позиции.

Какие зарплаты у BI-разработчика?

Точные цифры сильно зависят от региона, грейда, компании и стека, поэтому ориентируйтесь на них как на порядок величины, а не гарантию. Junior-позиции стартуют заметно ниже middle, а senior с сильным SQL и опытом проектирования витрин ценятся ощутимо выше. Актуальные вилки смотрите в открытых вакансиях на момент поиска.

Где практиковать перед собесом?

Тренируйте SQL короткими задачами с моментальным разбором — например, в SQL-тренажёре — и собирайте учебные дашборды на публичных датасетах (Kaggle, открытые данные). Параллельно проговаривайте кейсы «спроектируй дашборд» вслух: на собесе ценят именно ход мысли, а не готовый набор графиков.

Открыть Карьерник в Telegram