Отклики на позицию Data Engineer

Введение: Data Engineer — не «парень с ETL»

Рынок дата-инженеров перегрет до смешного. На одну senior-позицию прилетает под полторы тысячи откликов, и первые 90% отсева делает не человек, а софт, которому всё равно, сколько у вас лет опыта — если опыт не упакован в понятные ему сигналы. Полторы секунды на резюме, и вердикт готов.

Стек тем временем съехал. Data mesh, lakehouse, real-time streaming — это уже не словечки с конференций, а первая строка в вакансии. Если ваше резюме читается как «SQL, Python, Airflow, чуть-чуть Spark» — вы даже не знаете, сколько собеседований прошло мимо.

Что реально в стеке DE сейчас

Набор 2020 года — Airflow, PySpark, SQL — стал гигиеническим минимумом. Проходите первый фильтр и тут же упираетесь во второй, где копают глубже.

Хранение и табличные форматы

Iceberg выиграл войну форматов. Delta Lake держится внутри Databricks, Hudi — в нише CDC. Но ключевое слово «lakehouse» без конкретики — пустой звук. Пишите, что именно делали.

Реальный сигнал: «Мигрировал 120 ТБ данных с Hive на Iceberg v2, настроил compaction по месяцам (Z-order по user_id + timestamp), p95 аналитических запросов упал с 40с до 4с.»

Оркестрация и трансформации

Airflow везде. Но знать хотя бы один альтернативный оркестратор в 2026 — уже хороший тон. Dagster и Prefect отъедают проекты, где локальная разработка и тестируемость важнее, чем пачка из 5000 DAG-ов в проде.

dbt — стандарт. Если вы senior и не упомянули dbt, ATS скорее всего пойдет искать дальше. Не обязательно быть фанатом — достаточно показать, что вы понимаете разницу между «сырые SQL-скрипты без тестов» и «dbt с автотестами, доками и инкрементальными моделями».

Streaming

Kafka — база. Но просто «работал с Kafka» в 2026 — как «работал с Git». Покажите глубину: масштаб топиков, throughput, как решали exactly-once, что делали с consumer group rebalancing, какие баги ловили в проде.

Flink и RisingWave забирают нагрузку у Spark Structured Streaming в low-latency. Если ваш опыт — только batch, освойте streaming хотя бы на pet-проекте.

Инфраструктура

K8s — дефолт для data workloads. Spark on K8s, Trino on K8s, Kafka on Strimzi. Terraform, Helm, Prometheus + Grafana — теперь это зона дата-инженера, не infra-команды. В средних и маленьких компаниях от DE ждут, что он сам поднимет кластер и настроит алертинг.

Как устроено резюме, которое читает ATS

Заголовок и Summary

Заголовок — первое, на что смотрит ATS. Без выдумок: «Data Engineer» или «Senior Data Engineer». Не «Cloud Data Platform Architect», не «Big Data & ML Solutions Engineer». Точное совпадение — первый рубеж. Не прошли — не читают дальше.

Summary — 500-600 знаков. Не «ответственный, целеустремленный». Сразу покажите: с какими объемами работали, какой стек, какую проблему бизнеса решали.

Рабочий пример:

«Senior Data Engineer, специализация — streaming и real-time аналитика. 8 лет в batch и real-time. С нуля построил data mesh из 5 доменов (Kafka 2.1M msg/sec → Flink → Iceberg → Trino → dbt), 200+ внутренних пользователей. 18 ТБ событий/день, p95 latency доставки — 90 секунд. Сократил стоимость инкрементальной загрузки на $22K/мес.»

Есть всё: масштаб, стек, latency, деньги, архитектурные решения. ATS строит плотный эмбеддинг. Рекрутер за 5 секунд понимает уровень.

Опыт работы: STAR в инженерном исполнении

Каждый пункт — четыре слоя:

