Veri Bilimci Mülakat Soruları ve Yanıtları Rehberi

Örnek Cevap

Bir e-ticaret projesinde sepet terk oranını azaltmaya odaklandım. Önce problemi modelleme değil, iş kararı olarak çerçeveledim: hangi kullanıcı grubuna hangi aksiyon alınırsa gelir artar? Segment bazlı analiz, basit bir tahmin modeli ve A/B test ile çalıştım. Sonuçları ürün ve pazarlama ekiplerine anlaşılır şekilde sundum; ekip, kampanya bütçesini yüksek dönüşüm ihtimali olan segmentlere kaydırdı. Benim için başarı, modelin accuracy'si değil, alınan kararın net etkisiydi.

Örnek Cevap

Önce veri yapısını, hedef metriği, gecikme ihtiyacını ve yorumlanabilirlik beklentisini netleştiririm. Çoğu durumda önce logistic regression gibi basit ve açıklanabilir bir baseline kurarım. Eğer baseline iş hedefini karşılamıyorsa, daha karmaşık modellere geçerim. Model seçiminde overfitting riski, bakım kolaylığı, deployment maliyeti ve ekip içi kullanım rahatlığı da benim için belirleyicidir.

Örnek Cevap

Önce öneriyi ve bunun neyi değiştireceğini söylerim; sonra destekleyici kanıtı kısa ve net sunarım. AUC, RMSE gibi metrikleri doğrudan bırakmak yerine, bunları gelir, kayıp, dönüşüm ya da operasyon yükü gibi iş diline çeviririm. Belirsizlikleri açıkça belirtirim; böylece karar, varsayımlar saklanmadan alınır. Gerekirse tek sayfalık özet ve sade görseller kullanırım.

Örnek Cevap

Kodumu sürüm kontrolünde tutar, veri kaynaklarını net dokümante eder ve mümkünse tek bir pipeline üzerinden çalışırım. Random seed, train-validation ayrımı ve veri sızıntısı kontrolleri benim için standart adımdır. Sonucu, makul benchmark'larla ve iş mantığıyla da çapraz kontrol ederim. Ayrıca code review kadar analitik review de isterim; çünkü temiz görünen ama hatalı bir analiz, kötü kod kadar risklidir.

Örnek Cevap

Bir projede ekip, belirli bir feature'ın dönüşümü artırdığına çok emindi. Ben ilişkiyi kontrollü değişkenlerle test ettiğimde etkinin büyük ölçüde kaybolduğunu gördüm. Bulguyu aceleyle reddetmeden, alternatif açıklamaları da kontrol ederek adım adım sundum. Sonrasında ekip kontrollü bir deney yaptı ve benim bulgum doğrulandı; kaynaklar daha etkili alanlara aktarıldı.

Type I error, gerçek null hipotezi yanlışlıkla reddetmektir; yani false positive'tir ve alpha düzeyiyle ilişkilidir. Type II error ise yanlış null hipotezi reddetmemektir; yani false negative'tir ve power ile bağlantılıdır. İkisi arasında denge vardır; hangi hatanın daha pahalı olduğuna göre karar verilir.

Bias, modelin çok basit varsayımlar nedeniyle veriyi yeterince öğrenememesinden doğan hatadır. Variance ise modelin eğitim verisine fazla duyarlı olup yeni veride kötüleşmesidir. Karmaşıklık arttıkça bias düşebilir ama variance artabilir; amaç, unseen data üzerinde toplam hatayı minimize etmektir. Regularisation, cross-validation ve daha fazla veri bu dengeyi kurmaya yardım eder.

Cross-validation, veriyi fold'lara ayırır; model bazı fold'larda eğitilir, kalan fold'da doğrulanır ve bu işlem döndürülür. Böylece her gözlem bir kez validation set olur. Sonuçların ortalaması, tek bir train-test split'e göre daha güvenilir performans tahmini verir. Özellikle veri azsa ve hyperparameter tuning yapılacaksa çok faydalıdır.

Dengesiz sınıflarda accuracy aldatıcı olabilir; çoğunluk sınıfını tahmin eden bir model bile yüksek accuracy alabilir. Precision, pozitif diye tahmin edilenlerin ne kadarının doğru olduğunu; recall ise gerçek pozitiflerin ne kadarının yakalandığını gösterir. Kullanım maliyetine göre seçim yapılır; örneğin hastalık taramasında recall, spam filtrelemede precision daha kritik olabilir.

Regularisation, loss fonksiyonuna ceza ekleyerek model karmaşıklığını azaltır ve overfitting'i kontrol eder. L1, katsayıların mutlak değerini cezalandırır; bazı katsayıları sıfıra çekerek feature selection etkisi yaratabilir. L2 ise kareler üzerinden ceza verir, katsayıları yumuşak biçimde küçültür ve korelasyonlu değişkenlerde daha stabil çalışır.

Farklı formatlarda gelen işlem verileri ve çok sayıda eksik alanla çalıştım. Önce missingness oranını çıkardım, sonra her kolon için eksikliğin mekanizmasına göre impute, drop veya flag kararları verdim. Her temizleme kararını dokümante ettim ki sonuçlar savunulabilir olsun. Temizlenmiş veri seti ekip için güvenilir kaynak haline geldi ve dokümantasyon sayesinde tekrar iş çıkarma ihtiyacı azaldı.

Offline iyi görünen bir model, deployment sonrası feature dağılımları eğitim verisinden kaydığı için zayıfladı. Giriş dağılımlarını ve çıktı kalitesini izleyen bir monitoring kurdum. Sonra modeli güncel veriyle yeniden eğittim ve planlı retraining pipeline ekledim. Performans toparlandı; monitoring bir sonraki drift'i kullanıcıya zarar vermeden yakaladı.

Yönetim kurulundan önce iki gün içinde pazar büyüklüğü tahmini gerekiyordu. Bu durumda mükemmel ama geç bir çalışma yerine, güvenilir veriyle savunulabilir bir back-of-the-envelope model kurdum. Varsayımları ve güven aralıklarını açık söyledim. Sonuç karar için zamanında kullanıldı; ayrıca daha sonra derinlemesine bir çalışma ile tahmin rafine edildi.

Bir ekip sezonluk etkileri göz ardı edip önce-sonra kıyaslarıyla başarı ilan ediyordu. Ben, gerçek etkiyi izole etmek için kontrollü bir A/B test önerdim ve küçük bir pilot tasarladım. Test sonucunda, yüksek sesle savunulan feature'ın etkisinin aslında nötr olduğu görüldü. Bu deneyden sonra ekip, büyük lansmanlarda deneysel yaklaşımı standart hale getirdi.