Собеседование на Data Engineer

Что спрашивают на собесе Data Engineer

Data Engineer — это инженерная профессия с дата-фокусом, и собеседование это сразу выдаёт. Если у аналитика главный вопрос «какой запрос даст правильную цифру», то у дата-инженера — «как сделать так, чтобы данные стабильно доезжали из источника в хранилище, не ломались на масштабе и не начинали врать после очередного сбоя». Поэтому секций больше, чем на собесе аналитика, и почти каждая уходит в архитектуру.

SQL спрашивают на продвинутом уровне. Базовые JOIN и GROUP BY считаются данностью, а проверяют оптимизацию: чтение плана выполнения, индексы, материализованные представления, оконные функции в тяжёлых отчётах. Важно не просто получить результат, а объяснить, почему запрос на миллиард строк выполняется минуту, а не час, и что с этим делать.

Моделирование данных — отдельный большой блок. Звезда и снежинка, нормализация против денормализации, факты и измерения, медленно меняющиеся измерения (SCD). Здесь проверяют, понимаете ли вы, зачем в аналитическом хранилище осознанно дублируют данные, и когда это оправдано, а когда превращается в неуправляемый бардак.

Про DWH спрашивают, чем аналитическое хранилище отличается от операционной базы: OLAP против OLTP, колоночное хранение против строкового, почему ClickHouse, Snowflake или BigQuery быстры на агрегатах и медленны на точечных обновлениях. Рядом всегда идут ETL и ELT — как именно данные перекладываются из источников, где происходит трансформация и почему современные хранилища всё чаще делают её уже внутри себя.

Оркестрация — это про то, как пайплайны запускаются по расписанию и переживают сбои. Чаще всего речь про Airflow: DAG, зависимости задач, сенсоры, backfill, retry-логика, идемпотентность. Потоковая обработка — отдельная тема: Kafka как шина событий, разница между обработкой пакетами и потоком, гарантии доставки, как считать метрики на лету с задержкой в секунды.

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

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

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

Скрининг с рекрутером (20–30 минут) — формальность, но не пустая. Здесь сверяют опыт, реальный стек и ожидания по деньгам. Полезно заранее уметь за минуту рассказать, какие пайплайны вы строили, какой объём данных через них проходил и где была ваша зона ответственности.

SQL и кодинг (60 минут) — техническая секция, где дают схему и просят писать запросы вслух. У дата-инженера упор смещён на оптимизацию и корректность на масштабе: оконные функции, дедупликация, работа с дубликатами и поздними данными, объяснение плана выполнения. Часто добавляют задачу на Python — разобрать файл, написать трансформацию, накидать каркас DAG.

Моделирование и DWH (45–60 минут) — кейс вроде «спроектируй хранилище для маркетплейса». Ждут, что вы разложите источники на факты и измерения, выберете звезду или снежинку и обоснуете выбор, проговорите, как обрабатывать историю изменений через SCD.

Системный дизайн дата-пайплайна (60 минут) — ключевая секция уровня middle и выше. «Спроектируй приём 10 ТБ в день», «как обработать поток с задержкой в минуту», «что делать, когда источник прислал данные задним числом». Здесь оценивают не знание конкретного инструмента, а умение рассуждать про trade-off: пакеты против потока, идемпотентность, повторная обработка, мониторинг качества данных.

Поведенческая секция (45 минут) — вопросы в формате STAR про конфликты, инциденты на проде, упавшие ночью пайплайны. Дата-инженер часто оказывается между аналитиками, продуктом и платформенной командой, поэтому проверяют, умеете ли вы договариваться и брать ответственность за сломанные данные.

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

Большинство кандидатов проваливаются не на незнании модного инструмента, а на инженерных основах. Самая частая ловушка — рассказывать про технологии списком («работал с Airflow, Kafka, Spark»), но не уметь объяснить, почему выбрали именно их и какие были альтернативы. Интервьюер сразу слышит, кто строил систему, а кто прикладывал готовые кубики.

Вторая ловушка — игнорировать отказоустойчивость. Кандидат проектирует красивый пайплайн, но не отвечает на вопрос «что будет, когда задача упадёт на середине и запустится повторно». Если в ответе нет идемпотентности, повторной обработки и гарантий доставки, дизайн считается наивным.

Третья — путать обработку пакетами и потоком и тащить streaming туда, где хватило бы ночного пакета. Усложнение ради впечатления работает против кандидата: сильный инженер выбирает самое простое решение, которое закрывает требования по задержке.

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

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

Сначала попробуйте ответить сами, потом сверьтесь с разбором.

