Вопросы для подготовки к собеседованию на позицию Data Engineer

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

Ниже собраны вопросы на собеседовании Data Engineer с разбором ответов. Разберём SQL, модель хранилища, оркестрацию, стриминг и один проектный кейс. Формулировки в компаниях разные. Важно уметь уточнить объём, задержку и зерно, а не перечислить тулы.

Стек 2026 обычно выглядит так: SQL, склад, Airflow, Spark или Kafka, dbt, иногда Iceberg. Hadoop в вакансиях ещё встречается, но как наследство, не как базовый навык года. Открытый банк Enigmai показывает 131 заголовок, много общих вопросов по Python и CS, а модельные ответы закрыты. Здесь разберём именно пайплайны инженера данных.

Как проходит собеседование Data Engineer

Как проходит собеседование Data Engineer, зависит от компании, но почти всегда это несколько технических встреч, а не один час «про себя». Рекрутер сверяет стек и контур данных. Дальше отдельно смотрят SQL, модель хранилища и умение спроектировать загрузку.

Карьерник описывает типичную нарезку так. Скрининг 20–30 минут. SQL около 60 минут. Моделирование и DWH 45–60 минут. Дизайн пайплайна около 60 минут. Поведенческий блок около 45 минут. Это ориентир одной площадки, не единый ГОСТ.

У Skypro другая схема: скрининг 15–20 минут, техника 60–90, системный дизайн 45–60, культура 30–45. Не смешивайте минуты из двух гайдов в один «стандарт рынка». На конкретной вакансии набор встреч короче или длиннее.

Грейд меняет глубину, а не список тем. Junior объясняет JOIN, идемпотентность и простой DAG. Middle держит SCD, backfill и перекос в Spark. Senior связывает зерно, SLA и стоимость скана, а не только названия движков.

Ниже типичные этапы по Карьернику. Продуктовая команда дольше сидит в модели и оркестрации. Команда с легаси Hadoop может уйти в файлы и NameNode, хотя в 2026 это уже не общий дефолт.

Когда ответы на SQL и пайплайн уже складываются, полезно сверить стек с живыми вакансиями. В подборке разработки на HireHi видно, какие команды ждут Airflow, Spark, ClickHouse и склады.

Какие вопросы задают дата-инженеру

Какие вопросы задают дата-инженеру, почти всегда крутится вокруг четырёх рабочих тем. SQL и планы. Модель хранилища. Оркестрация и загрузка. Стрим, Spark и физика файлов. Soft skills спрашивают, но не вместо пайплайна.

Отдельно спрашивают про опыт: какой контур вы довели до прода, как чинили свежесть, что делали на backfill за годы истории. В кейсах смотрят, уточняете ли объём и SLA до выбора Kafka.

Практика показывает не словарный запас, а последовательность. Сначала зерно и объём, потом батч или стрим, потом идемпотентность и проверки. Банк Enigmai на 131 заголовок часто уводит в изоляцию транзакций и Python. Senior-вопросов в их счётчике всего один. Ниже разбираем пайплайны, а не CS-разминку.

Профессиональные вопросы Data Engineer

Разберём банк по рабочим темам, а не по Junior, Middle и Senior. Так удобнее повторять то, что реально спрашивают: от SQL до Iceberg. Грейд проявится в глубине ответа, а не в отдельной главке.

Открытые разборы Карьерника, Roasted.cv и старый кейс X5 Tech на Хабре сходятся в одном. Инженер данных должен объяснить, как данные едут, где ломаются и как переиграть загрузку без дублей.

SQL и работа с планом

Чем INNER JOIN отличается от LEFT и когда HASH JOIN уместнее nested loop?

Что проверяют. Не путаете ли вы семантику соединения с физическим оператором в плане.

Как отвечать. INNER оставляет только совпавшие ключи. LEFT сохраняет все строки левой стороны, даже без пары. Если измерение дырявое, INNER молча выкинет продажи. Nested loop хорош, когда одна сторона крошечная и есть индекс. HASH JOIN берут на больших аналитических соединениях, где вложенный цикл взорвёт время.

Демонстрационный ход. «Сначала скажу, какие строки должны выжить. Потом посмотрю кардинальность. Только после этого выберу оператор, а не наоборот.»

Зачем оконные функции, если уже есть GROUP BY?

Что проверяют. Умеете ли вы считать «рядом с деталью», а не только схлопнуть строки.

