Întrebări de Interviu pentru Data Engineer, pe Etape

Poate te pregătești la fel ca pentru un interviu de software engineering și te întrebi ce e diferit. Această secțiune mapează etapele pe care aceste interviuri le refolosesc, ca să-ți poți petrece timpul pe cele două etape care chiar separă candidații. Filtrul tehnic este rareori locul unde se pierd ofertele.

• SQL. Funcții window, deduplicare și performanța interogărilor, de obicei live.
• Modelare a datelor. Proiectarea tabelelor pentru o afacere descrisă și apărarea grain-ului ales.
• Design de pipeline și ETL. O etapă deschisă de system design axată pe mișcarea datelor.
• Procesare distribuită. Cum execută de fapt un framework job-ul tău și de ce e lent.
• Programare. Python sau Scala, adesea mai ușoară decât o etapă de software engineering.
• Comportamental. Incidente de gardă, dashboard-uri stricate și stakeholderi care voiau cifra ieri.

Titlurile se suprapun mult cu analytics engineering și rolurile de platform, deci mixul variază. Băncile de întrebări pentru roluri conexe se află în hub-ul întrebări de interviu pe rol.

SQL

• Deduplică un tabel păstrând doar cel mai recent rând pentru fiecare cheie.
• Scrie o interogare care returnează numărul de sesiuni ale fiecărui utilizator folosind un interval de inactivitate de 30 de minute.
• Calculează un total cumulativ și o variație lună la lună într-o singură interogare.
• Găsește rândurile prezente în snapshot-ul de ieri dar lipsă din cel de azi.
• Ce face QUALIFY, și ce ai scrie fără el?
• Această interogare scanează un miliard de rânduri și durează douăzeci de minute. Cum o diagnostichezi?
• Explică diferența dintre partitioning și clustering, și când ajută fiecare.

Modelare a datelor

• Proiectează tabelele pentru istoricul comenzilor unui marketplace online. Care e grain-ul fact table-ului tău?
• Explică un star schema, și când ai denormaliza deliberat mai departe.
• Ce este o slowly changing dimension, și cum implementezi tipul doi?
• Un stakeholder vrea ca raportarea istorică să reflecte regiunea actuală a unui client. Ce se strică?
• Cum ai modela un flux de evenimente care sosește dezordonat?
• Când ai alege un tabel larg în locul unui model normalizat?

Etapa de modelare recompensează angajarea într-un grain și apărarea lui. Candidații care descriu trei design-uri posibile fără să aleagă unul obțin scoruri mai mici decât candidații care aleg un design rezonabil și îi numesc slăbiciunea.

Design de pipeline și ETL

• Proiectează un pipeline care încarcă tranzacțiile zilnice într-un warehouse pentru raportare.
• Sursa upstream retrimite datele de ieri. Ce se întâmplă cu job-ul tău?
• Cum faci un pipeline idempotent, și de ce contează pentru rerulări?
• Cum ai face backfill la doi ani de istoric fără a perturba încărcarea zilnică?
• Date întârziate apar la trei zile după închiderea partiției. Ce faci?
• Cum detectezi că un pipeline a reușit dar a produs date greșite?
• Ce monitorizezi, și ce trezește pe cineva la ora trei dimineața?

Procesare distribuită și streaming

• Ce cauzează un shuffle, și de ce e costisitor?
• Job-ul tău e lent și un task durează mult mai mult decât restul. Ce se întâmplă?
• Explică data skew și două moduri de a-l gestiona.
• Când ai alege streaming în locul unui job batch programat?
• Ce garantează de fapt exactly once processing, și unde nu se aplică?
• Cum gestionează watermark-urile evenimentele dezordonate într-o agregare windowed?

Observă cât de puține din aceste întrebări îți cer să numești o unealtă. A numi una e începutul răspunsului, nu răspunsul. Întrebarea de follow-up e mereu de ce, și ce se strică.

Citirea acestor liste creează recunoaștere. Etapele de design testează altceva: să ții un sistem în minte în timp ce cineva te întrerupe cu un scenariu de eșec. Asta vine doar din a spune design-urile cu voce tare.

• Desenează și narează un pipeline în cincisprezece minute. Sursă, landing, transformare, serve, plus cum eșuează fiecare etapă.
• Atacă propriul design. După fiecare sesiune de practică, întreabă-te ce se întâmplă la o rerulare, la date întârziate, și la o schimbare de schemă.
• Ai pregătit un număr pentru scală. Rânduri pe zi, dimensiune, buget de latență. Menționarea scalei presupuse mai întâi este notată.
• Scrie SQL de mână. Etapele live folosesc adesea un editor simplu, fără autocomplete și fără execuție.
• Exersează bine o poveste de incident. Ce s-a stricat, cum ai găsit-o, ce ai schimbat ca să nu se repete.

O data engineer cu șase ani pe pipeline-uri batch s-a pregătit revizuind internele framework-urilor, apoi s-a blocat pe "sursa upstream a retrimis fișierul de ieri" pentru că îl gestionase mereu manual, niciodată nu îl explicase. Cunoștințele erau acolo; răspunsul vorbit nu. Exersarea etapei de design cu follow-up-uri este exact pentru ce este construit modul mock interview.