Czego szukamy w Senior Data Engineerze

Data Engineering w 2026 roku to dyscyplina znacznie szersza niż „ETL z PL/SQL” — to projektowanie i utrzymywanie pipeline’ów przetwarzających terabajty dziennie, modelowanie hurtowni i lakehouse’ów, zarządzanie jakością danych, orkiestracja, observability oraz pomost między analityką a produkcją (analytics engineering + ML platform). Senior Data Engineer musi czuć się swobodnie zarówno w warstwie batch (Apache Spark, dbt, Airflow), jak i streamingu (Apache Kafka, Flink, Spark Structured Streaming), znać nowoczesne formaty (Apache Iceberg, Delta Lake, Hudi), platformy chmurowe (Snowflake, BigQuery, Databricks, Redshift) oraz fundamenty modelowania (Kimball, Inmon, Data Vault 2.0). W ARDURA Consulting weryfikujemy kandydatów dla projektów obejmujących migracje hurtowni, budowę lakehouse, real-time analytics, GDPR-compliant pipeline’y oraz dostarczanie danych do zespołów ML.

Dobry Senior DE powinien znać: Python na poziomie produkcyjnym (typowanie, testowanie, async dla I/O); SQL na poziomie window functions, CTE rekurencyjne, query plan tuning; Apache Spark (DataFrame API, Spark SQL, Catalyst optimizer, partycjonowanie, salting, broadcast joins, AQE); Kafka (topics, partitions, consumer groups, exactly-once semantics, Schema Registry); orkiestrację (Airflow, Dagster, Prefect); transformacje (dbt — modele, testy, snapshots, exposures); warstwy storage (Delta Lake, Apache Iceberg z time travel, branching, ACID); query engines (Trino/Presto, ClickHouse dla OLAP); bazy operacyjne (PostgreSQL, MongoDB, Cassandra dla wide-column); data quality (Great Expectations, Soda Core, dbt tests). W tym przewodniku znajdziesz pytania, zadania i red flags.

Top 15 pytań rekrutacyjnych (z odpowiedziami)

1. Czym różni się ETL od ELT i kiedy wybrać które? ETL transformuje dane przed załadowaniem do hurtowni — historyczne podejście, sens gdy storage jest drogi a compute tani lub gdy hurtownia ma ograniczoną moc obliczeniową. ELT ładuje surowe dane do hurtowni i transformuje w niej — nowoczesne podejście umożliwione przez tanie storage chmurowe i potężne compute (Snowflake, BigQuery). ELT umożliwia raw data preservation, łatwiejsze debugowanie, time travel. Senior wskaże, że dziś standardem jest ELT z dbt jako warstwą transformacji.

2. Wyjaśnij modelowanie Kimball, Inmon i Data Vault. Kiedy które? Kimball (star/snowflake schema, fact + dimension tables) — szybkie dostarczenie danych do BI, intuicyjne dla analityków, łatwe agregacje. Inmon (3NF, EDW jako “single source of truth”, potem data marts) — większa spójność, trudniejszy w użytkowaniu. Data Vault 2.0 (Hubs, Links, Satellites) — auditability, historyzacja, łatwy do skalowania w dużych organizacjach z wieloma źródłami. Senior wskaże, że Kimball w warstwie marts + Vault w warstwie raw to częsta hybryda.

3. Jak optymalizujesz wolnego Spark joba? Profilowanie najpierw: Spark UI (stages, tasks, skewed partitions, shuffle read/write). Najczęstsze problemy: data skew (rozwiązanie: salting, broadcast hint dla małego tablu, AQE skew join), zbyt mała/duża liczba partycji (repartition, coalesce), niewłaściwy join (broadcast vs shuffle, sort-merge vs broadcast), brak partycjonowania na storage (Parquet partition columns), niewykorzystane Predicate Pushdown, slow UDFs (preferuj built-in functions lub Pandas UDFs). Senior wspomni o Adaptive Query Execution (AQE) jako defaultu od Spark 3 i o Dynamic Partition Pruning.

