Pytania na rozmowę kwalifikacyjną na stanowisko Data Engineer — Ponad 30 pytań i eksperckie odpowiedzi

Stanowiska inżynierii danych wzrosły o ponad 60% od 2020 roku, czyniąc tę specjalizację jedną z najszybciej rozwijających się w branży technologicznej [1]. Mimo to, przy średnio 118 kandydatach na jedno stanowisko i 27% wskaźniku przejścia z rozmowy do zatrudnienia [2], rozmowy kwalifikacyjne pozostają wysoce konkurencyjne. Współczesne rozmowy na stanowisko data engineera wykraczają poza biegłość w SQL — testują zdolność projektowania skalowalnych potoków, modelowania danych do analityki, zarządzania jakością danych i operowania w środowiskach produkcyjnych z użyciem narzędzi takich jak Spark, Kafka, dbt i Airflow [3]. Poniższe pytania odzwierciedlają wzorce stosowane przez zespoły rekrutacyjne w firmach od startupów budujących pierwszy stos danych po przedsiębiorstwa zarządzające hurtowniami danych o skali petabajtów.

Kluczowe wnioski

• Rozmowy kwalifikacyjne na stanowisko data engineera obejmują SQL, Python, modelowanie danych, projektowanie potoków ETL/ELT i architekturę systemów [1].
• Należy oczekiwać zadań programistycznych w SQL i Pythonie obok sesji projektowania potoków na tablicy.
• Pytania behawioralne badają sposób radzenia sobie z incydentami jakości danych, komunikacją z interesariuszami i współpracą między zespołami.
• Coraz częściej oczekuje się znajomości narzędzi nowoczesnego stosu danych (dbt, Airflow, Spark, Kafka, Snowflake, Databricks).
• Wykazanie zrozumienia zarządzania danymi, liniażu i obserwowalności wyróżnia kandydatów na stanowiska seniorskie.

Pytania behawioralne

Data engineerowie funkcjonują na styku inżynierii i analityki, współpracując z data scientists, analitykami i zespołami produktowymi. Pytania behawioralne oceniają, jak nawiguje się te relacje w warunkach rzeczywistych ograniczeń [4].

1. Proszę opisać sytuację, w której zbudowany potok danych uległ awarii w produkcji. Jak zdiagnozowano i naprawiono problem?

Należy użyć STAR: Situation (codzienne zadanie ETL nie powiodło się o 3 w nocy, opóźniając poranny dashboard analityczny), Task (przywrócenie świeżości danych przed godzinami pracy), Action (sprawdzenie logów Airflow, zidentyfikowanie zmiany schematu w źródłowym API, która przerwała krok ekstrakcji, wdrożenie obsługi ewolucji schematu i dodanie alertów), Result (potok przywrócony w 90 minut, dodanie testów integracyjnych automatycznie wykrywających zmiany schematu).

2. Proszę opowiedzieć o sytuacji, w której nie zgadzano się z data scientist lub analitykiem co do modelowania danych. Jak rozwiązano problem?

Należy opisać kompromis — być może analityk chciał szeroką zdenormalizowaną tabelę dla wydajności zapytań, podczas gdy kandydat opowiadał się za znormalizowanym modelem wymiarowym dla łatwości utrzymania. Należy wyjaśnić, jak przetestowano oba podejścia z reprezentatywnymi zapytaniami i znaleziono kompromis (zmaterializowane widoki lub preaggregowane tabele), który spełnił obie potrzeby.

3. Proszę przeprowadzić przez sytuację, w której odziedziczono starszy potok danych i trzeba było zdecydować, czy go refaktoryzować, czy przebudować.

Należy ocenić kryteria decyzyjne: jakość dokumentacji, pokrycie testami, krytyczność biznesowa i koszt przestoju podczas migracji. Silne odpowiedzi pokazują systematyczną ocenę zamiast domyślnego „przepisz wszystko" lub „zostaw tak, jak jest."

4. Proszę opisać sytuację, w której wdrożono monitoring jakości danych, który wykrył problem, zanim dotarł do odbiorców downstream.

Należy omówić konkretne kontrole jakości danych: monitoring współczynnika null, SLA świeżości, wykrywanie anomalii liczby wierszy i walidacja schematu. Należy wymienić narzędzia takie jak Great Expectations, testy dbt lub Monte Carlo. Należy skwantyfikować wpływ — „wykryto 40% spadek liczby wierszy spowodowany zmianą w systemie źródłowym, który spowodowałby nieprawidłowe raporty przychodowe."