Как отвечать. GROUP BY теряет зерно: после него нет исходной строки. Окно считает сумму, ранг или лаг и оставляет деталь. Так находят дубли через ROW_NUMBER, считают долю строки в дне и берут следующий заказ через LEAD. На миллиардах окно без партиции по дате легко уходит в сортировку всего факта.

Демонстрационный ход. «Для следующего заказа пользователя пишу LEAD по user_id, а не группировку. И сразу сужаю окно партицией, чтобы сортировка не съела склад.»

Как найти дубли по бизнес-ключу и что с ними делать?

Что проверяют. Есть ли у вас правило, а не разовый DELETE.

Как отвечать. Сначала назовите ключ: заказ плюс источник, а не «все поля совпали». Дальше ROW_NUMBER по ключу и времени источника: оставляете последнюю версию, остальные в карантин. На стриме дубли приезжают из at-least-once, поэтому дедуп должен переживать повторную доставку. Мониторьте долю дублей, иначе тихий рост незаметен.

Почему индекс спасает OLTP и часто не нужен в ClickHouse?

Что проверяют. Отличаете ли строковое OLTP от колоночного OLAP.

Как отвечать. В Postgres индекс сужает точку: один заказ, один клиент. В колоночнике вроде ClickHouse выигрыш даёт сортировочный ключ, партиция и чтение нужных столбцов. Вторичный индекс на каждую колонку витрины чаще мешает вставке. Для аналитики важнее, чтобы фильтр попал в ключ сортировки, а не в десяток btree.

Как разбирать медленный аналитический запрос, не гадая?

Что проверяют. Идёте ли вы от фактов плана, а не от совета «добавь индекс».

Как отвечать. Сначала смотрите, сколько байт сканируется и сработала ли обрезка партиций. Потом джойн: не раздуло ли строки, нет ли перекоса ключа, не ушло ли на диск. В учебном примере Roasted.cv запрос на миллиардах уходит из десятков секунд в минуты, когда теряется обрезка партиций или джойн размножает строки. Это разборный кейс, не статистика рынка.

Демонстрационный ход. «Сначала EXPLAIN и байты. Потом проверка зерна джойна. Только потом кластер, соль ключа или витрина.»

Моделирование и хранилище

Когда выбирать звезду, а когда снежинку?

Что проверяют. Понимаете ли цену джойнов в аналитике, а не рисуете схему «как в третьей нормальной».

Как отвечать. Звезда: факт в центре, измерения рядом, мало джойнов. Снежинка нормализует измерения на уровни: город в регионе, регион в стране. Для витрин и BI обычно звезда. Снежинку берут, когда измерение огромное и его правят отдельно, либо когда так уже живёт ядро. Не зовите снежинку «более правильной». Для дашборда лишний джойн часто дороже.

Что такое SCD и чем SCD2 опасна на жирных атрибутах?

Что проверяют. Умеете ли вы хранить историю измерения, не раздувая факт.

Как отвечать. SCD1 перезаписывает атрибут: вчерашний сегмент клиента теряется. SCD2 открывает новую версию с датами действия. Её опасно вешать на часто меняющееся поле вроде статуса сессии: на одного клиента вырастут десятки строк. Тогда выносят летучий атрибут в мини-измерение или в факт. Для отчёта «как было на дату» нужен as-of, а не только текущая строка.

Зачем суррогатный ключ, если в источнике уже есть id?

Что проверяют. Думаете ли вы про несколько систем и SCD2, а не про один CRM.

Как отвечать. Натуральный id живёт в системе-источнике и может повториться в другой. Суррогат стабилен внутри склада и переживает SCD2: одна сущность, несколько версий. Для идемпотентной загрузки удобен детерминированный хеш системы, исходного id и начала версии. Тогда параллельные воркеры не плодят разные ключи на одну сущность.

Как выбрать зерно факта и не смешать два процесса в одной таблице?

Что проверяют. Слышите ли вы процесс, а не сразу рисуете широкую таблицу.

Как отвечать. Зерно это ответ на вопрос «что описывает одна строка». Чек, строка чека, день-магазин-SKU это три разных факта. Если смешать оплату и отгрузку, метрики разъедутся. Сначала назовите процесс и зерно, потом измерения и меры. Широкую таблицу для дашборда можно собрать сверху, но не делать её единственным источником правды.

Почему в хранилище денормализуют то, что в OLTP держат нормализованным?

Что проверяют. Не путаете ли вы цель учёта транзакций и цель аналитики.

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

Оркестрация, загрузка и качество

Чем ETL отличается от ELT и что берут в 2026?

