Резюме Data Engineer

Резюме Data Engineer часто выглядит как каталог инструментов: Airflow, Spark, Kafka, dbt, Snowflake, «опыт с облаками». Рекрутер это уже видел сто раз. Ему нужно другое: какие данные вы возили, для кого они нужны, как часто обновлялись и что вы делали, когда пайплайн врал.

Ниже — как собрать файл инженера данных под CIS IT 2026: заголовок, summary, формулировки пайплайнов, инциденты качества, стек без кладбища аббревиатур и два полных примера. Общая структура CV — в как составить резюме. Карта навыков роли — в навыках аналитика рядом, но DE — это поставка и качество, не дашборд.

Коротко:

• Пишите пайплайн как продукт: источник, преобразование, потребитель, SLA свежести.
• Один инцидент качества сильнее десяти названий фреймворков.
• Стек группируйте. Не дублируйте его в каждой пуле опыта.
• Переход из аналитики или backend продаётся задачей про данные, а не сменой титула.
• Перед отправкой прогоните файл через разбор резюме и сверьте формулировки с живыми вакансиями Data Engineer.

Что решают за 20 секунд

На отклик DE смотрят так: это инженер данных или аналитик с SQL? Есть ли прод, а не только учебный ноутбук? Понятно ли, какие объёмы и какие потребители? Не рассылка ли это на «всё про данные»?

Заголовок «Data Engineer / Analyst / ML» почти всегда проигрывает узкому. Если вы закрываете ETL и витрины — так и напишите. Если вы аналитик, который один раз поднял Airflow, не переименовывайте себя. Роль в рынке и вход — в как стать Data Engineer.

Первый экран должен дать роль, один домен (реклама, биллинг, логи, финансы) и один факт поставки. Остальное человек дочитает, если этот факт стыкуется с вакансией.

В удалённых командах CIS в 2026-м к этому добавляется формат: письменный статус «витрина опаздывает», пересечение часов с потребителем отчёта, язык алертов. Это не «софт-скилл». Это условие, при котором ваш пайплайн вообще имеют смысл дежурить. Если вы это не называете, рекрутер дорисует офис и девять утра по Москве — и отсеет зря или наоборот позовёт не туда.

Заголовок, summary и ссылки

Заголовок: роль + уровень + узкая специализация, если она есть. «Data Engineer, витрины и batch ETL» сильнее «специалист по данным». Не пишите пять синонимов через слэш.

Summary — четыре строки: кто вы, какой контур, какой результат, какой формат работы. Формула и чужие ошибки — в как написать summary. Для DE в summary должны появиться свежесть, объём или потребитель, а не «ответственный и люблю данные».

Ссылки: GitHub с одним пайплайном, который можно прочитать, а не монорепозиторий курсов. Если код закрыт NDA — опишите схему словами: источники, оркестрация, склад, витрина, кто читает. Ссылка на пустой профиль хуже, чем честный «код внутренний».

Как описывать пайплайны

Пункт опыта — не список технологий. Это маршрут данных. Формула:

1. Откуда данные (API, CDC, файлы, очередь, чужая БД).
2. Что вы с ними делали (очистка, склейка, SCD, агрегаты, проверки).
3. Куда они попадали и кто ими пользовался.
4. Какой был контракт: раз в час, к 09:00, не хуже вчерашнего, алерт при дыре.
5. Что сломалось и как вы это закрыли — если было.

Плохо: «Разрабатывал пайплайны на Airflow и Spark». Хорошо: «Собрал ежедневную витрину заказов из Postgres и событий очереди; витрина нужна финансам к 8:00; добавил проверку суммы чеков, инцидент «пустой день» ловим до открытия отчётов».

Объёмы пишите только если помните порядок: гигабайты в день, миллионы строк, число таблиц. Выдуманные «петабайты» вскрываются первым вопросом. Если цифр нет, оставьте потребителя и SLA — это тоже масштаб.