4. Co to Delta Lake, Apache Iceberg, Apache Hudi i czym się różnią? To formaty tabel oparte o Parquet, dodające ACID, time travel, schema evolution, upserty. Delta Lake — najbardziej dojrzały, mocno powiązany z Databricks, świetne wsparcie Spark. Iceberg — open i agnostyczny vendorowo, hidden partitioning, branching/tagging, wsparcie wielu engine’ów (Spark, Trino, Flink). Hudi — najlepszy do streaming upsertów, copy-on-write vs merge-on-read. Senior wskaże Iceberg jako trend 2026 (Snowflake, BigQuery, Databricks wszystkie wspierają natywnie) i wyjaśni różnicę CoW vs MoR.

5. Wyjaśnij Apache Kafka. Co to topic, partition, consumer group? Topic — kategoria wiadomości. Partition — pod-strumień topica, gwarantuje uporządkowanie wewnątrz partycji, umożliwia paralelizm. Consumer group — zestaw konsumentów dzielący się partycjami (każda partycja czytana przez dokładnie jednego consumer’a w grupie). Senior wyjaśni replikację (replication factor, in-sync replicas), exactly-once semantics (idempotent producer + transactions), Schema Registry (Avro/Protobuf evolution) i kompromisy między latency a throughput.

6. Jak realizujesz CDC (Change Data Capture)? Trzy podejścia: (1) trigger-based — triggery w bazie zapisują zmiany do tabeli audytowej; mało wydajne, inwazyjne; (2) timestamp/version — query po updated_at; gubi delete’y i hard-overwrites; (3) log-based (Debezium, AWS DMS) — czyta WAL/binlog bazy źródłowej, najwydajniejsze i kompletne. Standard: Debezium → Kafka → konsumenci. Senior wskaże komplikacje: schema drift, snapshot vs streaming, tombstones dla delete, ordering w przypadku multi-table transactions.

7. Co to slowly changing dimensions (SCD)? Wyjaśnij typy. SCD obsługują zmiany w wymiarach. Type 0 — nie zmieniamy (historical). Type 1 — overwrite, brak historii. Type 2 — nowy wiersz dla każdej zmiany z effective_from/effective_to + flagą is_current (najczęściej używany). Type 3 — kolumna previous_value (rzadko). Type 4 — historia w osobnej tabeli. Type 6 — hybryda 1+2+3. Senior wskaże, że dbt snapshots implementują SCD2 natywnie.

8. Jak projektujesz pipeline dla 100GB plików dziennie? Pytanie kontekstowe — Senior pyta o detale: format źródłowy (CSV? JSON? Parquet?), latency wymóg (godzinny? godziny dziennie?), schema stability, downstream konsumenci, SLA, koszty. Następnie projektuje: landing zone (S3/GCS/ADLS raw), processing (Spark batch lub Spark Structured Streaming), storage warstwy bronze/silver/gold (medallion), partycjonowanie po dacie, orkiestrację (Airflow), monitoring jakości (Great Expectations / dbt tests), alerting (PagerDuty/Slack). Wspomni o idempotency, replayability, backfill strategy.

9. dbt — co i jak? dbt to narzędzie do transformacji w hurtowni (T w ELT). Modele to SELECT w SQL z Jinja, materializowane jako view/table/incremental/ephemeral. Testy (unique, not_null, accepted_values, relationships + custom). Snapshots (SCD2). Macros (DRY). Documentation (dbt docs). Senior wspomni o incremental models z is_incremental() dla pipeline’ów >100M wierszy, o exposure’ach jako warstwie lineage do BI, o tym, że dbt nie zastępuje orkiestratora (potrzebny Airflow/Dagster do schedulowania).