Что проверяют. Понимаете ли, где крутится трансформ, а не зубрите аббревиатуру.

Как отвечать. ETL преобразует данные до склада: Spark или Python пишут уже готовую витрину. ELT грузит сырьё как есть, а трансформ живёт в SQL склада, часто через dbt. В 2026 на облачных складах чаще ELT: дешевле крутить SQL рядом с данными. ETL остаётся, когда сырьё тяжёлое, грязное или склад не должен видеть сырой контур. Смешанная схема нормальна: сырой слой плюс трансформ в складе.

Как сделать загрузку идемпотентной при retry и backfill?

Что проверяют. Не нарисуете ли вы пайплайн, который при повторе удваивает факты.

Как отвечать. Идемпотентность значит: повторный прогон за ту же дату даёт тот же результат. Практические приёмы: overwrite партиции дня, MERGE по бизнес-ключу, детерминированные суррогаты. Нельзя делать голый INSERT из файла, который датчик Airflow может прочитать дважды. Backfill тех же дат должен быть безопасен. Если шаг пишет в две системы, оба шага обязаны переживать повтор.

Что такое catchup и depends_on_past в Airflow и когда они мешают?

Что проверяют. Понимаете ли вы поведение DAG на истории, а не только cron.

Как отвечать. Catchup догоняет пропущенные интервалы, когда DAG стоял. На годах истории это очередь тяжёлых прогонов. Depends_on_past не даёт сегодняшней таске стартовать, пока вчерашняя не успела: удобно для накопительного счёта и опасно, если вчера застряло навсегда. Для независимых дневных партиций чаще хватает overwrite дня без depends_on_past. Ретраи ставьте на сбой инфраструктуры, а не на «может, источник сам починится» без алерта.

Как партиционировать факты, чтобы не получить море мелких файлов?

Что проверяют. Связываете ли ключ партиции с реальными запросами и с физикой файлов.

Как отвечать. Партиция должна резать скан: обычно дата события или день загрузки. Слишком мелкая нарезка, например магазин плюс час на 20 тысячах точек, рождает миллионы файлов. Тогда метаданные и листинг каталога стоят дороже чтения. Сначала назовите фильтры дашборда. Потом размер файла 100–500 МБ в Parquet как ориентир, не догма. Перекос по дате промо лучше лечить солью или отдельной витриной, а не случайным ключом на весь факт.

CDC или поле updated_at: как забирать изменения?

Что проверяют. Понимаете ли дыру инкремента по времени обновления.

Как отвечать. updated_at не видит жёсткое удаление: строки просто исчезают, инкремент их не заметит. CDC из лога транзакций видит insert, update и delete. Если CDC нет, нужен полный снимок ключей и anti-join, либо флаг soft-delete в источнике. Для справочника на тысячи строк чаще дешевле полная перезаливка, чем хрупкий инкремент.

Где проверять качество: на входе, в transform или на витрине?

Что проверяют. Есть ли у вас слои проверок, а не одна «надеемся на BI».

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

Стриминг, Spark и стек 2026

Какие гарантии доставки даёт Kafka и что из этого следует?

Что проверяют. Не путаете ли вы «сообщение не потеряется» с «строка не задублируется».

Как отвечать. At-most-once коммитит офсет до обработки: можно потерять запись. At-least-once обрабатывает, потом коммитит: будут дубли, нужен идемпотентный sink. Exactly-once собирают транзакцией продюсера и идемпотентной записью, это не бесплатная галочка. Ключ партиции определяет порядок внутри партиции, не по всей теме. Лаг консьюмер-группы это SLI, его надо видеть, а не вспоминать после жалобы бизнеса.

Как лечить перекос ключа в Spark?

Что проверяют. Узнаёте ли skew в симптомах, а не только в определении.

Как отвечать. Симптом: одна таска идёт в разы дольше остальных. Частые причины: NULL в ключе, один огромный клиент или служебный ключ по умолчанию. Лечение: вынести NULL отдельно, засольть горячий ключ, бродкастить маленькую сторону. В учебном разборе Roasted.cv одна таска может быть примерно в 20 раз медленнее соседних. Это способ объяснить перекос, не замер рынка.

Почему мелкие файлы в озере тормозят чтение?

Что проверяют. Понимаете ли цену открытия тысяч объектов, а не только «Parquet быстрый».

Как отвечать. Каждый мелкий файл это отдельный листинг, футер и кусок планирования. Spark и склад тратят время на задачи, а не на байты. Причина часто в слишком большом числе партиций или в микробатче без compaction. Лечение: coalesce на запись, отдельный job уплотнения, табличный формат вроде Iceberg, который умеет следить за файлами. Не лечите это новым кластером, пока не посчитали число объектов.