• Ситуация: состояние системы до вас, масштаб
• Задача: что требовалось, почему сложно
• Действие: что конкретно вы сделали
• Результат: цифры — latency, стоимость, throughput, reliability

Слабый пункт: «Разрабатывал и поддерживал ETL-пайплайны».

Сильный: «Переписал 30+ ETL-джобов с AWS Glue на Spark Structured Streaming. Задержка доставки данных упала с 6 часов до 7 минут. Стоимость инкрементальной загрузки снизилась на 55% (~$14K/мес). Реализовал exactly-once через идемпотентную запись в Iceberg + checkpointing в Spark.»

Первый вариант мог написать кто угодно. Второй — человек, который решал проблему руками.

Навыки: контекст, а не список

40 технологий через запятую в секции «Навыки» — привет из 2020. Скорер смотрит, использовалась ли технология в блоке опыта, и в каком контексте. «dbt» в навыках, но ни одного упоминания в проектах — вес нулевой.

Лучше: в каждом пункте опыта — технология в контексте задачи. Секцию «Навыки» оставить короткой: 7-10 позиций по слоям (Storage, Processing, Orchestration, Infrastructure).

Сертификации

Сертификации уже не дают вау, но некоторые держатся:

• Confluent Certified Developer for Apache Kafka — сложный практический экзамен, котируется
• Google Professional Data Engineer — широкий спектр, узнаваем
• Databricks Data Engineer Associate — для компаний на Databricks
• dbt Analytics Engineering Certification — нишевый, но в сообществе знают

Сертификат без production-опыта на собеседовании скорее сыграет в минус. Спросят про exactly-once в Kafka Transactions — и всё станет ясно.

Как ATS на самом деле читает DE-резюме

Эмбеддинги вместо правил

Крупные вендоры (Greenhouse, Ashby, Lever) перешли с rule-based скоринга на эмбеддинговые модели. Резюме → вектор, вакансия → вектор, cosine similarity → score. Если вектор размазан (полно общих фраз, мало технических маркеров) — distance растет, скор падает.

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

Граф навыков и контекстное взвешивание

ATS строит граф: «Iceberg» → «Data Lakehouse» → «Table Format» → «Apache Spark». Написав «Iceberg с compaction и Z-order», вы получаете вес по всей цепочке, не перечисляя остальное.

Но «работа с большими данными» без конкретных форматов и движков — граф не строится. Профиль не ассоциируется с Data Engineering. Десять лет опыта уходят в серую зону.

Цифры — hard currency

Для DE цифры критичнее, чем для большинства ролей. Объемы, latency, throughput, количество источников — это разница между «работал в продакшене» и «прошел курс на Coursera».

Рекрутер не поймет «compaction strategy для Iceberg». Но HR-скрининг отсечет резюме без метрик масштаба. Правило простое: после каждого пункта — «цифры есть?» Нет — дописать.

Три разных Data Engineer

Рынок DE фрагментирован. Одна и та же вакансия «Senior Data Engineer» в трех компаниях — три радикально разных роли:

• Platform DE: инфраструктура. Kafka, K8s, Terraform, Spark on K8s, CI/CD, мониторинг. Языки — Python, Go, иногда Java. SQL — мало.
• Analytics DE: 80% времени в SQL и dbt. Модели, витрины, общение с аналитиками. Глубоко знает бизнес-домен.
• Streaming DE: real-time, Kafka/Flink/RisingWave, низкая latency, высокий throughput. Прикладные области — anti-fraud, real-time рекомендации, operational мониторинги.

Одно резюме на все три — бессмысленно. ATS сверяет эмбеддинги, и Platform-резюме на Analytics-вакансию даст низкий cosine similarity. Рекрутер вас просто не увидит.

Стратегия: 2-3 версии резюме под разные треки, и 15 минут на докрутку Summary под вакансию перед откликом. Разница между «просмотрено» и «отклонено».

От резюме к собеседованию

