4 апреля 2026 г.

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

Чем дата-инженер отличается от аналитика данных

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

На практике дата-инженер занимается тремя вещами:

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

Проектирование хранилищ данных. Data warehouse, data lake, lakehouse — дата-инженер выбирает архитектуру, проектирует схемы, оптимизирует хранение. Он решает, как партиционировать таблицы, какие форматы файлов использовать (Parquet, ORC, Avro), как обеспечить быстрый доступ к данным для аналитиков.

Обеспечение надёжности и масштабируемости. Пайплайн, который падает каждый день — бесполезен. Дата-инженер настраивает мониторинг, алерты, retry-логику, idempotent-обработку. Он думает о том, что произойдёт, когда данных станет в 10 раз больше.

Подробнее о разнице между ролями — в статье Типы аналитиков: отличия.

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

Типичный процесс для дата-инженера — 3–5 этапов:

1. HR-скрининг. Мотивация, ожидания, общее понимание роли. Могут спросить: «Чем DE отличается от DA?», «С какими хранилищами работали?», «Какой стек у вашего текущего проекта?»

2. SQL-интервью. Отдельный этап, 45–60 минут. У дата-инженера проверяют не только аналитические запросы, но и знание DDL, оптимизации, работы с большими таблицами. Подробнее — ниже.

3. Python/код. Написать ETL-скрипт, разобрать задачу на обработку данных, работа с файлами и API. Могут попросить написать код на доске или в онлайн-редакторе.

4. System design. Спроектировать пайплайн данных для конкретной задачи: выбрать источники, трансформации, хранилище, оркестрацию, мониторинг.

5. Финальное интервью. Разговор с руководителем или командой о предыдущем опыте и культурном соответствии.

SQL: что спрашивают у дата-инженера

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

DDL и проектирование схем

На собеседовании могут попросить создать таблицу с нуля, объяснить выбор типов данных и ограничений:

CREATE TABLE events (
    event_id    BIGINT GENERATED ALWAYS AS IDENTITY,
    user_id     BIGINT NOT NULL,
    event_type  VARCHAR(50) NOT NULL,
    payload     JSONB,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
    CONSTRAINT pk_events PRIMARY KEY (event_id)
);

CREATE INDEX idx_events_user ON events (user_id);
CREATE INDEX idx_events_created ON events (created_at);

Частые вопросы: «Зачем TIMESTAMPTZ, а не TIMESTAMP?», «Когда использовать JSONB, а когда отдельные колонки?», «Как выбрать между BIGINT и UUID для первичного ключа?»

Партиционирование

Дата-инженер работает с таблицами на миллиарды строк. Без партиционирования запросы к таким таблицам будут выполняться часами.

CREATE TABLE events_partitioned (
    event_id    BIGINT,
    user_id     BIGINT NOT NULL,
    event_type  VARCHAR(50) NOT NULL,
    created_at  TIMESTAMPTZ NOT NULL
) PARTITION BY RANGE (created_at);

CREATE TABLE events_2026_01 PARTITION OF events_partitioned
    FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');

На собеседовании спрашивают: «По какому полю партиционировать?», «Чем RANGE-партиционирование отличается от LIST и HASH?», «Как это влияет на план запроса?» Правильный ответ зависит от паттернов доступа к данным — универсального решения нет.

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

Дата-инженер должен уметь читать EXPLAIN ANALYZE и понимать, почему запрос медленный:

  • Seq Scan vs Index Scan — когда планировщик выбирает полное сканирование и как этого избежать.
  • Join-стратегии — Nested Loop, Hash Join, Merge Join. Когда какая эффективнее.
  • Статистика и VACUUM — почему планировщик может выбрать неоптимальный план.

Типичная задача: «Запрос к таблице на 500 млн строк выполняется 40 минут. Что вы проверите?» Ожидаемый ход: проверить план выполнения, посмотреть наличие индексов, оценить селективность условий WHERE, проверить партиционирование, посмотреть статистику таблицы.

Базовые SQL-навыки (JOIN, GROUP BY, оконные функции) тоже проверяют — подготовиться можно в разделе SQL и подборке задач.

Python: ETL, Airflow, Spark

Обработка данных

На собеседовании дата-инженера Python — не про pandas и визуализацию. Это про надёжную обработку больших объёмов данных. Типичные задачи:

  • Прочитать CSV/JSON-файл, трансформировать данные, загрузить в базу.
  • Обработать данные потоково (без загрузки всего файла в память).
  • Работа с API: пагинация, retry, rate limiting.

Пример задачи: «Напишите функцию, которая читает CSV-файл по чанкам и загружает данные в PostgreSQL, пропуская строки с невалидным email».

Apache Airflow