Когда нужен стрим, а когда хватит батча раз в час?

Что проверяют. Не ставите ли Kafka «потому что так современнее».

Как отвечать. Стрим нужен, когда задержка минуты меняет решение: антифрод, операционный мониторинг, онлайн-фичи. Если дашборд смотрят утром и SLA «данные за вчера к 8:00», часовой батч проще, дешевле и легче делать идемпотентным. Смешанная схема частая: стрим в операционный контур, батч в бухгалтерию метрик. Назовите latency и цену ошибки, потом брокер.

Зачем тесты dbt, если проверки уже стоят в DAG?

Что проверяют. Отличаете ли оркестрацию от контракта модели.

Как отвечать. DAG проверяет, что таска завершилась. dbt-тест проверяет смысл таблицы: уникальность ключа, not null, связь с измерением, допустимые значения. Snapshot в dbt это способ SCD2. Incremental должен переживать повтор и не сканировать всю историю без нужды. Тесты unique и not_null это минимум. Для выручки нужен тест зерна и проверка, что джойн не размножил строки.

Чем таблица Iceberg отличается от папки parquet?

Что проверяют. Видите ли разницу озера «как файлы» и озера «как таблица».

Как отвечать. Папка parquet не знает схему, снапшоты и атомарную замену. Iceberg хранит метаданные: схема, партиции, список файлов, история. Можно эволюционировать партиции, читать as-of и не ломать читателей полузаписью. Delta и Hudi закрывают похожий контур. В 2026 это частый ответ на «как не умереть на мелких файлах и schema drift», а не лекция про Hadoop 2019 года.

Когда брать ClickHouse, когда Postgres, когда облачный склад?

Что проверяют. Выбираете ли движок под запрос, а не «что было в прошлом проекте».

Как отвечать. Postgres хорош как OLTP и небольшой служебный слой. ClickHouse силён на широких агрегатах и свежих витринах, если сортировочный ключ совпал с фильтром. Облачный склад удобен, когда команда живёт в SQL и ELT, а скан оплачивается отдельно. Не тащите OLTP-нормализацию в ClickHouse. Не ждите от Postgres той же скорости колоночного скана по годам факта.

Озеро и хранилище: кто источник правды?

Что проверяют. Не смешиваете ли сырой слой, ядро и витрину для дашборда.

Как отвечать. Озеро держит сырую историю дешево и долго. Ядро склада даёт согласованную модель: зерно, ключи, SCD. Витрина обслуживает дашборд и не обязана быть источником правды. Если BI считает метрику иначе, чем склад, правды две и спор бесконечен. Сначала назовите, какой слой отвечает за цифру для бизнеса, потом рисуйте широкую таблицу.

Что спрашивают про опыт дата-инженера

Что спрашивают про опыт дата-инженера, почти никогда не сводится к списку тулов в резюме. Интервьюер хочет услышать контур: откуда данные, какое зерно, какой SLA, что ломалось. Названия Spark и Airflow без этой рамки звучат как витрина навыков, а не как работа.

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

Хорошая рамка такая. Задача и зерно. Ограничения источника. Что выбрали и почему не стрим. Как проверяли качество. Что увидели в проде через неделю. Не выдумывайте цифры. Если объём не помните, скажите порядок и как его тогда оценивали.

Отдельно спросят, как вы разговаривали с аналитиком или DS. Типичный конфликт: они хотят новое поле «вчера», а контракт источника плывёт. Сильный ответ показывает границу: что можно отдать витриной, а что надо чинить в источнике.

Какие ситуационные кейсы ждут дата-инженера

Какие ситуационные кейсы ждут дата-инженера, обычно про продакшен, а не про абстрактную этику. Ниже рабочие сцены. В каждой сначала назовите симптом и что проверите, потом лечение.

Витрина удвоила выручку без роста продаж. Что проверяете?

Что проверяют. Узнаете ли размножение строк от джойна с неуникальным измерением.

Как отвечать. Сначала сверка зерна: число строк факта до и после джойна. Если строки выросли, измерение не уникально по ключу или SCD2 приджойнили без as-of. Лечение: тест уникальности, выбор текущей версии, мост для M2M с коэффициентом, а не «поправлю в BI делением на два».

Утренний DAG упал, дашборд нужен через два часа. С чего начнёте?

Что проверяют. Умеете ли сузить инцидент, а не перезапускать всё подряд.

