Питання співбесіди Data Engineer, за етапами

Можливо, ви готуєтеся так само, як до циклу співбесід software engineer, і думаєте, у чому різниця. Цей розділ показує етапи, які повторюються в цих співбесідах, щоб ви могли витратити час на два етапи, які насправді відрізняють кандидатів. Технічний фільтр рідко є місцем, де втрачають офери.

• SQL. Віконні функції, дедуплікація і продуктивність запитів, зазвичай наживо.
• Моделювання даних. Проєктування таблиць для описаного бізнесу і захист обраного grain.
• Проєктування пайплайна й ETL. Відкритий етап системного дизайну, зосереджений на русі даних.
• Розподілена обробка. Як фреймворк насправді виконує вашу job і чому вона повільна.
• Кодування. Python або Scala, часто легше за етап software engineering.
• Поведінковий. Інциденти на чергуванні, зламані дашборди й стейкхолдери, яким число було потрібне вчора.

Назви посад сильно перетинаються з analytics engineering і платформними ролями, тому набір змінюється. Пов'язані банки питань за ролями лежать у хабі питання співбесід за роллю.

SQL

• Здедуплікуйте таблицю, залишивши лише найновіший рядок для кожного ключа.
• Напишіть запит, що повертає кількість сесій кожного користувача з розривом неактивності 30 хвилин.
• Обчисліть накопичувальний підсумок і зміну місяць до місяця в одному запиті.
• Знайдіть рядки, присутні у вчорашньому знімку, але відсутні в сьогоднішньому.
• Що робить QUALIFY, і що ви написали б без нього?
• Цей запит сканує мільярд рядків і триває двадцять хвилин. Як ви це діагностуєте?
• Поясніть різницю між partitioning і clustering та коли кожен допомагає.

Моделювання даних

• Спроєктуйте таблиці для історії замовлень онлайн-маркетплейсу. Який grain вашої fact table?
• Поясніть star schema і коли ви навмисно денормалізували б далі.
• Що таке slowly changing dimension і як ви реалізуєте тип два?
• Стейкхолдер хоче, щоб історична звітність відображала поточний регіон клієнта. Що зламається?
• Як би ви змоделювали потік подій, що надходить не по порядку?
• Коли ви обрали б широку таблицю замість нормалізованої моделі?

Етап моделювання винагороджує тих, хто визначається з grain і захищає його. Кандидати, які описують три можливі дизайни, не обираючи жодного, отримують нижчі оцінки, ніж ті, хто обирає розумний дизайн і називає його слабкість.

Проєктування пайплайна й ETL

• Спроєктуйте пайплайн, що завантажує щоденні транзакції у сховище для звітності.
• Джерело upstream надсилає вчорашні дані повторно. Що відбувається з вашою job?
• Як зробити пайплайн ідемпотентним і чому це важливо для повторних запусків?
• Як би ви зробили backfill за два роки історії, не порушуючи щоденне завантаження?
• Запізнілі дані з'являються через три дні після закриття партиції. Що ви робите?
• Як ви виявляєте, що пайплайн завершився успішно, але виробив неправильні дані?
• Що ви моніторите і що розбудить когось о третій ночі?

Розподілена обробка і стрімінг

• Що спричиняє shuffle і чому він дорогий?
• Ваша job повільна, і один task триває набагато довше за решту. Що відбувається?
• Поясніть data skew і два способи з ним впоратися.
• Коли ви обрали б стрімінг замість запланованої batch-job?
• Що насправді гарантує exactly once processing і де це не діє?
• Як watermark обробляють події не по порядку у windowed-агрегації?

Зверніть увагу, як мало з цих питань просять назвати інструмент. Назвати один — лише початок відповіді, не сама відповідь. Наступне питання завжди чому і що зламається.

Читання цих списків дає впізнавання. Етапи дизайну перевіряють інше: утримувати систему в голові, поки хтось перериває вас сценарієм збою. Це приходить лише від промовляння дизайнів уголос.

• Намалюйте й опишіть пайплайн за п'ятнадцять хвилин. Джерело, landing, трансформація, serve, плюс як кожен етап дає збій.
• Атакуйте власний дизайн. Після кожного тренування запитуйте, що відбувається при повторному запуску, при запізнілих даних і при зміні схеми.
• Майте напоготові число для масштабу. Рядків на день, розмір, бюджет затримки. Озвучення припущеного масштабу першим оцінюється.
• Пишіть SQL вручну. Живі етапи часто використовують простий редактор без автозаповнення і без виконання.
• Відпрацюйте одну історію інциденту як слід. Що зламалося, як ви це виявили, що змінили, щоб це не повторилося.

Data engineer із шестирічним досвідом роботи з batch-пайплайнами готувалася, переглядаючи внутрішній устрій фреймворків, а потім застрягла на "джерело upstream повторно надіслало вчорашній файл", бо обробляла це лише вручну, ніколи не пояснювала. Знання були; усної відповіді не було. Тренування етапу дизайну з наступними питаннями — саме те, для чого створено режим mock interview.