Interview T-Mobile - Data Engineer

1

🟢 Ľahká

0 / 4 body

Predstav si, že máš tabuľku `customers` v transakčnom systéme. Zákazník zmení email adresu. Ako by si to riešil v klasickej relačnej DB vs v Data Vault? Aký je hlavný rozdiel?

Klasická DB: UPDATE na existujúcom riadku - pôvodná hodnota sa stratí (alebo SCD Type 2 duplikuje celý riadok)

Data Vault prístup: Hub zostáva nezmenený (immutable), pridá sa nový riadok do Satellite s novým emailom

Výhoda: V Data Vault pôvodný email zostáva zachovaný, máš plnú históriu zmien, lepšia auditovateľnosť

Praktické použitie: Vieš zodpovedať "Aký email mal zákazník 1.1.2024?" - v klasickej DB už nevieš, v Data Vault áno

2

🟢 Ľahká

0 / 4 body

Máš dbt projekt s 50+ modelmi a build trvá 2 hodiny. Business chce aktualizovať len jeden report každú hodinu. Ako by si to optimalizoval?

Selective run: Použiť `dbt run --select report_name+` (model + všetky jeho dependencies), nie plný build

Incremental models: Zmeniť modely na incremental (materialized='incremental'), spracovať len nové/zmenené dáta

Tags/groups: Použiť tagy (dbt run --select tag:hourly) alebo groups pre organizáciu modelov podľa refresh frequency

Scheduling: Rozdeliť na viac jobov v orchestrátore (Airflow) - kritické modely častejšie, menej dôležité zriedkavejšie

3

🟡 Stredná

0 / 5 bodov

Potrebuješ integrovať dáta z API, ktoré má rate limit 100 requestov/minútu a máš 50 000 produktov na update. Ako by si to navrhol v dbt/Python pipeline?

Batch processing: Rozdeliť na batch-e po 100 produktoch, sleep medzi batch-ami (60 sekúnd), celkový čas ~8.5 hodín

Incremental approach: Načítať len changed produkty (delta load) - identifikovať pomocou last_modified_date alebo hash comparison

Staging layer: Prvý krok: Python script stiahne API dáta do staging table/file, druhý krok: dbt spracuje staging → raw vault

Error handling: Retry mechanism s exponential backoff, logovanie failed requests, queue pre retry (dead letter queue)

Optimalizácia: Využiť bulk endpoints ak API podporuje (namiesto 1 request = 1 produkt), alebo paralelizovaťs viacerými API keys

4

🟡 Stredná

0 / 5 bodov

V Data Vault máš 3 satellites na produkt z rôznych zdrojov (ERP, E-shop, CRM). Business chce jeden unified view. Ako vytvoríš "Golden Record" a ako rozhodneš, ktorému zdroju dôverovať pri konfliktoch?

Business Vault view: Vytvoriť view/table joinujúci všetky 3 satellites, každý atribút má definovaného "source of truth" (napr. cena z E-shop, kategória z ERP)

Priority rules: Definovať hierarchiu zdrojov pre každý atribút pomocou COALESCE (napr. COALESCE(eshop.price, erp.price, crm.price))

Metadata tracking: Pridať stĺpce source_system, last_updated_date pre každý atribút, aby user vedel odkiaľ hodnota pochádza

Conflict detection: Flagovať produkty s konfliktmi (napr. rozdielne názvy v ERP vs E-shop), vytvoriť monitoring report pre business

Business rules: Implementovať validácie (napr. e-shop cena nesmie byť > 120% ERP base price), flagovať anomálie

5

🟡 Stredná

0 / 5 bodov

dbt test zlyháva na production, ale na dev prostredí prechádza. Ako by si debugoval tento problém a aké sú možné príčiny?

Rozdielne dáta: Production má viac/iné dáta ako dev (edge cases, ktoré dev nemá), skontrolovať row counts a sample dát

Timing issues: Na production bežia testy skôr než sa dokončí load (race condition), riešiť pomocou dependencies/waits v orchestrátore

Environment config: Rozdielne schema, permissions, alebo dbt profiles.yml nastavenia medzi dev a prod