5. Proszę opowiedzieć o sytuacji, w której trzeba było wyjaśnić koncepcję inżynierii danych nietechnicznemu interesariuszowi.

Ujmowanie procesów ETL, opóźnień danych i zależności potoków w terminach biznesowych jest niezbędne. Należy opisać stosowanie analogii, dashboardów lub wskaźników świeżości danych, by uczynić stan potoków widocznym i zrozumiałym.

6. Jak radzono sobie z sytuacją, w której dane z systemu źródłowego były niewiarygodne lub niespójne?

Należy omówić wdrożenie walidacji na warstwie ingestion, tworzenie kontroli uzgodnień między źródłem a celem, dokumentowanie problemów jakości danych w katalogu danych i komunikowanie znanych ograniczeń użytkownikom downstream zamiast cichego propagowania wadliwych danych.

Pytania techniczne

Pytania techniczne testują głębię wiedzy w zakresie SQL, systemów rozproszonych, modelowania danych i architektury potoków [5].

1. Proszę wyjaśnić różnicę między ETL a ELT. Kiedy wybrałoby się każde podejście?

ETL (Extract, Transform, Load) transformuje dane przed załadowaniem do hurtowni — odpowiednie, gdy hurtownia ma ograniczoną moc obliczeniową lub gdy transformacje wymagają złożonej logiki biznesowej. ELT (Extract, Load, Transform) ładuje surowe dane najpierw i transformuje je w hurtowni — preferowane przy nowoczesnych kolumnowych hurtowniach (Snowflake, BigQuery, Redshift), które dysponują elastyczną mocą obliczeniową do transformacji [3]. Należy omówić, jak dbt stał się standardowym narzędziem dla „T" w ELT.

2. Proszę napisać zapytanie SQL znajdującą drugie najwyższe wynagrodzenie w każdym dziale.

Należy użyć funkcji okna: SELECT department, employee, salary FROM (SELECT department, employee, salary, DENSE_RANK() OVER (PARTITION BY department ORDER BY salary DESC) as rank FROM employees) ranked WHERE rank = 2. Należy omówić, dlaczego DENSE_RANK prawidłowo obsługuje remisy i dlaczego RANK lub ROW_NUMBER mogą dać inne wyniki.

3. Jak zaprojektowałoby się przyrostowy potok danych przetwarzający tylko zmienione rekordy z systemu źródłowego?

Należy omówić strategie Change Data Capture (CDC): przyrostowe ładowanie oparte na znacznikach czasowych (kolumny updated_at), CDC oparte na logach (Debezium czytający write-ahead logi bazy danych) i porównanie oparte na hashach. Należy odnieść się do wyzwań: spóźnione dane, usunięcia niewidoczne dla podejść opartych na znacznikach czasowych i gwarancje przetwarzania exactly-once [1].

4. Proszę wyjaśnić różnice między schematem gwiazdkowym a schematem płatka śniegu. Kiedy zastosowałoby się każdy?

Schemat gwiazdkowy ma centralną tabelę faktów połączoną ze zdenormalizowanymi tabelami wymiarów — prostsze zapytania, szybsze odczyty, idealne dla narzędzi BI. Schemat płatka śniegu normalizuje tabele wymiarów na podwymiary — redukuje redundancję pamięci, ale zwiększa złożoność zapytań. Schematy gwiazdkowe są preferowane dla obciążeń analitycznych, gdzie wydajność zapytań ma znaczenie; schematy płatka śniegu pasują do środowisk, gdzie priorytetem jest efektywność pamięci i integralność danych.

5. Czym Apache Kafka różni się od tradycyjnej kolejki komunikatów jak RabbitMQ i kiedy wybrałoby się Kafka dla potoku danych?

Kafka to rozproszona platforma strumieniowania zdarzeń z trwałymi, uporządkowanymi, odtwarzalnymi logami. RabbitMQ to broker komunikatów zoptymalizowany dla dostarczania punkt-punkt z semantyką potwierdzenia. Kafka należy wybrać dla strumieniowania zdarzeń o wysokiej przepustowości, agregacji logów i scenariuszy, w których wielu konsumentów musi niezależnie czytać te same dane (fan-out). RabbitMQ należy wybrać dla kolejek zadań ze złożonym routingiem i wymaganiami dostarczania exactly-once [5].

6. Czym jest partycjonowanie danych i jak poprawia wydajność zapytań w hurtowni danych?