Три частые пустые формулы и чем их заменить:

• «Строил DWH» → какие слои, какие витрины, кто читает по утрам.
• «Настраивал Airflow» → сколько DAG, какой SLA, что делали при падении сенсора.
• «Обеспечивал качество» → какая проверка, какой инцидент, какой алерт.

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

Как сжимать любой опыт в пули — в как описать опыт в резюме. Проекты без работодателя — по той же формуле в как описывать проекты.

Качество данных важнее оркестратора

Команды в 2026-м нанимают DE не за умение кликать DAG. Они нанимают человека, который замечает, что вчерашний отчёт врёт. В резюме это выглядит так:

• проверки на свежесть, полноту, уникальность ключа, допустимый дрейф;
• алерт, который разбудил не вас, а дежурного;
• инцидент: симптом, причина, фикс, что сделали, чтобы не повторилось;
• контракт с аналитиком или продуктом: что считается «готово».

Один разобранный инцидент качества закрывает сомнение «это просто перекладыватель таблиц». Без него стек звучит как курс. Не приукрашивайте: «нашли дубли в справочнике клиентов, отчёт по LTV врал две недели» — нормальная сильная пуля.

Пример 1. Переход из аналитики

Кандидат: 2 года Data Analyst, SQL и витрины, сам завёл оркестрацию пары отчётов. Цель — junior/middle DE, batch, не стриминг.

Data Engineer (переход из аналитики). Batch ETL, витрины для продукта и финансов, SQL / Python / dbt. Удалённо, CIS.

Последние полтора года собирал витрины, которые раньше считались руками в Excel. Источники: Postgres продукта и выгрузки маркетинга. Собрал 6 моделей в dbt, расписание раз в сутки к 7:30. Добавил тест на уникальность order_id и на пустой день: один раз поймали обрыв интеграции до утреннего стендапа.

Spark в проде не использовал — в вакансиях со стримингом это честно указано. Готов разобрать модели и тесты на созвоне. GitHub: один учебный DAG с проверками, не «интернет-магазин».

Почему это работает: роль названа как переход, не маскировка. Есть потребитель, SLA, проверка качества. Нет притворства про Kafka. Стек узкий и стыкуется с junior DE без стриминга.

Пример 2. Middle с прод-контуром

Вакансия: Data Engineer, витрины + инциденты, облако по факту, не «архитектор платформы».

Data Engineer, 4 года. Склад и витрины биллинга, оркестрация, дежурства по свежести.

Вёл контур ежечасных агрегатов платежей: CDC из Postgres, преобразование, витрина для антифрода и финансов. Держали свежесть < 70 минут; на обрыве источника алерт в чат дежурного. Два инцидента за год: сдвиг таймзоны в окне и дубли после ретрая — оба закрыты проверкой ключа и идемпотентной записью.

Стек: Python, SQL, Airflow, Postgres, объектное хранилище. Spark — точечно на исторический пересчёт, не как основной движок. Kubernetes администрировал не я: описываю как пользователь джобов.

Честная граница «Spark точечно» и «K8s не я» снимает риск собеседования, где вас разберут как platform lead. Рекрутеру проще позвать человека, который не врёт про ширину.

Перед/после одной пули, если кажется, что «писать нечего»:

Было: «Участвовал в разработке пайплайнов обработки данных (Python, SQL, Airflow)».

Стало: «Собрал ежедневный пересчёт витрины подписок из биллинга и событий продукта; проверка суммы MRR против исходной таблицы; один раз поймали обрыв CDC до открытия дашборда у финансов».

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

Стек: три места, не одно кладбище

Шапка — 5–8 технологий, без которых вы не тот кандидат. Опыт — стек внутри задачи, один раз. Блок skills — группы: языки, оркестрация, склады, качество, облако. Как раскладывать — в как указать стек в резюме.