Как отвечать. Смотрите, какая таска и какой интервал, есть ли частичная запись, идемпотентен ли повтор. Если упал конец цепочки, сырой слой мог быть готов: пересобираете витрину, не весь год. Сообщаете SLA и что уже проверено. Тихий рестарт без понимания записи часто делает вторую беду: дубли.

Источник сменил тип поля и отдал пустые значения. Как ответите?

Что проверяют. Есть ли контракт и карантин, а не только «починим сегодня вечером».

Как отвечать. Жёсткая проверка схемы на входе должна была остановить сломанный слот, а не пропустить NULL в факт. Дальше: карантин партии, алерт владельцу источника, решение, чинить задним числом или оставить дыру с пометкой. Поле updated_at тут не спасёт, если тип сломался на полной выгрузке.

Поздние события приехали через пять дней после закрытия дня. Что с витриной?

Что проверяют. Различаете ли event time и время обработки.

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

Просят Kafka, хотя SLA дашборда «раз в сутки». Что скажете?

Что проверяют. Умеете ли отговорить от стрима ради моды.

Как отвечать. Спросите, какое решение меняется в минутах, а не в часах. Если никто не дежурит по лагу и витрина суточная, часовой батч проще в идемпотентности и дешевле в сопровождении. Стрим можно оставить на узкий операционный контур. На интервью это плюс, а не «кандидат не знает Kafka».

Какие практические задания дают дата-инженеру

Какие практические задания дают дата-инженеру, чаще всего трёх видов. Живой SQL. Разбор медленного скана. Дизайн загрузки под ограничения. Ниже разберём подход, а не готовый «правильный стек».

Спроектируйте витрину продаж: 100 тысяч SKU и 20 тысяч магазинов

Что проверяют. Уточняете ли зерно и слой хранения до выбора движка.

Как отвечать. Это учебные ограничения из статьи X5 Tech на Хабре за октябрь 2021 года, не описание их найма в 2026. Тогда интервьюеры называли порядка 100 тысяч SKU, 20 тысяч магазинов, около 2 миллиардов строк продаж в месяц, хранение нескольких лет и обновление раз в месяц. Запросы: маржа по категории за три года и топ городов за месяц.

Сначала зерно. Одна строка это продажа SKU в магазине за день или строка чека? Для месячной маржи по категории дневной агрегат часто достаточен как витрина. Сырую историю чеков держать в дешёвом слое, а не тащить в колоночник «как есть навсегда» без нужды.

Потом задержка. Обновление раз в месяц почти наверняка батч, не Kafka. Инкремент закрытого месяца overwrite партиции безопаснее голого INSERT. Для дашборда «топ городов за месяц» витрина в колоночнике вроде ClickHouse уместна. Ядро истории может жить в озере или складе с партицией по месяцу.

Чего не делать первым ходом. Не начинать с лекции про NameNode и случайный ключ партиции Spark на диапазон 0..1e9. Такой ход в разборе X5 Tech как раз рождал море мелких файлов. Сначала зерно, SLA и два слоя: история и витрина для дашборда. Движок после этого.

Разберите запрос, который на миллиардах ушёл из секунд в минуты

Что проверяют. Профилируете ли вы, а не предлагаете «оптимизировать Spark» вслепую.

Как отвечать. Учебный сюжет Roasted.cv: запрос к складу на порядка 5 миллиардов строк, который жил десятки секунд и стал занимать минуты. Сначала план и байты скана. Потеря обрезки по дате, размножение строк на джойне, перекос, сброс на диск. Сверьте число строк до и после джойна. Только потом соль, бродкаст или готовую витрину. Не называйте это статистикой всех компаний.

Напишите инкремент месяца без дыр и дублей

Что проверяют. Закрываете ли вы повтор, опоздание и удаление, а не только «WHERE updated_at».

Как отвечать. Для месячной партиции безопасный шаблон: пересобрать месяц целиком из согласованного слоя или MERGE по ключу чека. Проверки: число ключей, сумма чеков против источника, нет ли дыр в датах. Если источник удаляет строки, updated_at недостаточен. Нужен CDC, полная сверка ключей или soft-delete. Backfill того же месяца должен дать ту же сумму.

Как подготовиться к собеседованию Data Engineer

Подготовка к собеседованию Data Engineer это не список определений и не курс Hadoop 2019 года. Соберите три контура: SQL на больших таблицах, модель с зерном и SCD, один DAG с retry и backfill. К ним добавьте два проектных кейса, которые вы можете рассказать без выдуманных цифр.