Partycjonowanie dzieli duże tabele na segmenty oparte na kluczu (data, region, ID klienta). Zapytania filtrujące po kluczu partycji skanują tylko odpowiednie segmenty, redukując koszty I/O i obliczeń. Należy omówić strategie partycjonowania: partycjonowanie zakresowe dla danych szeregów czasowych, partycjonowanie hashowe dla równomiernej dystrybucji i znaczenie wyboru kluczy partycji dopasowanych do typowych wzorców zapytań.

7. Jak obsługuje się ewolucję schematu w potoku danych, gdy źródła upstream zmieniają format danych?

Należy wdrożyć rejestr schematów (Confluent Schema Registry dla Kafka lub ewolucja schematu Avro/Parquet). Zdefiniować reguły kompatybilności wstecznej i wprzód. Używać stref landing akceptujących surowe dane bez wymuszania schematu, następnie walidować i transformować w warstwach staging. Alertować o zmianach schematu i wdrożyć circuit breakery zatrzymujące przetwarzanie zamiast propagować uszkodzone dane [3].

Pytania sytuacyjne

Pytania sytuacyjne przedstawiają realistyczne wyzwania potoków, by ocenić podejście do rozwiązywania problemów [4].

1. Codzienny potok zajmuje 6 godzin, ale biznes potrzebuje odświeżania danych co 2 godziny. Jak podejść do tego problemu?

Należy przeanalizować, gdzie spędzany jest czas — ekstrakcja, transformacja czy ładowanie? Wdrożyć przetwarzanie przyrostowe zastępujące pełne przeładowania tabel. Zrównoleglić niezależne transformacje. Rozważyć przeniesienie ciężkich transformacji do hurtowni (ELT), by wykorzystać jej elastyczną moc obliczeniową. Jeśli SLA wymaga czasu zbliżonego do rzeczywistego, ocenić alternatywy strumieniowe dla najkrytyczniejszych tabel.

2. Data scientist raportuje nagły spadek dokładności modelu machine learning. Podejrzewa problem z jakością danych. Jak przeprowadza się dochodzenie?

Sprawdzić metadane potoku: czy ostatnie uruchomienie zakończyło się pomyślnie? Porównać liczbę wierszy, współczynniki null i rozkłady wartości z historycznymi bazami odniesienia. Sprawdzić zmiany w systemie źródłowym (modyfikacje schematu, aktualizacje reguł biznesowych). Użyć narzędzi liniażu danych, by prześledzić cechy wejściowe modelu do ich tabel źródłowych i zidentyfikować, gdzie wystąpiło przesunięcie rozkładu.

3. Projektuje się platformę danych dla startupu, który obecnie ma 10 GB danych, ale oczekuje 10 TB w ciągu 18 miesięcy. Jak zaprojektować architekturę na wzrost bez nadmiernej inżynierii?

Rozpocząć od zarządzanej hurtowni chmurowej (Snowflake, BigQuery) skalującej się elastycznie. Użyć dbt do transformacji, który skaluje się z mocą obliczeniową hurtowni. Wdrożyć orkiestrację z Airflow lub Dagster od początku — trudniej ją dodać później. Zaprojektować modele wymiarowe wspierające przyszłą ekspansję. Unikać przedwczesnej optymalizacji, jak klastry Spark, dopóki wolumen danych faktycznie tego nie wymaga.

4. Dwa różne zespoły potrzebują tych samych danych źródłowych, ale z różnymi transformacjami i wymaganiami świeżości. Jak uniknąć duplikacji potoków?

Wdrożyć współdzieloną architekturę medallion brązowa/srebrna/złota. Ingestionować surowe dane raz do warstwy brązowej, stosować wspólne oczyszczanie w warstwie srebrnej i pozwolić każdemu zespołowi budować własne transformacje warstwy złotej. Użyć katalogu danych do dokumentowania dostępnych zestawów danych i zapobiegania budowaniu redundantnych potoków ingestion przez zespoły.

5. Potok używa API z limitem 100 żądań na minutę, ale trzeba codziennie wyekstrahować 1 milion rekordów. Jak zaprojektować ekstrakcję?

Wdrożyć ograniczanie częstotliwości z wykładniczym wycofywaniem w kodzie ekstrakcji. Użyć paginacji z offsetami opartymi na kursorze dla przyrostowych pobrań. Zaplanować ekstrakcję poza godzinami szczytu, by zmaksymalizować przepustowość w ramach limitów. Cachować odpowiedzi API, by uniknąć ponownego pobierania niezmienionych danych. Jeśli API obsługuje endpointy eksportu zbiorczego, użyć ich zamiast pobierania rekord po rekordzie.

Pytania do rekrutera

Data engineerowie powinni ocenić dojrzałość platformy danych i kulturę inżynieryjną zespołu [1].