Перегруженное резюме — ловушка. Напихать всё, до чего дотянулись на Coursera, легко. Провалить техническое интервью за 15 минут — еще легче.

Правило: если по технологии не готовы ответить на три уровня — не пишите её.

1. Concept: зачем технология, какую проблему решает?
2. Internals: как устроена. Kafka — partition assignment, log compaction, rebalancing, idempotent producers. Spark — shuffle, partitioning, AQE, broadcast joins.
3. Production: какую реальную проблему с ней решили? С какими багами столкнулись?

Третий уровень провален — технология убирается из резюме senior-уровня. Senior с той стороны стола разберет вас быстрее, чем длится consumer group rebalancing.

Deep-dive FAQ: Резюме Data Engineer

1. «SQL» в навыках — хватит или надо перечислять СУБД?
   Перечисляйте. PostgreSQL, ClickHouse, BigQuery, Snowflake, Trino. «SQL» — это как написать «языки программирования» вместо Python.

2. Как писать про облака, чтобы ATS засчитал?
   Сервисы, а не провайдеры. Не «AWS», а «AWS EMR, S3, Glue Data Catalog, Athena, MSK». И метрики: стоимость, объемы, latency.

3. Python — как правильно?
   Контекст: «Python: кастомные Airflow-операторы, интеграционные тесты пайплайнов, CLI для data quality-чеков». Без контекста — пустая строка.

4. Soft Skills для DE — нужны?
   На senior-уровне да. В формате STAR: «Мигрировал 25 команд с Airflow 1.x на 2.x — организовал воркшопы, написал доку и шаблоны DAG-ов». И техника, и умение двигать людей.

5. Open Source — плюс или минус?
   Реальные PR в крупные проекты — сильный плюс. Пустой GitHub с одним форком — лучше не упоминать.

6. Название компании влияет на Match Rate?
   Некоторые ATS интегрированы с Crunchbase/СПАРК. FAANG, Яндекс, Тинькофф, известный стартап — система понимает масштаб и дает дополнительный вес.

7. Что делать, если фон — legacy (Oracle, Informatica, SSIS)?
   Не прячьте. Покажите вектор: «Поддерживал 200+ джобов на Informatica → инициировал миграцию на Airflow + dbt, ускорил разработку новых пайплайнов на 70%». Траектория ценнее статики.

8. Построить платформу с нуля — насколько это ценно?
   Очень. Один пункт про «выбрал стек, настроил CI/CD, мониторинг, алертинг, платформа обрабатывает 3 ТБ/день» стоит пяти пунктов «участвовал в поддержке».

9. Частая смена работы — как к этому относится ATS?
   Если каждый переход — рост (выше грейд, сложнее стек), ATS не штрафует. Но объяснять логику на HR-скрининге всё равно придется.

10. Сертификация или pet-проект — что весомее?
    Pet-проект с кодом, архитектурной схемой и метриками. Сертификат — «я сдал тест». Pet-проект — «я могу построить систему». Разница очевидна.

11. Мониторинг и алертинг — обязательно в резюме?
    Да. Инженер, умеющий мониторить пайплайны (Prometheus, Grafana, PagerDuty), стоит в 1.5-2 раза дороже. Пункт: «Настроил p95 latency-мониторинг, алертинг в Slack при падении качества данных ниже SLA.»

12. Data mesh — buzzword или реальное требование?
    Если писали data contracts, настраивали федеративный каталог и децентрализованное владение — укажите. Если только прочитали статью Дегани — лучше не надо. Спросят на собеседовании.

Заключение

Резюме Data Engineer в 2026 — техническая спецификация, а не биография. ATS видит набор эмбеддингов и контекстных связок. Чем точнее позиционирование (Platform, Analytics или Streaming), чем больше цифр в каждом пункте — тем выше шанс не застрять в серой зоне.

И резюме не должно врать. Фильтр, может, и обманете, но senior-инженер на собеседовании разберет вас быстрее, чем срабатывает Kafka consumer rebalancing.