1. Чем ETL отличается от ELT? В ETL данные сначала трансформируют на отдельном движке и только потом грузят в хранилище. В ELT их сырыми загружают в хранилище и трансформируют уже внутри него средствами самого DWH. ELT стал стандартом, потому что облачные хранилища дёшевы и быстры на трансформациях, а держать сырые данные под рукой полезно для пересчётов.

2. Чем OLAP отличается от OLTP? OLTP — операционные системы: короткие транзакции, частые INSERT и UPDATE, узкие запросы по ключу, нормализованные таблицы (например PostgreSQL для биллинга). OLAP — аналитические: большие сканы, агрегаты, преобладает чтение, таблицы денормализованы (ClickHouse, Snowflake, BigQuery). Разные нагрузки требуют разной физики хранения.

3. Нормализация или денормализация в хранилище? В операционной базе нормализуют, чтобы убрать дублирование и аномалии при обновлении. В аналитическом хранилище наоборот часто денормализуют: данные дублируют сознательно, чтобы убрать JOIN-ы и ускорить чтение, потому что аналитические таблицы редко обновляются построчно. Выбор — это размен между скоростью запросов и стоимостью хранения и поддержки.

4. Star schema против Snowflake — когда что? Звезда — это одна таблица фактов и плоские независимые измерения, меньше JOIN и быстрее запросы. Снежинка нормализует измерения на подсправочники: экономит место, но усложняет запросы. По умолчанию берут звезду и уходят в снежинку только там, где дублирование в измерениях становится реальной проблемой.

5. Что такое идемпотентность пайплайна и зачем она? Идемпотентность — это когда повторный запуск даёт ровно тот же результат, без дублей. Для дата-инженера это критично: задачи падают, retry и backfill — норма жизни. Добиваются через запись по уникальному ключу (UPSERT или MERGE вместо слепого INSERT) и через перезапись целевой партиции перед загрузкой, а не дозапись поверх.

6. Что такое медленно меняющиеся измерения (SCD)? Это способ хранить историю изменений в таблицах измерений. SCD type 1 просто перезаписывает значение и теряет историю. SCD type 2 заводит новую версию строки с датами действия и флагом актуальности, поэтому можно посчитать метрику «на тот момент». Type 2 — самый частый ответ на вопрос «как сохранить, что у клиента поменялся город».

7. Зачем партиционировать таблицы? Партиционирование физически разбивает таблицу по колонке (чаще по дате), и движок при запросе читает только нужные куски, а не всю таблицу. Это ускоряет фильтрацию и удешевляет загрузку: новую партицию можно перезаписать целиком, не трогая историю. Без партиционирования большие таблицы превращаются в полный скан на каждый запрос.

8. Batch или streaming? Пакетная обработка копит данные и считает их по расписанию — проще, дешевле, легче чинить, подходит для отчётов, где задержка в часы допустима. Потоковая обработка считает события по мере поступления с задержкой в секунды — нужна для антифрода, рекомендаций и мониторинга. Streaming дороже в поддержке, поэтому его берут только там, где задержка реально критична.

9. Зачем Parquet и колоночные форматы? Parquet хранит данные по колонкам, а не по строкам, поэтому аналитический запрос читает только нужные колонки и сильно экономит на вводе-выводе. Колоночное хранение к тому же лучше сжимается, ведь в одной колонке значения однотипные. Для аналитики это в разы быстрее и дешевле, чем строковый CSV.

10. Как обработать данные, пришедшие задним числом (late-arriving)? Несколько подходов: перезапустить нужные партиции через backfill; считать по времени события, а не по времени обработки; использовать SCD для исторической точности; буферизовать данные перед загрузкой. У каждого свой размен между сложностью и точностью, и сильный ответ — это назвать пару вариантов и их цену.

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

SQL для DE

• SQL на собеседовании
• Оконные функции — шпаргалка
• LAG, LEAD в SQL
• CTE и подзапросы
• JSONB в PostgreSQL
• Materialized views в SQL

Хранилища и DWH

• ClickHouse vs PostgreSQL для аналитика
• Data Warehouse vs Database
• Star vs Snowflake schema для DE
• Slowly Changing Dimensions (SCD) для DE
• Data Vault 2.0 на собесе DE
• Lakehouse, Iceberg, Delta на собесе DE

Оркестрация

• Airflow для аналитика
• Airflow на собесе DE
• Airflow backfill на собесе DE
• Airflow sensors на собесе DE
• Airflow XCom на собесе DE
• Airflow vs Dagster
• Airflow vs Prefect на собесе DE