1. „Jak wygląda obecny stos danych — hurtownia, orkiestracja, transformacja i narzędzia obserwowalności?" — Ujawnia środowisko techniczne i stan modernizacji.
2. „Jak zarządzacie jakością danych obecnie i czy istnieje framework monitoringu jakości danych?" — Wskazuje dojrzałość zarządzania danymi.
3. „Jaki jest stosunek data engineerów do data scientists i analityków w zespole?" — Pokazuje, czy data engineerowie są zintegrowani z odbiorcami danych, czy odizolowani.
4. „Jak zespół obsługuje dyżury przy awariach potoków?" — Ocenia obciążenie operacyjne i oczekiwania co do work-life balance.
5. „Czy istnieje katalog danych lub narzędzie liniażu danych?" — Ujawnia praktyki odkrywalności i dokumentacji.
6. „Jakie jest największe wyzwanie inżynierii danych, z którym zespół się obecnie mierzy?" — Daje wgląd, czy rola odpowiada umiejętnościom i zainteresowaniom.

Format rozmowy i czego oczekiwać

Rozmowy kwalifikacyjne na stanowisko data engineera obejmują zazwyczaj cztery do pięciu rund oceniających zarówno umiejętności kodowania, jak i myślenie projektowe [3].

Screening rekruterski (30 minut): Rozmowa o doświadczeniu, oczekiwaniach płacowych i ogólnym tle technicznym.

Runda kodowania SQL (60 minut): Pisanie zapytań SQL we współdzielonym środowisku — funkcje okna, CTE, agregacje i joiny. Należy oczekiwać dyskusji o optymalizacji planów wykonania zapytań.

Runda Python / Programowanie (60 minut): Implementacja logiki przetwarzania danych — parsowanie plików, transformacja struktur danych lub budowa prostego komponentu potoku. Nacisk na czysty, testowalny kod.

Runda projektowania systemów (60-90 minut): Projektowanie potoku danych lub platformy danych end-to-end. Typowe zadania: zaprojektowanie systemu analityki czasu rzeczywistego, budowa data lake dla firmy wieloproduktowej lub architektura platformy danych opartej na zdarzeniach.

Runda behawioralna (45-60 minut): Pytania o współpracę, reagowanie na incydenty i komunikację z nietechnicznymi interesariuszami.

Jak się przygotować

Przygotowanie do rozmowy na stanowisko data engineera powinno łączyć ćwiczenia SQL, naukę projektowania potoków i wiedzę specyficzną dla narzędzi [5].

Opanować SQL: Ćwiczyć funkcje okna, CTE, self-joiny i optymalizację zapytań. Korzystać z platform takich jak zadania bazodanowe LeetCode, HackerRank SQL lub Stratascratch. Być w stanie pisać złożone zapytania bez IDE.

Studiować modelowanie danych: Rozumieć schematy gwiazdkowe, schematy płatka śniegu, wolno zmieniające się wymiary (Typ 1, 2, 3) i architekturę medallion (brązowa/srebrna/złota). Być gotowym do projektowania modelu wymiarowego na tablicy.

Znać swoje narzędzia: Być przygotowanym do dyskusji o narzędziach wymienionych w opisie stanowiska. Dla Spark: rozumieć RDD vs. DataFrames, partycjonowanie i operacje shuffle. Dla Airflow: rozumieć DAGs, operatory, sensory i XComs. Dla dbt: rozumieć modele, testy, makra i przyrostowe materializacje.

Ćwiczyć projektowanie potoków: Przejść przez pięć projektów potoków end-to-end: batch ETL, strumieniowanie czasu rzeczywistego, replikacja oparta na CDC, ekstrakcja oparta na API i migracja hurtowni danych. Dla każdego zidentyfikować narzędzia, tryby awarii i strategię monitoringu.

Przygotować historie o jakości danych: Mieć konkretne przykłady problemów jakości danych, które się odkryło, zbadało i rozwiązało. Skwantyfikować biznesowy wpływ wykrycia (lub przeoczenia) tych problemów.

Powtórzyć koncepcje systemów rozproszonych: Rozumieć partycjonowanie, replikację, modele spójności i twierdzenie CAP w kontekście systemów danych. Książki takie jak Designing Data-Intensive Applications Martina Kleppmann'a stanowią bezcenne przygotowanie.

Typowe błędy na rozmowie

Należy unikać tych pułapek, które często dyskwalifikują kandydatów na stanowisko data engineera [4].

