Вопросы на собеседовании data engineer, по этапам

Возможно, вы готовитесь так же, как к собеседованию software engineer, и гадаете, в чём разница. Этот раздел показывает, какие этапы повторяются в таких собеседованиях, чтобы вы потратили время на два этапа, которые реально разделяют кандидатов. Технический фильтр редко становится местом, где теряют офферы.

• SQL. Оконные функции, дедупликация и производительность запросов, обычно вживую.
• Моделирование данных. Проектирование таблиц под описанный бизнес и защита выбранной гранулярности.
• Дизайн пайплайна и ETL. Открытый этап системного дизайна, ограниченный движением данных.
• Распределённая обработка. Как фреймворк на самом деле выполняет вашу задачу и почему это медленно.
• Кодирование. Python или Scala, часто легче, чем этап software engineering.
• Поведенческий. Инциденты на дежурстве, сломанные дашборды и стейкхолдеры, которым число было нужно ещё вчера.

Названия должностей сильно пересекаются с analytics engineering и платформенными ролями, поэтому набор вопросов меняется. Смежные банки вопросов по ролям собраны в хабе вопросы на собеседовании по ролям.

SQL

• Дедуплицируйте таблицу, оставив только самую свежую строку по каждому ключу.
• Напишите запрос, возвращающий количество сессий каждого пользователя, используя разрыв неактивности в 30 минут.
• Посчитайте накопительный итог и изменение месяц к месяцу одним запросом.
• Найдите строки, присутствующие во вчерашнем снапшоте, но отсутствующие в сегодняшнем.
• Что делает QUALIFY, и что вы написали бы без него?
• Этот запрос сканирует миллиард строк и занимает двадцать минут. Как вы будете это диагностировать?
• Объясните разницу между партиционированием и кластеризацией и когда что помогает.

Моделирование данных

• Спроектируйте таблицы для истории заказов онлайн-маркетплейса. Какая гранулярность у вашей fact-таблицы?
• Объясните star schema и когда вы намеренно денормализовали бы её ещё сильнее.
• Что такое slowly changing dimension и как вы реализуете тип два?
• Стейкхолдер хочет, чтобы исторические отчёты отражали текущий регион клиента. Что сломается?
• Как бы вы смоделировали поток событий, приходящих не по порядку?
• Когда вы выберете широкую таблицу вместо нормализованной модели?

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

Дизайн пайплайна и ETL

• Спроектируйте пайплайн, загружающий ежедневные транзакции в хранилище для отчётности.
• Источник upstream снова присылает вчерашние данные. Что происходит с вашей задачей?
• Как сделать пайплайн идемпотентным и почему это важно для повторных запусков?
• Как бы вы сделали backfill за два года истории, не нарушив ежедневную загрузку?
• Опоздавшие данные появляются через три дня после закрытия партиции. Что вы делаете?
• Как бы вы обнаружили, что пайплайн отработал успешно, но выдал неверные данные?
• Что вы мониторите и что будит кого-то в три часа ночи?

Распределённая обработка и стриминг

• Что вызывает shuffle и почему он дорогой?
• Ваша задача выполняется медленно, и одна таска занимает намного дольше остальных. Что происходит?
• Объясните data skew и два способа с ним справиться.
• Когда вы выберете стриминг вместо запланированной batch-задачи?
• Что на самом деле гарантирует exactly once обработка и где эта гарантия не действует?
• Как watermark обрабатывают события не по порядку в оконной агрегации?

Обратите внимание, как мало из этого просит вас назвать инструмент. Назвать инструмент — это начало ответа, а не сам ответ. Дальше всегда спрашивают почему и что сломается.

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

• Нарисуйте и опишите пайплайн за пятнадцать минут. Источник, landing, трансформация, отдача, плюс как ломается каждый этап.
• Атакуйте собственный дизайн. После каждой тренировки спрашивайте, что произойдёт при повторном запуске, при опоздавших данных и при изменении схемы.
• Держите наготове цифру масштаба. Строк в день, размер, бюджет задержки. Назвать предполагаемый масштаб первым — это оценивается.
• Пишите SQL от руки. На живых этапах часто используют простой редактор без автодополнения и без выполнения.
• Отрепетируйте одну историю инцидента как следует. Что сломалось, как вы это нашли, что изменили, чтобы это не повторилось.

Дата-инженер с шестилетним опытом на batch-пайплайнах готовилась, повторяя внутреннее устройство фреймворков, а затем застряла на фразе "источник upstream снова прислал вчерашний файл", потому что раньше только обрабатывала это вручную, но никогда не объясняла. Знание было; произнесённого ответа не было. Тренировка этапа дизайна с дополнительными вопросами — именно для этого создан режим mock interview.