Debug stratégia: Použiť `dbt test --store-failures` na prod, pozrieť failed rows, porovnať s dev dátami, reprodukovať lokálne

Test design: Test môže byť príliš striktný alebo nezohľadňovať business rules (napr. test na unique, ale business povoluje duplikáty v určitých prípadoch)

6

🔴 Ťažká

0 / 6 bodov

Business potrebuje report "Customer 360" - všetky info o zákazníkovi (profile, orders, payments, support tickets) z posledných 3 rokov. V Data Vault to vyžaduje 8+ JOINov a query trvá 5 minút. Ako by si to optimalizoval na < 10 sekúnd?

Point-in-Time (PIT) table: Pre-compute daily snapshoty všetkých satellites pre zákazníka, redukuje JOINy z 8 na 1-2

Bridge table: Materialized table s pre-joined hubmi a linkami (customer → orders → products), refresh denne cez dbt

Agregácie: Pre-compute metriky (total_orders, lifetime_value, avg_ticket_size) do summary table, nemusíš to počítať on-the-fly

Partitioning/Clustering: PARTITION BY customer_hk a year, CLUSTER BY (customer_hk, load_date), skenuje len relevantné partitions

Materialized view: Vytvoriť customer_360 ako materialized view/table, incrementálne update len changed customers

Caching layer: Pre často pristupovaných zákazníkov použiť Redis/memcached cache, alebo query result cache v DWH

7

🔴 Ťažká

0 / 6 bodov

Zistíš, že za posledných 6 mesiacov sa do Data Vault nahrávali duplicitné záznamy kvôli bug-u v ETL. Teraz máš v hub_customer duplikáty (rovnaký customer_id s rôznymi hash). Ako by si to vyčistil bez straty dát a histórie?

Analýza rozsahu: Najprv identifikovať všetky duplicate páry, počet ovplyvnených zákazníkov, satellites a links, ktoré ukazujú na duplicate hashes

Merge stratégia: Určiť "master" hash (najstarší load_date alebo najviac satellites), všetky ostatné duplikáty sú "slave" hashes

Satellite migration: UPDATE/INSERT satellites - zmeniť customer_hk z "slave" na "master", zachovať load_date a record_source (append, nie overwrite)

Link update: UPDATE linky - nahradiť "slave" hash za "master" hash v customer_hk FK, zachovať link_hk integritu

Audit trail: Vytvoriť audit table zaznamenávajúcu merge (old_hash, new_hash, merge_date, reason), soft-delete duplicate hubov (nie hard delete)

Prevention: Pridať dbt test unique na (customer_id) v staging, constraint na hub level, monitoring pre future duplicates

8

🔴 Ťažká

0 / 6 bodov

Potrebuješ implementovať GDPR "right to be forgotten" v Data Vault architektúre. Zákazník žiada vymazanie všetkých osobných údajov. Ako to urobíš bez porušenia Data Vault principov (never delete)?

Pseudonymization approach: Nahradiť PII v satellites anonymizovanými hodnotami (email → hashed_email, name → "REDACTED"), zachovať štruktúru

Separate PII satellites: Dizajn: Oddeliť PII do vlastných satellites (sat_customer_pii), non-PII ostávajú (sat_customer_metadata), delete len PII satellites

Deletion satellite: Pridať nový satellite row s flagom is_deleted=true a anonymizovanými dátami, Business Vault views filtrujú deleted records

Encryption/Tokenization: PII uložené encrypted s customer-specific key, pri GDPR request zmazať encryption key - data ostávajú ale sú nečitateľné

Audit a compliance: Logovať všetky GDPR requests a actions, retention policy pre audit logs (napr. 7 rokov), dokázať compliance pre regulátory

Hub integrity: Hub zostáva (obsahuje len hash), všetky FK v linkoch fungujú, analytika na non-PII dátach možná (agregáty, trendy)

🎯 Interview T-Mobile

👤 Informácie o kandidátovi

📊 Celkové Skóre

📋 Interview Report - T-Mobile Data Engineer