Карьерник советует разобрать несколько дизайнов пайплайна, не одну шпаргалку. Повторите идемпотентность, поздние события и разницу озера и склада. Hadoop имеет смысл только если он явно в вакансии. В 2026 базовый набор чаще SQL, склад, Airflow, Spark или Kafka, dbt.

Частые провалы, которые называют в разборах Карьерника, выглядят так. Человек перечисляет тулы и не может собрать загрузку. Нет истории про идемпотентность и retry. Hadoop рассказывают как текущий дефолт. SQL плывёт на окнах и плане. Стрим предлагают до вопроса про SLA.

• Не начинайте ответ с названия движка, пока нет объёма и зерна.
• Не делайте голый INSERT, если таску могут перезапустить.
• Не тащите MapReduce как главную тему 2026 года без запроса вакансии.
• Не молчите про проверки качества и свежесть витрины.

Перед живой встречей ответы стоит проговорить вслух. На HireHi это можно сделать в ИИ-тренажёре пробного собеседования: выберите роль инженера данных, грейд и формат, отвечайте голосом, затем разберите слабые темы.

Шаг 1. Выберите специальность, грейд и формат

В форме укажите разработку или data, роль Data Engineer, свой грейд и тип встречи. Для разговора с тимлидом данных берите технический формат: так вопросы ближе к SQL, DAG и модели, а не только к рассказу о себе.

Категория и роль должны совпасть с вакансией. Если в форме нет отдельной строки «инженер данных», укажите ближайшую data-роль и в ответах держите пайплайн, а не продуктовую аналитику.

Шаг 2. Запустите тренировку и отвечайте

В живом прогоне отвечайте голосом, как на встрече с дата-тимлидом. Для этой роли полезно сначала назвать объём, задержку и зерно, задать уточнение по кейсу и только потом предлагать Spark или Kafka.

Экран вопроса и запись голоса открываются после входа и старта сессии. Без этого дальше формы тренажёр не пускает. Ниже опирайтесь на сам сценарий, а не на кадр диалога.

Шаг 3. Посмотрите результат

После завершения сравните, где ответ был верный по сути, но без структуры. Для инженера данных типичные дыры: нет зерна, нет идемпотентности, сразу стрим, Hadoop как будто сейчас дефолт.

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

Шаг 4. Повторите слабые темы

Не перечитывайте все вопросы подряд. Возьмите две просевшие темы, например SCD2 и retry DAG, и прогоните короткий сценарий ещё раз. Перед реальной встречей этого цикла обычно хватает больше, чем новой шпаргалки по тулам.

Как отвечать на техническом интервью DE

Как отвечать на техническом интервью DE, видно по первым двум минутам кейса. Слабый ход: сразу назвать Kafka, Iceberg и три облака. Сильный ход: уточнить объём, задержку, полную загрузку или инкремент, зерно и кто читает витрину.

Спросите, сколько строк в день и какой SLA свежести. Спросите, нужна ли полная перезаливка или только дельта. Спросите, что хуже: опоздать на час или отдать дубль. От этих ответов архитектура меняется сильнее, чем от любимого движка.

Дальше держите слои. Сырой забор. Идемпотентная запись. Проверки. Витрина для дашборда. Не смешивайте их в одну «просто таблицу в Spark». Если условий мало, назовите допущение вслух и идите от него, а не молча рисуйте максимальный стек.

Инструменты называйте как следствие. Часовой батч в Airflow плюс MERGE. Стрим, если минуты реально меняют решение. ClickHouse, если витрина это широкие агрегаты. Iceberg, если озеро должно быть таблицей, а не папкой файлов.

Какие вопросы задать команде данных

Какие вопросы задать команде данных, лучше собрать под контур, а не взять универсальный список «расскажите про культуру». Ниже вопросы, которые показывают, как устроены пайплайны, а не как устроен офис.

• Какой склад и оркестратор сейчас в проде, и что считается легаси?
• Кто владеет контрактом источника, если схема внезапно плывёт?
• Какой SLA свежести у ключевых витрин и кто дежурит ночью?
• Какая доля батча и стрима, и зачем стрим там, где он есть?
• Как устроены тесты: dbt, проверки в DAG, сверка с источником?
• Можно ли переигрывать закрытый день, если события приехали поздно?

Спросите, как команда считает выручку: в складе или уже в BI. Если ответы расходятся, вы поймёте, куда попадёте в первый месяц. Это полезнее вопроса про любимый язык.