Airflow — стандарт оркестрации пайплайнов данных. На собеседовании проверяют:

  • DAG, Task, Operator — базовые концепции. DAG — направленный ациклический граф задач. Task — отдельный шаг. Operator — тип задачи (PythonOperator, BashOperator, SqlOperator).
  • Расписание и триггеры. Как настроить запуск по cron, по событию, по завершению другого DAG.
  • Обработка ошибок. Retry, таймауты, алерты. Что произойдёт, если задача упала посреди выполнения?
  • Идемпотентность. Если DAG запустить повторно за ту же дату — данные не должны задвоиться.

Частый вопрос: «Чем отличается backfill от обычного запуска?» Backfill — это запуск DAG за прошлые периоды, когда данные уже существуют, но пайплайн не был запущен.

Apache Spark (базовый уровень)

Не на всех собеседованиях спрашивают Spark, но для позиций middle+ это ожидаемый навык:

  • RDD vs DataFrame vs Dataset — эволюция API. На практике все работают с DataFrame.
  • Lazy evaluation — трансформации не выполняются, пока не вызвано действие (action).
  • Партиционирование данных — как Spark распределяет данные по узлам кластера.
  • Shuffle — самая дорогая операция. Когда происходит (JOIN, GROUP BY, repartition) и как минимизировать.

System design: проектирование пайплайнов

На кейс-интервью дата-инженеру дают задачу уровня: «Спроектируйте систему сбора и аналитики кликстрима для e-commerce с 10 млн пользователей в день».

Ожидаемая структура ответа:

  1. Источники данных. Веб-трекер, мобильный SDK, серверные логи. Формат событий, объём данных, частота.
  2. Ingestion. Kafka для потоковой загрузки. Почему Kafka, а не RabbitMQ? Kafka хранит данные, позволяет перечитывать, масштабируется горизонтально.
  3. Обработка. Spark Streaming или Flink для realtime-обработки. Batch-пайплайн на Airflow + Spark для ежедневных агрегаций.
  4. Хранилище. Raw-данные в S3 (data lake) в формате Parquet. Агрегированные данные — в ClickHouse или BigQuery для быстрых аналитических запросов.
  5. Качество данных. Валидация схемы на входе, проверки полноты после загрузки, мониторинг аномалий.
  6. Мониторинг. Алерты при задержке пайплайна, при росте ошибок, при отклонении объёма данных от нормы.

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

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

SQL — приоритет номер один. Но готовьтесь не только к аналитическим запросам. Разберитесь в DDL, индексах, партиционировании, планах выполнения. Потренируйте написание запросов в SQL-тренажёре.

Python — не алгоритмы, а инженерные задачи. Потренируйтесь писать ETL-скрипты: чтение файлов, обработка ошибок, загрузка в базу. Если претендуете на middle+ — разберитесь с Airflow DAG на уровне написания с нуля.

System design — рисуйте пайплайны. Возьмите 3–4 реальных сценария (аналитика e-commerce, рекомендательная система, CRM-аналитика) и спроектируйте архитектуру данных от источника до дашборда. Продумайте, что сломается при росте нагрузки.

Разберитесь в форматах данных. Parquet vs CSV vs JSON vs Avro — когда что использовать, как это влияет на скорость чтения и размер хранения.

Если вы переходите из аналитики — у вас уже есть база в SQL и понимание данных. Осталось добрать инженерную часть: инфраструктуру, оркестрацию, оптимизацию. Подробнее о пути в аналитику — в статье Как стать аналитиком данных.

Читайте также

FAQ

Нужен ли дата-инженеру опыт в аналитике?

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

Какой язык программирования учить — Python или Scala?

Python — стандарт индустрии для дата-инженерии. 90% вакансий требуют Python. Scala используется в командах, которые много работают со Spark, но даже там PySpark покрывает большинство задач. Начинайте с Python, Scala добавите позже, если понадобится.

Сколько времени нужно на подготовку?

Если у вас есть опыт в аналитике или разработке — 3–4 недели. Ключевые темы: SQL (DDL + оптимизация), Python (ETL-скрипты), Airflow (базовые концепции), основы system design. Если входите в область с нуля — 2–3 месяца с упором на SQL и Python.

Чем Data Engineer отличается от Backend-разработчика?

Backend-разработчик строит приложения, которые обслуживают пользователей в реальном времени: API, бизнес-логика, транзакции. Дата-инженер строит системы обработки данных: пайплайны, хранилища, трансформации. Backend думает о latency и user experience, DE — об объёмах данных, пропускной способности и консистентности. Технологии пересекаются (Python, SQL, Kafka), но задачи и метрики успеха — разные.

Потренируйтесь решать задачи для аналитиков — откройте тренажёр с SQL, Python и продуктовыми вопросами.

Тренироваться в Telegram