Veri Mühendisi Mülakat Soruları, Aşamalara Göre

Belki de bir yazılım mühendisliği mülakatına hazırlanır gibi hazırlanıyor ve farkın ne olduğunu merak ediyorsunuz. Bu bölüm, bu mülakatlarda tekrar tekrar kullanılan aşamaları haritalandırır, böylece zamanınızı adayları gerçekten ayıran iki aşamaya ayırabilirsiniz. Teknik filtre, teklifin kaybedildiği yer nadiren burasıdır.

• SQL. Window fonksiyonları, deduplication ve sorgu performansı, genellikle canlı olarak.
• Veri modelleme. Anlatılan bir iş için tablo tasarlamak ve seçtiğiniz grain'i savunmak.
• Pipeline ve ETL tasarımı. Veri hareketine odaklanmış, açık uçlu bir sistem tasarımı aşaması.
• Dağıtık işleme. Bir framework işinizi gerçekte nasıl çalıştırır, ve neden yavaştır.
• Kodlama. Python veya Scala, genellikle bir yazılım mühendisliği aşamasından daha hafif.
• Davranışsal. Nöbet olayları, bozulan dashboard'lar ve rakamı dün isteyen paydaşlar.

Unvanlar analytics engineering ve platform rolleriyle büyük ölçüde örtüşür, bu yüzden karışım değişir. İlgili rol soru bankaları role göre mülakat soruları merkezinde yer alır.

SQL

• Bir tabloyu, her anahtar için yalnızca en güncel satırı bırakacak şekilde deduplicate edin.
• 30 dakikalık bir hareketsizlik boşluğu kullanarak her kullanıcının oturum sayısını döndüren bir sorgu yazın.
• Tek bir sorguda running total ve ay bazında (month over month) değişimi hesaplayın.
• Dünün snapshot'ında bulunan ama bugünkünde eksik olan satırları bulun.
• QUALIFY ne işe yarar, ve onsuz ne yazardınız?
• Bu sorgu bir milyar satırı tarıyor ve yirmi dakika sürüyor. Bunu nasıl teşhis edersiniz?
• Partitioning ile clustering arasındaki farkı, ve her birinin ne zaman işe yaradığını açıklayın.

Veri modelleme

• Bir online pazaryerinin sipariş geçmişi için tabloları tasarlayın. Fact tablonuzun grain'i nedir?
• Bir star schema'yı açıklayın, ve ne zaman bilerek daha fazla denormalize edersiniz.
• Slowly changing dimension nedir, ve type two'yu nasıl uygularsınız?
• Bir paydaş, geçmişe dönük raporlamanın bir müşterinin güncel bölgesini yansıtmasını istiyor. Ne bozulur?
• Sırasız gelen bir event stream'i nasıl modellersiniz?
• Normalize edilmiş bir modele karşı geniş bir tabloyu ne zaman seçersiniz?

Modelleme aşaması, bir grain'e bağlanıp onu savunmayı ödüllendirir. Üç olası tasarımı seçim yapmadan anlatan adaylar, makul bir tasarım seçip zayıf noktasını söyleyen adaylardan daha düşük puan alır.

Pipeline ve ETL tasarımı

• Günlük işlemleri raporlama için bir warehouse'a yükleyen bir pipeline tasarlayın.
• Upstream kaynak dünün verisini yeniden gönderiyor. İşinize ne olur?
• Bir pipeline'ı nasıl idempotent hale getirirsiniz, ve bu yeniden çalıştırmalar için neden önemlidir?
• Günlük yüklemeyi aksatmadan iki yıllık geçmişi nasıl backfill edersiniz?
• Geç gelen veri, partisyon kapandıktan üç gün sonra ortaya çıkıyor. Ne yaparsınız?
• Bir pipeline'ın başarılı olduğunu ama yanlış veri ürettiğini nasıl tespit edersiniz?
• Neyi izlersiniz, ve sabahın üçünde birini neyin uyandırmasını sağlarsınız?

Dağıtık işleme ve streaming

• Bir shuffle'a ne sebep olur, ve neden pahalıdır?
• İşiniz yavaş ve bir task diğerlerinden çok daha uzun sürüyor. Ne oluyor?
• Data skew'i ve bunu ele almanın iki yolunu açıklayın.
• Zamanlanmış bir batch işine karşı streaming'i ne zaman seçersiniz?
• Exactly once processing gerçekte neyi garanti eder, ve nerede geçerli değildir?
• Watermark'lar, windowed bir aggregation'da sırasız olayları nasıl ele alır?

Bunların ne kadar azının size bir araç adı sormasına dikkat edin. Bir isim söylemek cevabın başlangıcıdır, cevabın kendisi değil. Sonraki soru her zaman neden, ve neyin bozulacağıdır.

Bu listeleri okumak tanıma kazandırır. Tasarım aşamaları başka bir şeyi test eder: biri sizi bir hata senaryosuyla keserken bir sistemi kafanızda tutmak. Bu yalnızca tasarımları sesli söylemekten gelir.

• On beş dakikada bir pipeline çizin ve anlatın. Kaynak, landing, transform, serve, artı her aşamanın nasıl bozulacağı.
• Kendi tasarımınıza saldırın. Her pratik turdan sonra, bir yeniden çalıştırmada, geç veride ve bir şema değişikliğinde ne olacağını sorun.
• Ölçek için hazır bir rakamınız olsun. Günlük satır sayısı, boyut, gecikme bütçesi. Varsayılan ölçeğinizi önce belirtmek puanlanır.
• SQL'i elle yazın. Canlı aşamalar genellikle otomatik tamamlama ve çalıştırma olmayan sade bir editör kullanır.
• Bir olay hikayesini iyice prova edin. Ne bozuldu, nasıl buldunuz, tekrar olmasın diye neyi değiştirdiniz.

Batch pipeline'larda altı yıllık deneyimi olan bir veri mühendisi, framework içyapısını gözden geçirerek hazırlandı, sonra "upstream kaynak dünün dosyasını yeniden gönderdi" sorusunda takıldı çünkü bunu yalnızca elle halletmişti, hiç anlatmamıştı. Bilgi oradaydı; sözlü cevap değildi. Takip sorularıyla tasarım aşamasını prova etmek, mock interview modunun tam olarak yapıldığı iştir.