Как перейти в инженерию данных из другой области?

Откуда вы начинаете важнее должности

Инженер данных — не лицензируемая профессия. Нет регистрирующего органа, нет экзамена, который нужно сдать, прежде чем так себя называть, ничего похожего на профессиональную аттестацию. Звучит как хорошая новость, и в каком-то смысле так и есть: никто не может отсечь вас формально. Но это также означает, что отбор происходит полностью за столом менеджера по найму, через собеседование и тестовое задание, и эта планка росла, а не снижалась, поскольку всё больше рутинной ETL-работы поглощается управляемыми инструментами вроде Fivetran, dbt Cloud и облачными сервисами для загрузки данных. То, что остаётся делать инженеру данных, — всё чаще более сложная половина: проектирование пайплайнов, которые не портят данные незаметно, обработка обратных загрузок и запаздывающих событий, управление оркестрацией (Airflow, Dagster или облачный планировщик), рассуждения о стоимости и масштабе в распределённой системе. Это та работа, на которую вы на самом деле претендуете, что бы ни говорилось в объявлении.

Что реально переносится

Если вы инженер-программист, переходящий в эту область, большая часть того, что у вас есть, переносится напрямую: дисциплина контроля версий, тестирование, ревью кода, чутьё к тому, что происходит, когда задача падает на полпути. Что вы добавляете — это моделирование данных (схемы звезды, медленно меняющиеся измерения, стратегия партиционирования) и специфические режимы отказа пакетных и потоковых пайплайнов — идемпотентность, exactly-once против at-least-once доставки, дрейф схем. Это кратчайший путь в роль, и менеджеры по найму это знают; ожидайте, что вас попросят спроектировать пайплайн на доске, а не просто написать функцию.

Если вы аналитик данных или BI-разработчик, ваш SQL вероятно силён, а понимание того, как бизнес реально использует данные — реальный актив, которого не хватает большинству чистых программистов. Что не переносится автоматически — инженерная половина: написание продакшн Python (не скриптов в блокнотах), построение и тестирование пайплайнов, а не запросы к таблицам, которые кто-то другой наполнил, и работа с инструментами оркестрации и инфраструктуры. Роль analytics engineer (построенная вокруг dbt) находится между двумя позициями и является обычной, надёжной ступенькой — стоит явно назвать это в резюме, если это ваш путь, поскольку теперь это признанная должность сама по себе, а не эвфемизм.

Если вы администратор баз данных, проектирование схем, индексирование и настройка производительности хорошо переносятся, и интервьюеры серьёзно отнесутся к опыту DBA. Чего обычно не хватает — уверенности в языке общего назначения на продакшн-уровне и опыта с облачными, горизонтально масштабируемыми инструментами (Spark, BigQuery, Redshift, Snowflake), которые в значительной степени заменили администрирование однопоточных баз данных в такой роли.

Если вы data scientist, будьте честны с собой насчёт пересечения: построение моделей и статистический вывод — это другой набор навыков, чем инженерия пайплайнов, и эти две вещи смешиваются в объявлениях о работе больше, чем следовало бы. Некоторые data scientists написали много продакшн-кода для пайплайнов, и переход реален; другие в основном работали в блокнотах с данными, которые кто-то другой подготовил, и переход гораздо более тонкий, чем предполагает должность.

Если вы приходите из области без опыта программирования вообще — операции, финансы, совершенно другая инженерная дисциплина — короткого пути нет. Маршрут существует, но он проходит через обучение написанию и тестированию ПО сначала, обычно через роль аналитика или младшего инженера-программиста, а не напрямую в инженерию данных.

Вопрос сертификации

Лицензии нет, но есть рынок сертификации, и стоит трезво понимать, что она делает и чего не делает. AWS Certified Data Engineer – Associate, Google Cloud Professional Data Engineer, Microsoft Azure Data Engineer Associate и Databricks Data Engineer Associate существуют и неплохо признаются. Они демонстрируют, что вы изучили сервисы конкретной платформы и можете ответить на вопросы с множественным выбором о них в условиях экзамена. Чего они не демонстрируют, и что большинство менеджеров по найму скажут вам, они ценят гораздо меньше сертификата — это что вы можете построить нечто, что выживет при контакте с реальными, грязными, запаздывающими, дублированными данными в продакшне. Рассматривайте сертификацию как доказательство того, что вы можете свободно говорить о платформе на собеседовании, а не как то, что даёт вам собеседование. Репозиторий GitHub с реальным пайплайном — загружающим реальные данные, с тестами, логированием и написанной заметкой о том, что его ломает — делает больше работы, чем сертификат, лежащий рядом с ним в резюме.

Что должна преодолеть ваша заявка

Три вещи конкретно, и это не то, что вам скажет исправить общий совет по резюме.

Во-первых, проблема именованных инструментов. Объявления о вакансиях для инженеров данных необычно конкретны насчёт инструментария — Airflow, dbt, Kafka, Spark, хранилище данных конкретного облака — потому что команды нанимают кого-то, кто может быстро стать продуктивным с их существующим стеком. Если ваш опыт в другом наборе инструментов, система отслеживания кандидатов или быстрый первый просмотр отфильтруют вас, прежде чем кто-то прочтёт параграф о переносимых навыках. Исправление не в том, чтобы заявлять об инструментах, которые вы не использовали; а в том, чтобы построить что-то реальное с инструментами, наиболее часто называемыми в ролях, которые вы хотите, даже в малом масштабе, и точно сказать, что вы с ними построили.

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

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

Сколько это реально занимает

Нет единого честного числа, но есть честные диапазоны в зависимости от того, откуда вы начинаете.

Из разработки ПО, с существующей беглостью в Python и SQL: три-шесть месяцев целенаправленной работы — правильное изучение моделирования данных, выбор одного инструмента оркестрации и одного облачного хранилища данных, и построение двух-трёх проектов пайплайнов — реалистично, прежде чем вы станете конкурентоспособны для junior-mid ролей инженера данных.

Из аналитической или BI-работы, с сильным SQL, но ограниченной практикой разработки ПО: шесть-двенадцать месяцев, потому что вы строите новый навык (продакшн-код, тестирование, оркестрация), а не расширяете существующий. Роли analytics engineer часто достижимы раньше, чем роли data engineer, с этой стартовой точки, и могут служить реальным мостом, а не утешительным призом.

Из нетехнической области: двенадцать-двадцать четыре месяца — реалистичный диапазон, обычно через промежуточную роль, а не прямым прыжком. Подозрительно относитесь к чему-либо, обещающему быстрее этого; люди, которые добиваются этого за три месяца с нуля без истории программирования — исключение, которое продаётся как правило.

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

Что делать дальше

Выберите одну облачную платформу и один инструмент оркестрации и придерживайтесь их, а не пробуйте пять. Постройте один пайплайн от начала до конца с реальным, грязным, публичным источником данных — загрузка, трансформация, тесты и написанная заметка о режимах отказа — и поместите это туда, где менеджер по найму действительно посмотрит. Затем пройдитесь по конкретным объявлениям о работе, которые вы хотите, а не общим, и проверьте, покрывает ли ваш проект действительно инструменты, которые они называют; где нет, это следующая вещь для построения, а не следующий шаблон резюме для загрузки. jobmarket.pro читает полные объявления о вакансиях против вашего реального опыта и говорит вам, инструмент за инструментом, где конкретная роль инженера данных подходит, а где нет, прежде чем вы потратите вечер на написание заявки на то, что никогда бы не получилось.