Узнайте, почему в вакансиях дата-инженеров требуют 15+ технологий, а на деле нужны SQL и Python. Как пройти отбор, не соответствуя списку?
Недавно я встретился с двумя коллегами уровня staff-инженера. У нас за плечами 40+ лет в дата-инженерии, опыт в FAANG и десятки собеседований. Мы открыли одну вакансию из Series C компании с нормальной продуктовой командой. Ничего экзотического. И ни один из нас не соответствовал всем требованиям.
В описании были: SQL, Python, Airflow, Snowflake, Kafka, Flink, dbt, Terraform, Kubernetes и «опыт интеграции LLM». Пятнадцать технологий из четырёх разных дисциплин. Зарплата — $140K–$170K. Столько же платили в 2022 году, когда требовались только SQL, Python, Airflow и хранилище.
Три staff-инженера с суммарным опытом 40+ лет — ноль из трёх подходят по бумажке. Если это не говорит о сломанном процессе найма, то я не знаю, что ещё.
В 2022 году типичная вакансия дата-инженера включала 4–5 ключевых инструментов: SQL, Python, оркестратор (обычно Airflow), хранилище (Snowflake или BigQuery), иногда Spark для серьёзных объёмов.
В 2026 году та же вакансия с той же зарплатой теперь требует Kafka, Flink, dbt, Terraform, Kubernetes и «интеграцию LLM». Упоминания LLM в вакансиях выросли с 3% до 12% за один квартал. Это не постепенное внедрение, а панический найм.
Дело в том, что это не взаимодополняющие навыки. Это разные карьерные треки. Инженер Databricks, работающий с распределёнными вычислениями и оптимизацией Delta Lake, — не тот же человек, что инженер Snowflake, проектирующий паттерны конкурентности хранилища. Владение SQL и PySpark изучаются на разных этапах карьеры. Инженеры Databricks зарабатывают на $10K–$15K больше, чем инженеры Snowflake на аналогичных уровнях, не потому что Databricks «лучше», а потому что опыт работы со Spark и распределёнными системами встречается реже, чем знание SQL. Это принципиально разные кривые обучения, разные архитектуры, разная повседневная работа. Но в описаниях вакансий их перечисляют как взаимозаменяемые галочки.
Python встречается в 70% вакансий дата-инженеров, SQL — в 69%. Но дальше стек фрагментируется: Spark — 38,7%, Snowflake — 29,2%, Kafka — 24%, Databricks — 16,8%. Ни одна компания не сходится в том, что такое «стек». Поэтому они перечисляют всё, надеясь на идеального единорога.
Единорог не существует. А инженеры, которые ближе всего к этому — staff-уровня, понимающие всю сложность ландшафта — читают такое описание и закрывают вкладку.
Когда опытные инженеры видят 14+ инструментов в одной вакансии, они читают это как «компания не знает, что ей нужно», а не «мы тщательны».
Вакансии с 6–13 требованиями получают примерно на 30% больше откликов, чем вакансии с 14+. Не потому что на рынке не хватает талантов. А потому что люди с наибольшим опытом и контекстом чаще всего самоустраняются. Они знают, что никто не умеет всего этого. Джуниоры, которые не знают, чего не знают, и нажимают «Откликнуться».
Это не злой умысел. Это организационная дисфункция.
Большинство описаний вакансий пишутся не тем человеком, которому вы будете подчиняться. Их составляют комитетом. Нанимающий менеджер добавляет SQL и Python. Вице-президент добавляет Kubernetes и Terraform, потому что «мы переходим на cloud-native». ML-команда прикручивает интеграцию LLM, потому что слышала об этом на конференции. Рекрутер копирует из вакансии конкурента и добавляет то, что сработало в прошлый раз.
В итоге: три разные работы в одной вакансии. Платформенная инженерия. Инфраструктура потоковой передачи. Аналитическая инженерия. ML-операции. Каждая — отдельная специализация с разной кривой обучения и разным процессом собеседования. Никто в комитете не осознаёт, что они описали четырёх человек, а не одного. И никто не возражает, потому что добавление требований кажется бесплатным.
Это не бесплатно. Плохо составленные описания вакансий являются основной причиной более 50% неудач в найме. 44% нанимающих менеджеров не могут закрыть свои позиции, и это число растёт. Но вот главное: 94% работодателей говорят, что найм на основе навыков более предсказуем для успеха на работе, чем проверка резюме, однако более половины всё равно проверяют по жёстким спискам. Они знают, что процесс сломан. И продолжают так делать.
Компенсация рассказывает остальную историю. Зарплаты дата-инженеров выросли примерно с $113K до $153K за последние несколько лет. Это рост на 35%. Объём обязанностей примерно удвоился. Вас просят выучить вдвое больше, отвечать за вдвое больше, отлаживать вдвое больше — за прибавку в 35%. Экономика не сходится, и опытные инженеры видят это прямо в описании вакансии.
И давайте поговорим о 40% технологических компаний, которые за последний год размещали «фантомные» вакансии. Почти половина видимых вакансий дата-инженеров в LinkedIn — это не реальные открытые позиции. Вы продираетесь через список из 15 инструментов ради должности, которой может и не существовать. 62% нанимающих менеджеров признают, что их AI-скринеры отклоняют квалифицированных кандидатов, не соответствующих алгоритмическим паттернам. Так что даже если вы подадите заявку, ATS может похоронить её до того, как человек прочитает ваше имя. Фильтр сломан на каждом уровне.
Вот что происходит на первой неделе в любой из этих компаний. Никто не просит вас настроить кластер Flink, развернуть модель на Kubernetes и интегрировать LLM в пайплайн до обеда. На самом деле происходит вот что: вам показывают сломанный пайплайн, и вы выясняете, почему он сломан.
SQL и Python по-прежнему правят бал. SQL встречается в 94% собеседований на дата-инженеров, а SQL и Python вместе проходят примерно 60% реальных интервью. Остальные восемь инструментов из списка? Большинство команд используют в продакшене три, может четыре. Остальное — амбиции.
Реальная работа — это меньше «спроектируйте платформу потоковой передачи в реальном времени» и больше «выясните, почему этот пайплайн молча потерял 2 миллиона строк во вторник и сделайте так, чтобы это больше не повторилось». Продакшен-работа (отладка, инциденты, наблюдаемость) составляет около 60% того, чем дата-инженеры занимаются ежедневно. Она встречается примерно в 0% описаний вакансий. Никто не проверяет этот навык на собеседовании. Там спрашивают API Spark и задачи LeetCode среднего уровня. Это измеряет совершенно разные вещи.
77% дата-инженеров сообщают о возросшей нагрузке в 2026 году, несмотря на AI-инструменты, которые должны были её облегчить. Инженеры теперь тратят 37% времени на проекты, связанные с AI, по сравнению с 19% два года назад. AI не заменил работу; он создал новые категории работы поверх существующих. Обещание инструментов «делать больше с меньшими затратами» превратилось в «делать больше с большим, и ещё выучи это к пятнице».
Так что же на самом деле важно? Моделирование данных. Оптимизация запросов. Понимание, почему что-то ломается, а не только как это настроить, когда всё работает. Архитектура пайплайнов, а не системный дизайн (дата-инженерам плевать на балансировщики нагрузки и обратные прокси). Концепции, которые переносятся между любыми инструментами, любыми хранилищами, любыми оркестраторами. Концепции переносятся; знание инструментов — нет. Это всегда было правдой, и раздутые описания вакансий этого не изменили.
Вот практический совет. Откликайтесь при совпадении на 70%. Не 70% каждого случайного инструмента из списка; 70% обязательных требований. SQL, Python, один оркестратор, одно хранилище. Если у вас есть это плюс опыт поставки и отладки продакшен-пайплайнов, вы в игре.
42% кандидатов не соответствуют заявленным требованиям. Компании всё равно закрывают эти позиции. Нанимающие менеджеры часто знают, что не найдут того, кто отметит все галочки; описание вакансии — это якорь для переговоров, а не контракт. 81% работодателей в США внедрили найм на основе навыков, по сравнению с 57% в 2022 году. В описании — 15 инструментов, а на собеседовании проверяют три.
Перестаньте пытаться учить Kafka, Flink, Terraform и Kubernetes одновременно. Это погоня за инструментами, и это ловушка. Удвойте усилия по SQL, Python и моделированию данных. Нарабатывайте практику на том, что действительно спрашивают. Если вы оттачиваете Python, мы собрали вопросы по Python для собеседований, которые фокусируются на паттернах, встречающихся в реальных интервью, а не на редких фактах, которые никто никогда не проверял.
Оптимизируйте резюме под три-четыре инструмента, которые команда реально использует, а не под 15, которые перечислены. Не подгоняйте реальность под вымысел. Если в описании вакансии больше шести-семи различных инструментов, скорее всего, его составлял комитет, и никто в команде не использует их все. Это не сигнал дисквалифицировать себя; это сигнал, что компания наймёт за ядро и обучит периферии.
Снимите тревогу по поводу объёма. Должности Senior и Staff сходятся в одном описании с разницей в зарплате $10K. На бумаге некуда расти. Но на практике инженер, который может отладить продакшен-инцидент, смоделировать чистую схему и объяснить свои дизайнерские решения под давлением, — это тот, кого нанимают и повышают. Это не менялось за 15 лет дата-инженерии и не изменится, потому что кто-то добавил «интеграцию LLM» в описание.
Три staff-инженера, 40+ лет суммарного опыта, и никто из нас не прошёл ни по одному описанию вакансии. Это должно освободить вас, а не расстроить. Описание — вымысел. Ваши навыки — реальны. Знайте разницу, откликайтесь всё равно и пусть собеседование всё расставит по местам.
Какое самое абсурдное сочетание требований вы видели в вакансии дата-инженера?
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →