Data Engineer – скрытый герой данных: стек, тестовые задания и «красные флаги» при найме
За последние годы бизнес окружил себя модными терминами вроде Big Data, Data Science и искусственный интеллект. На этом фоне роль Data Engineer (инженера по данным) остаётся немного в тени – зато именно от него зависит, превратятся ли накопленные компанией данные в реальные инсайты. Без крепких «трубопроводов» данных даже самые продвинутые модели и аналитики бессильны.
Неудивительно, что спрос на дата-инженеров растёт взрывными темпами: например, по данным DICE, ещё в 2020 году число вакансий на эту позицию увеличилось на 50% по сравнению с предыдущим годом – это рекорд среди IT-специальностей (источник blog.skillfactory.ru). В результате хороших специалистов переманивают большими зарплатами (в России опытные дата-инженеры получают в среднем 250–300 тысяч ₽ в месяц), а HR-ам приходится выстраивать продуманный отбор. В этой статье – обзор того, что должен знать Data Engineer, как проверить его навыки на собеседовании и какие «красные флажки» помогут распознать проблемного кандидата.
Рост популярности дата-инженеров: в 2020 году количество вакансий выросло на 50% – самый высокий скачок среди IT-специальностей. Данные отчетa DICE Tech Job Report.
Кто такой Data Engineer и зачем он бизнесу
Если утрировать, дата-инженер – это высококвалифицированный «сантехник» мира данных, специалист, прокладывающий трубы и фильтры между различными источниками информации и теми, кто эту информацию потребляет. Его главная задача – настроить непрерывный поток данных внутри компании, чтобы разные системы и люди получали нужные данные быстро и в нужном формате. «Простыми словами, это инженер, который следит, чтобы данные в компьютерах компании передвигались и хранились правильно, как книги на полках библиотеки. Это помогает другим людям легче находить и использовать эти данные в работе» – именно так объясняет роль дата-инженера Максим Керемет (эксперт X5 Retail).
Для понимания места дата-инженера важно отличать его от более «раскрученного» сейчас Data Scientist. Дата-сайентист – исследователь, который придумывает, как с помощью данных решить задачу бизнеса (скажем, предсказать отток клиентов или настроить рекомендательную систему). Он формулирует гипотезы, экспериментирует с моделями и извлекает из данных инсайты.
Data Engineer же работает «за кулисами»: обеспечивает сбор и хранение сырого массива данных, превращает его в удобный для анализа вид и масштабирует успешные решения. Например, когда data scientist разработал ML-модель на небольшом наборе данных, именно инженеру данных поручат выстроить инфраструктуру для её работы на полном объёме информации и регулярного обновления модели. Кроме того, дата-инженер автоматизирует всю подготовку данных – от очистки и обогащения до мониторинга качества – чтобы аналитики и дата-сайентисты не тратили на это время.
Важно подчеркнуть: хотя дата-инженеры тесно связаны с data science-направлением, их роль имеет самостоятельную ценность для бизнеса. Они нужны везде, где компания хочет превращать большие данные в деньги – в телекоме, ритейле, банкинге, интернет-сервисах, промышленности и т.д.. Причём в небольших фирмах нередко ищут «универсала», совмещающего задачи инженера и аналитика, тогда как в крупных организациях эти функции уже разделены. В стартапе дата-инженеру могут впридачу поручить нагрузку дата-сайентиста или BI-аналитика – к этому стоит относиться осторожно.
Как отмечает Максим Керемет, на рынке до сих пор нет чётких требований к профессии, и порой в вакансиях на Data Engineer компании “навешивают” обязанности смежных ролей. Это приводит к ситуациям, когда человек, рассчитывавший развернуть сложные Pipelines на Python и Spark, по факту две третьих времени пишет простые SQL-запросы для отчётов. Вывод для HR: заранее определитесь, какого специалиста вы ищете и соответствует ли описание вакансии реальным задачам – иначе велика вероятность взаимного разочарования.
Технологический стек дата-инженера: от SQL до Hadoop
Ключевой вопрос для HR при найме – какими навыками должен обладать сильный Data Engineer. Ответ в том, что дата-инженер – это очень “разноплановый” разработчик, на стыке программирования, администрирования баз данных и аналитики. «На российском рынке Data Engineer – это человек, который может всё понемногу: и программировать, и работать с базами данных, и провести несложную аналитику (например, сделать дашборд в Power BI), и самостоятельно написать приложение» – объясняет тот же Максим Керемет. Рассмотрим основные элементы его техстека.
1. Базы данных и SQL. Поскольку 80% работы дата-инженера так или иначе связаны с таблицами, он обязан отлично знать SQL – язык запросов к реляционным СУБД. Инженер данных разбирается в разных типах хранилищ: реляционных БД (данные связаны по значениям, хранятся строками) и колоночных БД (оптимизированы для аналитики, данные хранятся по столбцам). В первом случае де-факто стандартом является PostgreSQL, во втором – отечественный ClickHouse, известный своей скоростью и широко применяемый для логирования и BI-задач.
Разумеется, мир баз данных этим не исчерпывается – в арсенале дата-инженера могут быть NoSQL-хранилища (MongoDB, Redis и т.п.) и современные облачные Data Warehouse решения: Amazon Redshift, Google BigQuery, Snowflake и др. Например, в так называемый «современный дата-стек» последних лет часто входят связки наподобие: системы передачи данных Fivetran/Stitch → облачное хранилище Snowflake/BigQuery → инструмент трансформации данных dbt → BI-платформа Looker, Tableau, Metabase и т.д. (источник habr.com). Хороший кандидат как минимум понимает, какие задачи решает каждый из этих элементов.
2. Программирование и автоматизация. Вторая «рука» дата-инженера – это кодинг, в первую очередь на языке Python. Этот язык стал по сути стандартом индустрии данных благодаря своей гибкости и обширным библиотекам.
Инженер данных должен уверенно писать скрипты на Python (уметь считывать наборы данных из разных источников, владеть основами ООП и т.д.). Эти навыки нужны не только для обработки данных, но и чтобы разрабатывать сервисы – например, REST API для доступа к данным, веб-приложения для мониторинга моделей, скрипты автоматизации повторяющихся процессов. Java и Scala также часто используются в data engineering – преимущественно там, где требуется максимальная производительность и надёжность на промышленном уровне. Например, Scala ценят при работе с платформой Apache Spark, потому что она обеспечивает более высокую скорость обработки больших данных, чем Python.
Кроме самих языков, важно знание систем контроля версий (Git). В современных командах инженеры данных выстраивают полноценный CI/CD для своих data-пайплайнов, поэтому умение работать с репозиториями (GitLab, GitHub) и контейнерами Docker уже практически обязательны. Docker позволяет «упаковать» ваш код вместе со всеми зависимостями так, чтобы его можно было запустить на любой машине – от ноутбука коллеги до кластера в облаке. А используя связку GitLab CI + Docker, дата-инженеры налаживают автоматический деплой ETL-скриптов, обновление данных по расписанию и прочие полезные штуки, повышающие надёжность инфраструктуры.
3. Big Data технологии. Отдельного разговора требуют навыки работы с распределёнными системами обработки данных. Когда данные исчисляются терабайтами и не умещаются на одном сервере, вступает в игру экосистема Hadoop/Spark.
Инженер данных должен понимать принципы распределённого хранения (HDFS, объектные хранилища в облаке) и иметь опыт с инструментами для параллельной обработки больших данных. Классический набор – это SQL-движок Hive (или аналогичный Presto/Trino) для выполнения запросов по огромным таблицам и фреймворк Apache Spark для масштабных вычислений в памяти кластера. Spark востребован всюду – от стриминговой обработки логов до машинного обучения на больших выборках – и поддерживает языки Scala, Java, Python, что возвращает нас к пункту 2. Также в Big Data-стеке часто фигурируют системы потоковой обработки и очередей сообщений (например, Apache Kafka для передачи потоков событий в реальном времени) и оркестраторы типа Apache Airflow (управление комплексными расписаниями задач).
Конечно, перечисленный стек не является закрытым списком – технологии эволюционируют. Ещё 5–7 лет назад в ходу были связки Hadoop MapReduce + Oozie, теперь они сменились на Spark + Airflow, завтра им на смену могут прийти новые инструменты. Поэтому хороший дата-инженер скорее не зациклен на конкретных технологиях, а понимает концепции: как спроектировать надёжный ETL/ELT-конвейер, как обеспечить масштабируемость, какие базы лучше подходят под конкретные виды данных. Если кандидат охотно рассуждает о таких вещах – это уже отличный признак его квалификации.
Собеседование data engineer: проверяем теорию и практику
Допустим, резюме претендента вас устраивает – дальше наступает самое интересное: этапы интервью и тестовых заданий. Как показывает практика, процесс отбора дата-инженеров многоступенчатый. Часто всё начинается с короткого скринингового звонка, где проверяют общий бэкграунд и мотивацию кандидата. Затем следует одно или несколько технических интервью с опытными инженерами, где детально оценивают знания (SQL, алгоритмы, архитектура данных и т.д.).
Почти неизбежно претендента ждёт и практическое испытание: ему могут выдать тестовое задание (take-home project) либо пригласить на сессию live-coding с задачей по разработке небольшого пайплайна или решению кейса (источник sky.pro). На высоких позициях добавляется раунд system design, где нужно спроектировать архитектуру данных для некоторого сценария. И, наконец, стандартный этап culture fit – проверка soft skills и того, впишется ли человек в команду.
Как же эффективно проверить ключевые навыки Data Engineer? Очевидно, что без проверки SQL не обходится ни одно интервью – обычно кандидатам дают написать несколько запросов, иногда прямо на виртуальной площадке с реальной базой. Помимо этого, популярны вопросы на знание принципов хранения данных, отличия разных систем (например, «чем колоночная база отличается от строковой?», «в каких случаях лучше NoSQL?» и т.д.). Интервьюеры любят убеждаться, что инженер мыслят системно: могут спросить, например, про разницу между классическим ETL и подходом ELT, и когда какой лучше применять.
Хороший специалист ответит, что ETL предполагает трансформацию до загрузки (традиционно использовался при ограниченных мощностях баз), а ELT – это новый тренд, когда данные сначала быстро загружаются «как есть» в хранилище, а уж потом преобразуются внутри него; ELT удобен в связке с мощными облачными DWH, позволяя гибче работать с сырыми данными. Вопросы могут затрагивать и Big Data: «как построить пайплайн реального времени для миллионов событий в час?» или «как обеспечить отказоустойчивость, если упадёт один из узлов кластера?». Здесь проверяется понимание распределённых систем, очередей сообщений, механизмов репликации и т.п.
Однако практика показывает, что одних устных вопросов недостаточно. Настоящая проверка data engineer – это приближенное к боевым условиям задание. Многие компании дают на выбор: либо выполнить небольшой проект дома за несколько дней, либо решить задачу в режиме реального времени на интервью. И у того, и у другого подхода есть плюсы/минусы.
Формат take-home позволяет кандидату подробнее показать свои навыки: написать чистый код, продемонстрировать умение пользоваться нужными инструментами. Зато есть риск, что кто-то посторонний ему поможет, или что задание займет слишком много времени (и отпугнёт сильных кандидатов, не готовых вкалывать бесплатно). Формат live-coding более честный – вы видите человека в деле – но за ограниченное время он успеет меньше, да и стресс может сказаться на результате.
Какой бы формат вы ни выбрали, важно продумать само задание. Эксперты советуют делать упор на реальные задачи, с которыми столкнётся инженер в вашей компании, а не на абстрактные головоломки. К сожалению, некоторые до сих пор проверяют дата-инженеров по принципу «как на разработчика алгоритмов из CS»: гоняют по математической статистике или классическим алгоритмам вроде бинарного дерева. Максим Керемет называет это ошибкой: количество решённых алгоритмических головоломок совсем не отражает реальной компетенции инженера данных.
Гораздо важнее посмотреть, как кандидат думает и пишет код в прикладном контексте. К примеру, попросите его разработать простой ETL-пайплайн: загрузить файл, трансформировать данные и сохранить результат, – и посмотрите, как он подойдёт к решению. Или дайте архитектурный кейс: «как спроектировать хранилище под данные такого-то типа, с такими-то требованиями по свежести и задержкам». Здесь уместно оценить и умение задавать вопросы, и подход к выбору технологий.
Кстати, умение задавать правильные вопросы – ценнейшее качество дата-инженера, на которое стоит обратить внимание ещё на этапе интервью. Опытные тимлиды делятся лайфхаком: они специально дают неполное или расплывчатое задание, чтобы посмотреть, станет ли кандидат уточнять требования. «Когда я работал в финтех-стартапе, часто просил кандидата набросать пайплайн обработки транзакций, намеренно не указав всех деталей, – рассказывает Максим Дорохов, Lead Data Engineer. – Лучшие инженеры сразу уточняли: какой объём данных ожидается? какова требуемая задержка обработки?
нужна полная загрузка или инкрементальная? Это мгновенно отделяло практиков от теоретиков». Если же человек молча принимается что-то кодить «вслепую», не выяснив контекста – это тревожный сигнал. В реальной работе дата-инженеру ежедневно приходится коммуницировать с заказчиками данных (аналитиками, менеджерами) и разбираться в бизнес-логике, поэтому инициативность и проактивность здесь крайне важны.
Напоследок, при оценке тестового задания помните, что важно не только что сделал кандидат, но и как. Обратите внимание на стиль кода, структуру решения, наличие комментариев. Хороший инженер задумывается о поддерживаемости: разбивает код на функции/модули, даёт понятные названия переменным, может сопроводить решение кратким README-файлом. Если же вы видите монолитный скрипт на 500 строк без единого пояснения, заваленный «магическими константами», – повод задуматься.
Возможно, человек торопился или не проявил должной усидчивости, а возможно – банально скачал чужое решение из интернета. Кстати, случаи плагиата в тестовых заданиях – не редкость, и это самый явный «красный флаг». Эксперты прямо говорят: если отношения с кандидатом начинаются с обмана, рассчитывать на его благонадёжность в работе точно не стоит (источник mts-link.ru).
«Красные флаги»: на что обратить внимание HR
Даже отличный технический результат не гарантирует, что кандидат идеально вам подойдёт. HR-ы и тимлиды выделяют множество тревожных сигналов – от резюме до финального интервью – которые помогают вовремя распознать потенциально проблемного сотрудника. Перечислим главные из них применительно к найму дата-инженеров.
1. Резюме не соответствует вакансии. Первый фильтр – это сама биография кандидата. Если соискатель откликается на роль Data Engineer, а в прошлом опыте ни одного проекта с данными, ни знаний нужных технологий – что ж, скорее всего, он плохо понимает, куда подается, или просто выстреливает резюме во все стороны.
МТС приводит такой случай как явный красный флаг: «если у человека нулевой опыт по заявленной должности, воспринимайте это как сигнал». Конечно, все когда-то были джуниорами, и кто-то действительно пытается сменить профиль – тут решение зависит от вашей готовности растить новичка. Но в целом несоответствие базовым требованиям – повод сэкономить время и отказаться от кандидата заранее.
2. Отсутствие внятной мотивации. Другая часть резюме – сопроводительное письмо или хотя бы ответы на скрининге – должны показать, зачем человек хочет именно в вашу компанию и именно на эту роль. Если же он не удосужился даже погуглить, чем занимается ваша фирма, и путается в ответе, чем предстоит заниматься на позиции, – это тревожный звоночек.
По словам HR-экспертов, неподготовленность к собеседованию (незнание профиля компании, ее продуктов) выдаёт либо низкую мотивацию, либо недостаток профессионализма. Дата-инженеры сейчас нарасхват, но если кандидат пришёл к вам только «за деньгами», без интереса к самим задачам, есть риск, что и работать он будет без энтузиазма. Директор по привлечению талантов МТС Яков Сайдин советует специально выяснять мотивацию: что человеку нравится в его работе, почему решил сменить место, чего хочет добиться. Незаинтересованный соискатель вряд ли задержится надолго.
3. Тривиальные или заученные ответы. Переходим к техническому интервью. Часто кандидаты готовятся по шпаргалкам – и это нормально, никто не обязуется помнить синтаксис или формулы наизусть. Но беда, если ответы звучат уж слишком шаблонно и поверхностно. Например, вы спрашиваете: «С какими сложностями вы сталкивались, строя дата-инфраструктуру?», а соискатель выдаёт дежурное: «Ну, бывало, на старом месте долго считались запросы, и я их оптимизировал индексами».
Вроде ответ по теме, но деталей ноль – возможно, человек вообще не участвовал в серьёзных проектах. Или задаёте кейс: «Какую самую большую проблему в процессах команды вы пытались решить?», а в ответ слышите банальное «Слишком много бессмысленных митингов». Как справедливо замечает техлид Avito Алексей Стратонов, жалоба на длинные совещания – это дефолтный ответ 90% кандидатов, потому что он лежит на поверхности (источник habr.com). Но такой ответ скорее выдаёт узкий кругозор и пассивность: если единственное, что инженер смог придумать – это порезать митинги, значит, он не был глубоко погружён в жизнь команды и не проявлял инициативы. Гораздо ценнее кандидат, который может рассказать о конкретном сложном случае и своих действиях для улучшения ситуации.
Чтобы вывести человека из зоны заготовленных ответов, интервьюеры обычно углубляют вопросы. Стратонов советует задать несколько уточнений даже к банальному ответу – так быстро выяснится, действительно ли инженер разбирается в теме или просто выучил «вопрос-ответ». Например, если кандидат заявляет, что знает Spark, можно спросить: «А как он работает с распределённой памятью? Какие типы RDD трансформаций знаете?».
Настораживающий признак – когда претендент путается и начинает отвечать односложно, без рассуждений. «Важно услышать ход мысли человека», – подчёркивает Стратонов. Если же инженер на каждый уточняющий вопрос отвечает всё более односложно и не пытается рассуждать – это красный флаг. Возможно, он просто зазубрил несколько фактов и не обладает глубоким пониманием.
4. Не признаёт своих ошибок. Интересный момент – как кандидат реагирует, если ловит себя на незнании или ошибке. Работа инженера данных сложна и порой непредсказуема: баги, падения джобов, несовместимость версий – со всем этим придётся иметь дело. Поэтому ценно умение честно сказать: «Я чего-то не знаю» и умение учиться на ошибках.
Если же соискатель начинает юлить, выгораживать себя или, хуже того, перекладывать вину на других, стоит насторожиться. Допустим, в резюме он указал опыт оптимизации хранилища, а на деле не может объяснить базовых вещей – но вместо признать, что не сталкивался, начинает жаловаться, что «в той компании был бардак, мне не дали ничего сделать». Такой тип поведения – «не брать ответственность» – в будущем может обернуться серьезными проблемами в работе. В МТС предупреждают: если кандидат «обвиняет бывших коллег и начальство во всех неудачах» или слишком оправдывается за провалы, это однозначно плохой сигнал. В командной работе важно уметь анализировать свои промахи, а не искать крайних.
5. Не укладывается в тестовом задании или халтурит. О красных флагах на этапе практики мы частично говорили выше, но повторим главное. Халатное отношение к тестовому заданию – верный признак низкой мотивации либо плохих привычек кандидата. Халатность может проявляться по-разному. Самый простой случай – небрежное оформление: в решении полно опечаток, непроверенных ошибок, не соблюдены оговорённые требования.
Например, просили документировать шаги, а он ничего не написал; жёстко ограничили время выполнения, а он сдал на три дня позже без объяснений. Конечно, бывают уважительные причины, но чаще всего просрочка дедлайна без предупреждения сигнализирует, что человек либо неорганизован, либо не слишком заинтересован и параллельно делает тесты для пяти компаний. В обоих случаях это риск для найма. Ещё один флажок – когда решение прислано, но полностью скопировано с чужого (из GitHub, у знакомого и т.п.). Некоторые думают, что HR не заметит подмены, однако опытные инженеры легко вычисляют несоответствие стиля кода или уровня знаний. Ловили кандидата на плагиате – можно смело ставить крест: если он начинает отношения с обмана, вряд ли дальше будет лучше.
6. Отсутствие вопросов и интереса. Наконец, один из самых верных индикаторов – как уже отмечалось, это активность самого кандидата на интервью. Если человек за всё время не задал ни одного вопроса о будущем проекте, о команде, о процессах – что ж, вероятно, ему всё равно. Для HR-а это красный флаг: значит, либо мотивация низкая, либо кандидат привык мыслить узко и выполнять задания без понимания контекста.
Яков Сайдин из МТС прямо включает «не задаёт вопросов на собеседовании» в список очевидных тревожных сигналов. Лучшие инженеры, как правило, сами проявляют любопытство: спрашивают про используемый стек, проблемы, которые предстоит решать, состав команды. Если же этого не происходит, задумайтесь – возможно, перед вами человек, который воспринимает работу лишь как обмен времени на деньги. В высокотехнологичной роли, требующей креативности и вовлечённости, такая установка не сулит успеха.
Конечно, ни один критерий не даёт полной гарантии, поэтому решение о найме всегда комплексное. В работе с данными невероятно ценятся и технические таланты, и гибкость ума, и навыки коммуникации. В идеале вы хотите получить инженера, который и код напишет надёжный, и спросит лишний раз у аналитика, правильно ли понял задачу, и не растеряется, если что-то пойдёт не по плану.
Найти такого – непросто, но вполне реально, если подходить к найму вдумчиво. Изучайте резюме в связке с тестовыми заданиями, задавайте нестандартные вопросы, вникайте в мотивацию кандидата. И наоборот, не бойтесь отказать талантливому технарю, если чувствуете по “софт-скиллам”, что он не приживётся в вашей команде.
Вывод: дата-инженер становится всё более важной фигурой в компаниях, и HR-специалистам важно понимать специфику этой профессии. Зная, какие технологии стоят за красивым словом Data Engineer, какие задачи ему придётся решать и какие «звоночки» в поведении претендента могут предвещать проблемы, вы значительно повысите шансы нанять того самого человека. Инженера, который построит для вашего бизнеса «трубопровод данных» – и даст ему потечь полноводной рекой.