Не пишите «ETL, ELT, ELT/ETL, data pipelines» рядом. Выберите слова вакансии, которыми вы реально пользовались. ATS ищет совпадения, человек ищет смысл. Двадцать синонимов не усиливают файл — они маскируют, что вы возили.

Облако: конкретный сервис, который трогали (S3-совместимое хранилище, управляемый Postgres, очередь), а не логотип вендора. Если работали on-prem — так и напишите. Для удалённых команд CIS это норма, не минус. Формат удалённого CV — в резюме для удалённой работы.

Чего не должно быть

• «Большие данные» без порядка величины и без потребителя.
• Список из пятнадцати инструментов курса, которыми не готовы дебажить.
• ML-модели «для солидности», если вы их не катали в прод как DE.
• Должностная инструкция: «обеспечивал целостность хранилища».
• Проценты ускорения, которых не измеряли.
• Заголовок сразу на Senior Platform, если в опыте один DAG.

Типичные форматные провалы те же, что у всех IT-ролей: фото, колонки, PDF с текстом картинкой. Их список — в ошибках в резюме. Для ATS полезен соседний разбор как пройти ATS.

Как стыковать файл с вакансией

Откройте 5 объявлений одной линии: batch-витрины, стриминг, аналитическая инженерия. Не мешайте их в одном CV. Переставьте верхние пули под задачу вакансии: если ищут качество и SLA — инцидент наверх; если оркестрацию — DAG и расписание; если склад — модель данных и SCD.

Письмо не пересказывает резюме. Оно указывает на один пайплайн. Каркас — в что написать в сопроводительном письме. Если коммерческого DE-стажа нет, сначала соберите учебный контур со проверками, затем пишите — как в резюме без опыта.

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

Чек-лист DE-файла и скрининг

Перед отправкой пройдитесь по файлу так, как пройдётся человек на скрининге. Он не читает dbt-манифест. Он задаёт четыре вопроса вслух и ищет ответы в тексте.

1. Какие данные? Если ответа нет в первой пуле — допишите источник и сущность: заказы, платежи, клики, тикеты.
2. Кто потребитель? Финансы, антифрод, продукт, внешний отчёт. «Для бизнеса» — не потребитель.
3. Какой контракт свежести или качества? Час, утро рабочего дня, проверка пустого дня. Без контракта вы «просто грузили таблицы».
4. Что будет, если спросят про сбой? Должен быть один инцидент или честное «сбоев на моём контуре не ловил, вот учебная проверка».

На самом созвоне вас почти наверняка попросят нарисовать поток. Имеет смысл заранее набросать его на бумаге теми же словами, что в резюме: источник → преобразование → склад/витрина → потребитель → проверка. Если в файле Spark, а на схеме только SQL-модели — сразу признайте, где Spark был точечно. Расхождение схемы и CV ломает доверие быстрее, чем узкий стек.

Если откликаетесь на стриминг, а опыт batch — не маскируйте. Одна строка в summary: «batch-витрины, стриминг не в проде». Часть вакансий отпадёт. Это дешевле, чем час разбора Kafka, которой не было. Обратный случай: стриминг был, а в файле только Airflow — вы сами себя занижаете.

Учебный контур для входа: один DAG или один набор моделей, две-три проверки качества, README с тем, как прогнать и что сломаете специально, чтобы проверка сработала. Это сильнее сертификата облака без пайплайна. Как упаковать ссылку — в описании проектов.

Частые вопросы

Что сделать сейчас

Выпишите три пайплайна: источник, преобразование, потребитель, свежесть. Из них соберите 4–6 пуль последней роли и четырёхстрочный summary. Уберите из skills всё, чем не готовы дебажить на созвоне.

Сверьте файл с тремя живыми объявлениями в вакансиях Data Engineer, затем прогоните через разбор резюме. Если после диагонали всё ещё неясно, какие данные вы возили — правьте опыт, а не длину списка Airflow.