1. Pisanie poprawnego, ale niezoptymalizowanego SQL. Zapytanie dające prawidłowy wynik, ale niepotrzebnie skanujące całą tabelę, sygnalizuje brak świadomości produkcyjnej. Zawsze należy omawiać indeksowanie, partycjonowanie i plany wykonania.

2. Ignorowanie jakości danych w projektach potoków. Potok bez walidacji, monitoringu i alertów jest niekompletny. Zawsze należy uwzględniać kontrole jakości danych w odpowiedziach o projektowaniu systemów.

3. Nadmierna inżynieria dla skali, której się nie posiada. Proponowanie Kafki i Spark dla dziennego obciążenia 10 GB jest takim samym błędem jak stosowanie prostych skryptów dla dziennego obciążenia 10 TB. Architekturę należy dopasować do rzeczywistego wolumenu danych i trajektorii wzrostu.

4. Niezrozumienie kontekstu biznesowego. Potoki danych służą decyzjom biznesowym. Kandydaci projektujący technicznie solidne, ale biznesowo nieistotne rozwiązania mijają się z celem. Należy zadawać pytania wyjaśniające, kto konsumuje dane i jakie decyzje napędza.

5. Traktowanie przetwarzania wsadowego i strumieniowego jako wymiennych. Każde ma odmienne kompromisy pod względem złożoności, kosztu i opóźnienia. Należy jasno określić, kiedy każde podejście jest odpowiednie i jakie są operacyjne implikacje wyboru jednego z nich.

6. Zaniedbywanie kwestii operacyjnych. Monitoring potoków, alerty, logika ponawiania, kolejki martwych listów i procedury backfill nie są opcjonalne — to właśnie one czynią potok gotowym do produkcji [3].

Kluczowe wnioski

Rozmowy na stanowisko data engineera oceniają zdolność projektowania, budowania i operowania systemami danych dostarczającymi wiarygodne, terminowe dane osobom, które ich potrzebują. Należy przygotować się opanowując SQL, rozumiejąc narzędzia nowoczesnego stosu danych i ćwicząc projektowanie potoków end-to-end. Wyróżniają się kandydaci, którzy myślą o jakości danych, odporności operacyjnej i wpływie biznesowym — nie tylko o scenariuszu optymistycznym.

Chcesz mieć pewność, że CV eksponuje właściwe umiejętności inżynierii danych? Wypróbuj darmowy checker wyniku ATS od ResumeGeni, by zoptymalizować CV data engineera przed aplikacją.

Często zadawane pytania

Jakie języki programowania trzeba znać na rozmowę na stanowisko data engineera? SQL jest niezbędny. Python jest oczekiwany w większości ról. Scala jest wartościowy w środowiskach intensywnie wykorzystujących Spark. Java pojawia się w niektórych środowiskach korporacyjnych [5].

Jak ważne jest doświadczenie z chmurą na rozmowach z inżynierii danych? Bardzo ważne. Większość nowoczesnych ról inżynierii danych wymaga doświadczenia z co najmniej jedną platformą chmurową (AWS, GCP lub Azure) i natywnymi usługami danych w chmurze (Redshift, BigQuery, Snowflake, Databricks) [1].

Czy rozmowy na stanowisko data engineera obejmują kodowanie na żywo? Tak. Należy oczekiwać co najmniej jednej rundy kodowania SQL na żywo i często rundy kodowania Python skoncentrowanej na logice transformacji danych [3].

Jakie jest najczęstsze pytanie o projektowanie systemów dla data engineerów? Projektowanie wsadowego potoku danych z przetwarzaniem przyrostowym lub projektowanie systemu strumieniowania zdarzeń w czasie rzeczywistym to dwa najczęstsze zadania.

Jak przygotować się do rund projektowania systemów, jeśli pracowało się tylko nad istniejącymi potokami? Studiować architektury open-source, czytać posty na blogach inżynieryjnych firm takich jak Netflix, Uber i Airbnb i ćwiczyć wyjaśnianie decyzji projektowych na głos. Kluczową umiejętnością jest artykułowanie kompromisów, nie zapamiętywanie architektur.

Czy należy nauczyć się dbt na rozmowy z inżynierii danych? Tak — dbt stał się standardowym narzędziem w nowoczesnym stosie danych. Zrozumienie modeli, testów i przyrostowych materializacji jest oczekiwane w większości ról analytics engineering i inżynierii danych [5].

Jakie certyfikaty pomagają na rozmowach z inżynierii danych? Certyfikaty chmurowe (AWS Data Analytics Specialty, GCP Professional Data Engineer, Azure Data Engineer Associate) demonstrują wiedzę specyficzną dla platformy i są cenione przez wielu pracodawców.