10. Airflow vs Dagster vs Prefect — co wybierasz? Airflow — standard de facto, ogromny ekosystem, ale paradygmat task-centric utrudnia testowanie i wersjonowanie danych. Dagster — asset-centric (definiujesz dane, nie zadania), świetna observability, natywny lineage, lepiej integruje się z dbt. Prefect — DX, dynamic workflows, łatwiejszy start, ale mniejsze adopcja enterprise. Senior nie ma dogmatu — dla większości projektów greenfield wybiera Dagster, dla istniejącej infrastruktury Airflow.

11. Snowflake vs BigQuery vs Redshift vs Databricks — przeprowadź porównanie. Snowflake — separacja storage i compute (virtual warehouses), świetna concurrency, multi-cluster, cross-region replication. BigQuery — serverless, pay-per-query, świetna integracja z GA4/GCP, BI Engine. Redshift — natywne AWS, ekosystem, dziś znacznie lepszy niż 5 lat temu (Spectrum, RA3). Databricks — Lakehouse, najlepszy dla DE+DS+ML w jednym, Photon engine. Senior wybiera pod profil obciążenia: ML-heavy → Databricks, BI-heavy → Snowflake/BigQuery, AWS-only org → Redshift.

12. Data quality — Great Expectations vs Soda vs dbt tests? dbt tests — najprostsze, deklaratywne, w SQL, runują się z dbt buildem; OK dla unique/not_null/relationship. Great Expectations — bogaty katalog “expectations”, suites, docs (data docs), checkpointing; profilowanie. Soda Core — DSL SodaCL, mocne ad-hoc dla data engineerów, observability. Senior wskaże dbt tests dla warstwy modelowej + Great Expectations/Soda dla landing zone i metric layer.

13. Trino/Presto i ClickHouse — kiedy używasz? Trino — federated query engine, query across multiple sources (S3 Iceberg + PostgreSQL + Kafka) bez ETL. Sens dla ad-hoc analityki i prototypów. ClickHouse — OLAP columnar database, sub-second latency na miliardach wierszy, mat. views, świetny dla real-time dashboardów i product analytics (Posthog, Plausible). Senior wskaże ich miejsca w stacku obok hurtowni głównej.

14. Co to data lineage i dlaczego jest ważny? Lineage to mapa pochodzenia danych: które źródła zasilają które modele, które modele zasilają które dashboardy. Krytyczny dla impact analysis (jak zmiana w źródle wpłynie na BI), debugowania, compliance (GDPR — gdzie są dane osobowe), troubleshooting. Narzędzia: dbt docs (column-level), OpenLineage standard, DataHub, Atlan, Marquez. Senior wskaże, że bez lineage data team szybko traci kontrolę nad pipeline’em.

15. Opowiedz o najtrudniejszym pipeline’u, który zbudowałeś. Pytanie behawioralne. Słuchamy: rozumienie problemu biznesowego, kompromisy architektoniczne (np. batch vs streaming, koszt vs latency), idempotency, error handling, backfill strategy, monitoring, lessons learned. Red flag: kandydat opowiada o pipelinie który „po prostu zadziałał” bez incydentów — albo był prosty, albo nie debugował produkcji.

Zadania techniczne — 3 scenariusze

Scenariusz 1: Live coding (60 min) — Spark transformacja + dbt model Kandydat dostaje dataset (np. 50M wierszy zdarzeń e-commerce w Parquet) i ma napisać PySpark joba, który: filtruje po dacie, joinuje z tabelą produktów (broadcast hint dla małej tabeli), agreguje GMV per kategoria per dzień, zapisuje wynik partycjonowany po dacie do Delta/Iceberg. Następnie: napisać dbt model incremental, który dla tych danych liczy 7-dniowy rolling average GMV, dodać dwa testy (not_null, relationship), uruchomić dbt build. Patrzymy na: idiomatyczne API Sparka, świadomość partycjonowania, broadcast join, użycie is_incremental() i {{ this }} w dbt, dodawanie testów bez proszenia. Red flag: collect() na dużym DataFrame, brak partycjonowania.

