Что на самом деле проверяют на собеседовании дата-инженера

Кто на самом деле в комнате

На позицию дата-инженера после первого звонка вас редко оценивает рекрутер-универсал. Технические раунды обычно ведёт старший дата-инженер или руководитель направления, иногда с аналитическим инженером или дата-сайентистом, если ваши пайплайны будут питать их модели. Это важно, потому что вопросы задают люди, которых будили в три ночи из-за сломанного DAG, а не по чек-листу от HR. Они слушают, действительно ли вы управляли пайплайном в продакшене, а не можете ли вы определить ETL.

Маленькие компании часто объединяют всё в два раунда: живую техническую сессию и разговор с тем, кто отвечает за платформу данных. Крупные разделяют на скрининг по SQL/Python, раунд по проектированию систем или пайплайнов и раунд о ценностях или работе со стейкхолдерами с кем-то из команды, которую вы будете обеспечивать данными — часто аналитиком или продакт-менеджером, и это раунд, к которому кандидаты готовятся меньше всего, потому что он выглядит как светская беседа, а на деле — нет.

Скрининг по SQL и Python

Это редко тест на терминологию. Вам дадут схему — обычно что-то вроде заказов, клиентов, событий — и попросят написать запрос с оконными функциями: накопительные итоги, ранжирование внутри партиции, self-join для поиска разрывов или наложений в диапазонах дат. Суть не в синтаксисе, а в том, тянетесь ли вы к нужному инструменту без подсказок. Кандидат, который решает «найти первую и вторую покупку каждого клиента» через correlated subquery, когда LAG() справится чисто, сообщает интервьюеру кое-что о том, как он будет писать продакшен-SQL в условиях нехватки времени.

По Python ждите манипуляции данными через pandas или чистый Python — дедупликацию грязного датасета, парсинг искажённого JSON, обработку null-значений, которые в разных колонках означают разное. Всё чаще вас попросят порассуждать о Spark-джобе: почему трансформация медленная, где происходит shuffle, поможет ли repartitioning перед join. Если вы запускали Spark только через управляемую платформу вроде Databricks и никогда не объясняли, почему джоба начала писать на диск, здесь это вскроется.

Как здесь звучит поверхностный ответ: пересказ того, что индексы «ускоряют запросы», без возможности сказать, что происходит с производительностью записи, или правильное объяснение синтаксиса оконной функции, но неспособность сказать, когда использовать ROW_NUMBER() вместо RANK() и что сломается, если ошибиться на таблице с дублирующимися ключами.

Раунд по проектированию пайплайнов или систем

Этот раунд отделяет тех, кто настраивал инструмент, от тех, кто владел системой. Вас обычно попросят спроектировать что-то вроде: загрузить события из приложения в хранилище, держать dimension-таблицу синхронизированной с изменяющимся upstream-источником или построить пайплайн, который должен backfill-ить три года истории без удвоения счёта за вычисления.

Интервьюер слушает несколько конкретных вещей, и они всплывают почти в каждой версии этого вопроса:

• Идемпотентность. Можно ли запустить ваш пайплайн на тех же данных повторно без дубликатов или задвоенных итогов? Если в ответе не упоминается, как вы справитесь с джобой, которая упала на середине и перезапускается, это пробел, который они прощупают.
• Эволюция схемы. Что случится, когда исходная система добавит колонку или изменит тип с int на string? Вы падаёте с громким сообщением или молча портите downstream-таблицы? Упоминание schema registry или того, как тесты dbt или Great Expectations это поймают, сигнализирует, что вы уже на этом обжигались.
• Batch против streaming и почему. Не «streaming лучше» — это поверхностный ответ. Настоящий ответ объясняет trade-off: Kafka или Kinesis дают низкую задержку и сложность, которой теперь владеете вы, против запланированной batch-джобы в Airflow или Dagster, о которой проще рассуждать и которую проще дебажить, но данные остаются устаревшими на всю длину расписания.
• Партиционирование и стоимость. Если вы проектируете таблицу без упоминания партиционирования — обычно по дате в хранилище вроде BigQuery или Snowflake — и без признания того, что полный скан многотерабайтной fact-таблицы стоит реальных денег, интервьюер заметит упущение, даже если не скажет.
• Slowly changing dimensions. Если сценарий включает dimension, меняющийся со временем (адрес клиента, категория товара), вы его перезаписываете или версионируете через что-то вроде SCD Type 2? Ошибка здесь не провалит вас мгновенно, но незнание термина, когда интервьюер говорит «как бы вы обработали смену региона клиента» — показатель.

Поверхостный ответ на вопрос проектирования звучит бегло об инструментах и молчит о сбоях. «Я бы использовал Airflow для оркестрации и положил в Snowflake» — предложение без инженерии — оно называет вендора и пропускает решение. Сильный ответ говорит почему: почему этот оркестратор обрабатывает backfill так, как вам нужно, почему clustering keys этого хранилища важны для паттерна запросов, которые аналитики реально выполняют.

Вопросы, похожие на светскую беседу

«Расскажите о случае, когда построенный вами пайплайн сломался в продакшене» — это не разминка. Обычно это самый диагностический вопрос во всём процессе, потому что поверхностный ответ даёт симптом («дашборд показывал неправильные цифры»), а настоящий даёт механизм: какой мониторинг или его отсутствие привели к тому, что вы узнали от стейкхолдера, а не из алерта, какой оказалась первопричина — опоздавший файл, баг с таймзонами, изменение upstream-схемы, о котором вам не сказали — и что вы изменили потом, чтобы это не могло повториться тем же образом.

Аналогично, «как вы решаете, что тестировать в пайплайне» задаётся, чтобы увидеть, пишете ли вы проверки качества данных по привычке — количество строк, пороги null, ссылочную целостность между fact и его dimensions — или тестирование для вас это то, что делается после инцидента, потому что кто-то велел. Упоминание конкретной практики, вроде проверки, что внешний ключ в fact-таблице всегда разрешается в строку в dimension, звучит лучше, чем «я пишу тесты для своих пайплайнов», что может описывать любую джобу со словом pipeline.

«Как бы вы объяснили стейкхолдеру, почему их отчёт опоздал на день» проверяет кое-что иное: можете ли вы перевести техническую причину — ограничение rate limit в API источника, downstream-зависимость, которая не завершилась — на язык, с которым может работать не-инженер, не упрощая до нуля и не топя в терминологии DAG, которой у них нет.

Что выдаёт человека, не делавшего эту работу

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

Другой признак — говорить об объёме данных без упоминания стоимости или паттерна запросов. «У нас были миллиарды строк» само по себе не инженерный факт. Что это означало для партиционирования, кластеризации или компактизации таблицы, и что случилось бы со счётом хранилища, если бы вы ошиблись? Интервьюер, владевший дашбордом расходов Snowflake или BigQuery, задаст уточняющий вопрос и быстро выяснит, имели ли вы дело с миллиардами строк или просто упомянули их.

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

Перед следующим интервью выберите два пайплайна, которые вы действительно построили, и будьте готовы описать в конкретных терминах: как вы перезапустите их безопасно после частичного сбоя, что случится, если схема источника изменится под вами, и один инцидент, где он сломался и что вы изменили потом. Практикуйте формулировку trade-off, а не просто инструмента — batch против streaming, денормализованное против нормализованного, оркестратор A против оркестратора B — потому что это форма предложения, которую слушает интервьюер.

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