Streaming и Big Data

• Kafka на собесе DE
• Apache Spark на собесе DE
• Spark Structured Streaming на собесе DE
• Apache Flink на собесе DE
• Batch vs Stream processing

ETL / ELT и интеграции

• Airbyte vs Fivetran на собесе DE
• CDC и Debezium на собесе DE
• Идемпотентность пайплайна для DE
• CDC vs batch loading на собесе DE

Data quality и observability

• Data quality dimensions на собесе DE
• Great Expectations на собесе DE
• Data lineage на собесе DE

Гайды по компаниям

• Собес DE в Яндексе
• Собес DE в Т-Банке
• Собес DE в Ozon
• Собес DE в Авито

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

Готовиться к собесу дата-инженера лучше слоями, от фундамента к инструментам.

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

Дальше — моделирование данных. Разберите звезду и снежинку, факты и измерения, типы SCD по книге Кимбалла «The Data Warehouse Toolkit». Это та теория, которую спрашивают почти на каждом собесе и которую легко проговорить на кейсе, если она уложена в голове.

Параллельно поднимите pet-проект с настоящей оркестрацией: Airflow с расписанием, сенсорами, retry-логикой и идемпотентными задачами. Один работающий DAG на собственном проекте даёт больше, чем десяток статей, потому что вы своими руками ловите падения и backfill.

Затем добавьте потоковую обработку и движок больших данных: Kafka как шину событий и Spark для распределённых вычислений. Прорешайте пять и больше кейсов системного дизайна «спроектируй пайплайн» — именно эта секция отделяет middle от senior. И обязательно разбирайте каждую свою ошибку: понятая один раз ловушка превращается в выученный паттерн, а не в повторяющийся промах.

Частые ошибки на собеседовании

Главная ошибка — проектировать пайплайн, не уточнив требования. Прежде чем рисовать архитектуру, спросите про объём данных, допустимую задержку, частоту обновления и кто потребитель. Кандидат, который сразу тащит Kafka и Spark на задачу, где хватило бы ночного пакета и одной таблицы, выглядит слабее того, кто выбрал решение под требования.

Вторая ошибка — молчать и сразу писать код в SQL-секции. Проговаривайте схему, джойны и поведение дубликатов и NULL вслух: ход мысли оценивают не меньше, чем итоговый запрос. Третья — забывать про отказоустойчивость и качество данных. Если в дизайне нет ответа на «что будет при повторном запуске» и «как мы заметим, что данные сломались», его считают сырым. Сильный кандидат сам проговаривает идемпотентность, мониторинг и поздние данные, не дожидаясь наводящих вопросов.

Другие темы

• Подготовка к собеседованию аналитика
• SQL на собеседовании
• Python на собеседовании
• A/B-тестирование

FAQ

Чем DE отличается от DA и DS?

DE строит инфраструктуру: пайплайны, DWH, потоковую обработку в реальном времени. DA анализирует данные и считает метрики, DS строит модели. Дата-инженер — больше про инженерию и надёжность данных, меньше про статистику.

Нужны ли SQL и Python оба?

Да. SQL — обязательный навык на любом грейде, и на senior его спрашивают глубоко, с оптимизацией. Python нужен почти везде: DAG-и Airflow пишутся на Python, плюс обработка данных и служебные скрипты.

Сколько готовиться к DE-собесу?

Junior — около 3–6 месяцев после того, как набрали базу по SQL и одному оркестратору. Middle и senior с опытом — 1–3 месяца сфокусированной подготовки, упор на системный дизайн пайплайнов и моделирование.

Что важнее на собесе DE — инструменты или фундамент?

Фундамент. Конкретный стек (Airflow против Dagster, Kafka против очередей) учится быстро, а понимание моделирования, идемпотентности и trade-off пакеты-против-потока — то, что отличает сильного инженера. Инструменты называют как иллюстрацию решений, а не как самоцель.

Что такое системный дизайн дата-пайплайна?

Это секция, где дают задачу вроде «спроектируй приём 10 ТБ в день» и смотрят, как вы рассуждаете: какие источники, batch или streaming, как обеспечить идемпотентность и повторную обработку, где хранить, как ловить сбои и поздние данные. Оценивают логику и trade-off, а не идеальный ответ.

Нужен ли Hadoop?

В современных компаниях — почти нет. Hadoop в основном legacy, чаще встречается Spark поверх облачного хранилища (S3, GCS, ABFS). Hive metastore местами остаётся, но MapReduce руками писать уже не просят.