Scenariusz 2: System design (45 min) — real-time dashboard fraudów Kandydat projektuje pipeline: 1M transakcji/min napływa z systemu płatności, dashboard ma pokazywać transakcje podejrzane (rules + ML model) z latency <30s end-to-end, historia 90 dni dostępna do ad-hoc analizy, audit log dla compliance, GDPR (możliwość usunięcia danych klienta). Oczekujemy diagramu: ingestion (Kafka z partycjonowaniem po klientI’d dla ordering), stream processing (Flink albo Spark Structured Streaming z exactly-once), feature store, model serving (low-latency, Redis cache), storage (ClickHouse dla dashboardu real-time + Iceberg dla historii), orkiestracja, monitoring. Pytamy: jak skalować Kafka, jak obsłużyć late data, jak idempotency, jak GDPR right-to-be-forgotten przy immutable storage (separate PII table, tombstones).

Scenariusz 3: Code review (30 min) — SQL/dbt model z bugami Pokazujemy dbt model ~100 linii SQL z ukrytymi problemami: (1) brak DISTINCT w CTE z duplikatami (cardinality blow-up po join), (2) LEFT JOIN który powinien być INNER (NULLE psują agregację), (3) GROUP BY na kolumnach bez aliasów (kruchość, błędna agregacja po dodaniu kolumny), (4) window function bez PARTITION BY (kalkulacja globalna zamiast per klient), (5) timezone bug (UTC vs lokalny czas serwera w date_trunc), (6) brak is_incremental() mimo materialization=‘incremental’ (full refresh za każdym razem), (7) hardkodowany schemat zamiast {{ ref() }} (zepsuty lineage), (8) brak testów. Senior znajduje 6-8 z 8.

Red flags i deal-breakers

Kandydat deklaruje 5+ lat DE, ale używa Pythona jak Bash (skrypty bez funkcji, bez testów, bez typowania) — alarm. Brak znajomości window functions w SQL — fundament dyscypliny, nie da się być Senior bez tego. Spark wyłącznie z poziomu „df.toPandas()” — kompletne niezrozumienie distributed compute. Brak rozumienia partycjonowania i shuffle — Spark joby będą wieczne. Mówienie o ETL bez wspomnienia o idempotency i replayability — sygnał, że nigdy nie debugował produkcji. Brak doświadczenia z testami danych (dbt tests, GE, Soda) — w 2026 to nie opcja. Brak wiedzy o cost optimization (BigQuery slot reservations, Snowflake warehouse sizing, Spark cluster sizing) — przy enterprise to dyskwalifikacja, bo Senior odpowiada też za rachunek. Brak pytań o source data, SLA, downstream konsumentów, monitoring, on-call rotation — sygnał słabego zaangażowania.

Jak ARDURA Consulting weryfikuje kandydatów

W ARDURA Consulting prowadzimy 3-etapowy proces weryfikacji Senior Data Engineerów w 5 dni roboczych. Etap 1 (dzień 1) — screening CV + 30-minutowa rozmowa techniczna z lead data engineerem, podczas której zadajemy 8-10 pytań z listy powyżej, weryfikujemy znajomość Pythona, SQL, Sparka, dbt i historii projektów. Etap 2 (dni 2-3) — zadanie techniczne live (90 minut): PySpark + dbt live coding + system design (real-time pipeline lub batch warehousing) + code review SQL/dbt z bugami. Etap 3 (dzień 4) — rozmowa z naszym CTO o doświadczeniu projektowym (skala danych, stack, on-call, koszty, compliance), dopasowaniu kulturowym, oczekiwaniach finansowych i dostępności. Dzień 5 — finalna decyzja i przekazanie kandydata klientowi z pełnym raportem (mocne strony, ryzyka, rekomendacja seniority). Korzystamy z bazy 500+ zweryfikowanych seniorów, 99% retencji i średnio 2 tygodnie do wdrożenia w projekt klienta. Sprawdź dostępnych ekspertów →