Intervjufrågor för Data Engineer, per Omgång

Du kanske förbereder dig på samma sätt som för en software engineering-process och undrar vad som skiljer sig. Det här avsnittet kartlägger omgångarna som dessa intervjuer återanvänder, så att du kan lägga tiden på de två som faktiskt skiljer kandidater åt. Det tekniska filtret är sällan där erbjudanden går förlorade.

• SQL. Window functions, deduplicering och frågeprestanda, oftast live.
• Datamodellering. Designa tabeller för ett beskrivet företag och försvara den grain du valt.
• Pipeline- och ETL-design. En öppen systemdesignomgång inriktad på dataflyttning.
• Distribuerad bearbetning. Hur ett framework faktiskt kör ditt jobb, och varför det är långsamt.
• Kodning. Python eller Scala, ofta lättare än en software engineering-omgång.
• Beteende. Jourincidenter, trasiga dashboards och intressenter som ville ha siffran igår.

Titlar överlappar mycket med analytics engineering och platform-roller, så mixen skiftar. Relaterade frågebanker per roll finns i navet intervjufrågor per roll.

SQL

• Deduplicera en tabell så att bara den senaste raden per nyckel behålls.
• Skriv en fråga som returnerar varje användares sessionsantal med ett inaktivitetsgap på 30 minuter.
• Beräkna en löpande summa och en förändring månad över månad i en enda fråga.
• Hitta rader som finns i gårdagens snapshot men saknas i dagens.
• Vad gör QUALIFY, och vad skulle du skriva utan det?
• Den här frågan skannar en miljard rader och tar tjugo minuter. Hur diagnostiserar du det?
• Förklara skillnaden mellan partitioning och clustering, och när vardera hjälper.

Datamodellering

• Designa tabellerna för en nätmarknadsplats orderhistorik. Vad är grain för din fact table?
• Förklara ett star schema, och när du medvetet skulle denormalisera ytterligare.
• Vad är en slowly changing dimension, och hur implementerar du typ två?
• En intressent vill att historisk rapportering ska spegla en kunds nuvarande region. Vad går sönder?
• Hur skulle du modellera en händelseström som kommer oordnad?
• När skulle du välja en bred tabell framför en normaliserad modell?

Modelleringsomgången belönar att binda sig till en grain och försvara den. Kandidater som beskriver tre möjliga designer utan att välja får sämre poäng än kandidater som väljer en rimlig design och namnger dess svaghet.

Pipeline- och ETL-design

• Designa en pipeline som laddar dagliga transaktioner i ett warehouse för rapportering.
• Uppströmskällan skickar gårdagens data igen. Vad händer med ditt jobb?
• Hur gör du en pipeline idempotent, och varför spelar det roll för omkörningar?
• Hur skulle du backfilla två års historik utan att störa den dagliga laddningen?
• Sen data dyker upp tre dagar efter att partitionen stängdes. Vad gör du?
• Hur upptäcker du att en pipeline lyckades men producerade fel data?
• Vad övervakar du, och vad väcker någon klockan tre på natten?

Distribuerad bearbetning och streaming

• Vad orsakar en shuffle, och varför är den dyr?
• Ditt jobb är långsamt och en task tar mycket längre tid än resten. Vad pågår?
• Förklara data skew och två sätt att hantera det.
• När skulle du välja streaming framför ett schemalagt batch-jobb?
• Vad garanterar exactly once processing egentligen, och var gäller det inte?
• Hur hanterar watermarks oordnade händelser i en windowed aggregering?

Lägg märke till hur få av dessa frågor ber dig nämna ett verktyg. Att nämna ett är början på svaret, inte svaret. Följdfrågan är alltid varför, och vad som går sönder.

Att läsa dessa listor bygger igenkänning. Designomgångarna testar något annat: att hålla ett system i huvudet medan någon avbryter dig med ett felscenario. Det kommer bara från att säga designer högt.

• Rita och berätta en pipeline på femton minuter. Källa, landing, transform, serve, plus hur varje steg kan gå fel.
• Attackera din egen design. Efter varje övningsomgång, fråga vad som händer vid en omkörning, vid sen data, och vid en schemaändring.
• Ha en siffra redo för skala. Rader per dag, storlek, latensbudget. Att ange din antagna skala först bedöms.
• Skriv SQL för hand. Liveomgångar använder ofta en vanlig editor utan autocomplete och utan körning.
• Öva in en incidenthistoria ordentligt. Vad gick sönder, hur upptäckte du det, vad ändrade du så att det inte kunde hända igen.

En data engineer med sex års erfarenhet av batch-pipelines förberedde sig genom att repetera framework-interna, men fastnade på "uppströmskällan skickade gårdagens fil igen" eftersom hon bara någonsin hanterat det för hand, aldrig förklarat det. Kunskapen fanns; det talade svaret gjorde inte det. Att öva designomgången med följdfrågor är precis vad läget mock interview är byggt för.