Pytania Rekrutacyjne dla Data Engineera, wg Etapu

Możesz przygotowywać się tak samo, jak do procesu rekrutacyjnego dla software engineera, zastanawiając się, na czym polega różnica. Ta sekcja mapuje etapy, które te rozmowy powtarzają, dzięki czemu możesz poświęcić czas na dwa etapy, które naprawdę odróżniają kandydatów. Filtr techniczny rzadko jest miejscem, w którym tracone są oferty.

• SQL. Funkcje okienkowe, deduplikacja i wydajność zapytań, zwykle na żywo.
• Modelowanie danych. Projektowanie tabel dla opisanego biznesu i obrona wybranego grain.
• Projektowanie pipeline'u i ETL. Otwarty etap projektowania systemu skupiony na przepływie danych.
• Przetwarzanie rozproszone. Jak framework faktycznie wykonuje twój job i dlaczego jest wolny.
• Programowanie. Python lub Scala, często lżejsze niż etap software engineeringu.
• Behawioralny. Incydenty na dyżurze, zepsute dashboardy i interesariusze, którzy chcieli liczby wczoraj.

Tytuły stanowisk mocno pokrywają się z analytics engineeringiem i rolami platformowymi, więc mieszanka się zmienia. Powiązane banki pytań dla ról znajdziesz w hubie pytania rekrutacyjne wg roli.

SQL

• Zdeduplikuj tabelę, zostawiając tylko najnowszy wiersz dla każdego klucza.
• Napisz zapytanie zwracające liczbę sesji każdego użytkownika, używając 30-minutowej przerwy nieaktywności.
• Oblicz sumę narastającą i zmianę miesiąc do miesiąca w jednym zapytaniu.
• Znajdź wiersze obecne we wczorajszym snapshotcie, ale nieobecne w dzisiejszym.
• Co robi QUALIFY, i co napisałbyś bez tego?
• To zapytanie skanuje miliard wierszy i trwa dwadzieścia minut. Jak to zdiagnozujesz?
• Wyjaśnij różnicę między partitioningiem a clusteringiem i kiedy każdy pomaga.

Modelowanie danych

• Zaprojektuj tabele dla historii zamówień internetowego marketplace'u. Jaki jest grain twojej fact table?
• Wyjaśnij star schema i kiedy celowo zdenormalizowałbyś dalej.
• Czym jest slowly changing dimension i jak implementujesz typ dwa?
• Interesariusz chce, aby historyczne raportowanie odzwierciedlało obecny region klienta. Co się psuje?
• Jak zamodelowałbyś event stream, który przychodzi nie po kolei?
• Kiedy wybrałbyś szeroką tabelę zamiast znormalizowanego modelu?

Etap modelowania nagradza zaangażowanie się w jeden grain i jego obronę. Kandydaci, którzy opisują trzy możliwe projekty bez wyboru jednego, oceniani są gorzej niż kandydaci, którzy wybierają rozsądny projekt i wskazują jego słabość.

Projektowanie pipeline'u i ETL

• Zaprojektuj pipeline, który ładuje codzienne transakcje do hurtowni danych na potrzeby raportowania.
• Źródło upstream ponownie wysyła wczorajsze dane. Co dzieje się z twoim jobem?
• Jak sprawiasz, że pipeline jest idempotentny, i dlaczego ma to znaczenie dla ponownych uruchomień?
• Jak wykonałbyś backfill dwóch lat historii bez zakłócania codziennego ładowania?
• Opóźnione dane pojawiają się trzy dni po zamknięciu partycji. Co robisz?
• Jak wykrywasz, że pipeline zakończył się sukcesem, ale wyprodukował złe dane?
• Co monitorujesz, i co obudzi kogoś o trzeciej nad ranem?

Przetwarzanie rozproszone i streaming

• Co powoduje shuffle, i dlaczego jest kosztowny?
• Twój job jest wolny, a jeden task trwa dużo dłużej niż reszta. Co się dzieje?
• Wyjaśnij data skew i dwa sposoby radzenia sobie z nim.
• Kiedy wybrałbyś streaming zamiast zaplanowanego joba wsadowego?
• Co dokładnie gwarantuje exactly once processing, i gdzie to nie obowiązuje?
• Jak watermarki obsługują zdarzenia nie po kolei w agregacji okienkowej?

Zwróć uwagę, jak niewiele z tych pytań prosi cię o nazwanie narzędzia. Nazwanie jednego to początek odpowiedzi, nie odpowiedź. Pytanie uzupełniające zawsze brzmi dlaczego i co się psuje.

Czytanie tych list buduje rozpoznawanie. Etapy projektowe testują coś innego: utrzymanie systemu w głowie, gdy ktoś przerywa ci scenariuszem awarii. To bierze się tylko z mówienia projektów na głos.

• Narysuj i opowiedz pipeline w piętnaście minut. Źródło, landing, transformacja, serwowanie, plus jak każdy etap zawodzi.
• Zaatakuj własny projekt. Po każdej sesji ćwiczeniowej zapytaj, co dzieje się przy ponownym uruchomieniu, przy opóźnionych danych i przy zmianie schematu.
• Miej gotową liczbę dla skali. Wiersze dziennie, rozmiar, budżet opóźnienia. Podanie założonej skali jako pierwsze jest oceniane.
• Pisz SQL ręcznie. Etapy na żywo często używają zwykłego edytora bez autouzupełniania i bez wykonania.
• Przećwicz dobrze jedną historię incydentu. Co się zepsuło, jak to znalazłeś, co zmieniłeś, żeby się nie powtórzyło.

Data engineer z sześcioletnim doświadczeniem w pipeline'ach wsadowych przygotowywała się, przeglądając wewnętrzne mechanizmy frameworków, po czym utknęła na "źródło upstream ponownie wysłało wczorajszy plik", bo obsługiwała to tylko ręcznie, nigdy tego nie wyjaśniała. Wiedza była; mówiona odpowiedź nie. Ćwiczenie etapu projektowego z pytaniami uzupełniającymi to dokładnie to, do czego zbudowano tryb mock interview.