Bir BI mülakatı nasıl ilerler?
Veri analisti ve BI geliştirici mülakatları genellikle dört bölümden oluşur. Her biri farklı bir şeyi ölçer:
| Bölüm | Ne ölçülür? | Nasıl hazırlanılır? |
|---|---|---|
| Kavram soruları | Filtre bağlamı, ilişkiler, model tasarımı gibi temellerin anlaşılması | Aşağıdaki 12 soruyu kendi cümlelerinle, örnekle cevaplayabilmek |
| Canlı DAX ya da SQL | Bir iş sorusunu doğru ölçüye çevirme ve sesli düşünme | Arena meydan okumaları ve Sınavlar’daki kod sınavları |
| Vaka ya da rapor eleştirisi | Bir raporu okuma, sorunu bulma, öneri sunma | Örnek raporlar bölümü ve DAX Dedektif vakaları |
| Davranışsal | Paydaşla çalışma, belirsizlik, hata yönetimi | 2–3 gerçek proje hikâyesini Durum–Görev–Eylem–Sonuç yapısıyla hazırlamak |
En sık sorulan 12 kavram sorusu
Her cevap üç parçadan oluşmalı: tanım, kısa bir örnek ve “ne zaman önemli”. Ezberden okunan tanım değil, örnek ikna eder.
1. Filtre bağlamı ile satır bağlamı arasındaki fark nedir?
Filtre bağlamı, bir hücre hesaplanırken modelde hangi satırların görünür olduğudur (görselin satırları, dilimleyiciler, CALCULATE filtreleri). Satır bağlamı ise bir iteratörün ya da hesaplanmış sütunun “şu anki satır” bilgisidir ve kendi başına filtrelemez. Örnek: hesaplanmış sütunda SUM(Satislar[Tutar]) her satırda tablonun toplamını verir, çünkü satır bağlamı filtre değildir.
2. CALCULATE ne yapar?
İfadeyi değiştirilmiş bir filtre bağlamında hesaplar: filtre argümanları ilgili sütunlardaki dış filtreleri değiştirir, satır bağlamı varsa önce filtreye dönüştürür (bağlam geçişi). DAX’ta filtre bağlamını değiştirebilen fonksiyonlar yalnızca CALCULATE ve CALCULATETABLE’dır.
3. SUM ile SUMX farkı nedir?
SUM tek bir sütunu toplar. SUMX bir tabloyu satır satır dolaşır, her satırda bir ifade hesaplar ve sonuçları toplar: SUMX(Satislar, Satislar[Adet] * Satislar[BirimFiyat]). Satır düzeyinde bir hesap gerekiyorsa SUMX; yoksa SUM daha sade ve aynı hızdadır.
4. Bağlam geçişi nedir?
Satır bağlamında bir ölçü çağrıldığında ya da CALCULATE kullanıldığında, mevcut satırın değerleri filtreye dönüşür. Ölçüler örtük bir CALCULATE içerdiği için SUMX(VALUES(Urunler[Urun]), [Net Satış]) her üründe o ürünün satışını hesaplar.
5. ALL, ALLSELECTED ve REMOVEFILTERS farkı?
ALL ve REMOVEFILTERS, CALCULATE içinde filtreleri tamamen kaldırır (REMOVEFILTERS yalnızca bu iş için vardır ve niyeti daha açık gösterir). ALL ayrıca tablo döndürebilir. ALLSELECTED görselin kendi satır ve sütunlarından gelen filtreleri kaldırır ama dilimleyici ve sayfa filtrelerini korur: “ekranda görünen toplam içindeki pay” için kullanılır.
6. Yıldız şema neden önerilir?
Olgu tablosu ortada, boyut tabloları çevresinde ve ilişkiler bire-çok olduğunda filtreler tek yönde, öngörülebilir biçimde akar; VertiPaq daha iyi sıkıştırır ve DAX daha basit kalır. Düz (tek tablo) model, tekrar eden metin sütunları yüzünden büyür ve “müşteri başına” gibi ölçüleri zorlaştırır.
7. Çift yönlü ilişki ne zaman sorun olur?
Filtrenin iki yönde akması belirsiz yollar ve döngüler yaratabilir; sonuçlar beklenmedik değişir ve performans düşer. Gerektiğinde ilişkiyi tek yönlü bırakıp ölçü içinde CROSSFILTER(..., BOTH) ile yalnızca o hesap için açmak daha güvenlidir.
8. Hesaplanmış sütun mu, ölçü mü?
Hesaplanmış sütun yenilemede bir kez hesaplanır, modelde yer kaplar ve dilimleyicide, satır alanında kullanılabilir. Ölçü sorgu anında, filtre bağlamına göre hesaplanır ve yer kaplamaz. Kural: değeri satır düzeyinde bir özellik olarak filtrelemek ya da gruplamak istiyorsan sütun; toplanacak bir sayıysa ölçü.
9. Zaman zekâsı için neden ayrı bir tarih tablosu gerekir?
Zaman fonksiyonları kesintisiz bir tarih sütunu bekler. Olgu tablosundaki tarihlerde boşluk olur (satış olmayan günler). Ayrıca ayrı tablo; yıl, çeyrek, ay ve tatil gibi sütunları tek yerde tutar ve birden çok olgu tablosunu aynı takvimle filtreler.
10. Satır düzeyi güvenlik (RLS) nasıl çalışır?
Bir rol, bir tabloya DAX filtresi ekler (ör. [Bolge] = "Marmara"); filtre ilişkiler üzerinden olgu tablosuna yayılır. Dinamik RLS’te filtre kullanıcının e-postasıyla eşleşen satırları seçer: [Eposta] = USERPRINCIPALNAME(). Roller yayından sonra Service’te kullanıcılara atanır ve “Farklı görüntüle” ile test edilir.
11. Yavaş bir raporu nasıl incelersin?
Önce ölç: Performans Analizi ile hangi görselin ve hangi aşamanın (DAX sorgusu mu, görsel çizimi mi) yavaş olduğunu bul. Sorgu yavaşsa DAX Studio’da Server Timings’e bak. Sonra en sık sebepleri ele: yüksek kardinaliteli sütunlar, gereksiz sütunlar, çift yönlü ilişkiler, iteratör içindeki koşullar, sayfadaki görsel sayısı.
12. Import, DirectQuery ve Direct Lake arasında nasıl seçim yaparsın?
Import en hızlı sorguyu verir ama veri yenileme zamanına kadar eskidir ve model belleğe sığmalıdır. DirectQuery veriyi kaynağında sorgular; güncel ama yavaştır ve DAX kısıtları vardır. Direct Lake (Fabric) Delta tablolarını doğrudan belleğe okur: Import’a yakın hız, kopya ve yenileme gerektirmeden güncellik.
Canlı DAX sorusuna yaklaşım
Mülakatçı doğru formülden çok düşünme biçimini izler. Beş adımlı bir yol işe yarar:
- Soruyu netleştir. “Net satış iptalleri içeriyor mu? Toplam satırında ne görünmeli?” gibi bir iki soru sormak eksiklik değil, profesyonelliktir.
- Görseli tarif et. “Satırlarda kategori, sütunda yıl olan bir matris düşünüyorum.” Filtre bağlamını konuşulur hâle getirir.
- Mevcut ölçülerden kur.
[Net Satış]varsa SUM’ı yeniden yazma; ölçüleri birbirinin üzerine kurmak, iyi model alışkanlığıdır. - VAR ile adım adım yaz ve her değişkenin ne tuttuğunu söyle.
- Bir hücreyle doğrula. “Elektronik 2024 hücresinde bu ölçü şunu verir; toplam satırında ise şunu.” Sınır durumlarını (BLANK, ilk yıl, sıfıra bölme) kendin söyle.
Mülakatçının sevdiği tuzaklar
| Tuzak | Ne olur? | Ders |
|---|---|---|
| VAR’ı CALCULATE’ten önce hesaplamak | Değişken sabittir; filtre onu değiştirmez | VAR, mantık |
[A] - [GY] ilk yılda | BLANK 0 sayılır; tüm satış “büyüme” görünür | BLANK ve hatalar |
Tarih[Yil] = Y - 1 ile geçen yıl | Ay-yıl kırılımında her hücre BLANK | Zaman zekâsı |
| Ortalamaların ortalaması | Küçük gruplar ortalamayı orantısız etkiler | İteratörler |
ALL(Satislar) | Boyut filtreleri de silinir (genişletilmiş tablo) | ALL ailesi |
| Toplam satırının toplam olmaması | Toplanamayan ölçüler toplamda yeniden hesaplanır | Filtre bağlamı |
Bu tuzakların hepsi derslerin “Derinleş” bölümlerinde gerçek verilerle gösteriliyor.
Vaka sorusunu anlatmak
“Bu rapora bakıp ne söylersin?” sorusunda sonuca değil, yola puan verilir. Önce genel resmi (toplam, eğilim), sonra en büyük sapmayı, sonra sebebi aradığın kırılımları anlat ve bir öneriyle bitir. DAX Dedektif vakaları tam olarak bu akışı çalıştırır. Sınavlar bölümündeki Mülakat simülasyonu ise süreli bir canlı DAX turudur ve her sorudan sonra gerçek mülakatlardaki gibi bir takip sorusu gösterir.
Rol bazlı kavram soru bankası (zayıf ve güçlü cevap örnekleriyle), davranışsal sorular, ev ödevi vakası ve rapor eleştirisi alıştırması için menüdeki Mülakat bölümüne, sık karıştırılan kavramlar ve hatalar için de Sık karıştırılanlar ve Sık hatalar sayfalarına bak.
İleri teknik mülakat: dört tur
Kıdemli analist ve BI geliştirici mülakatlarında kavram soruları kısalır, uygulama turları uzar. Genellikle şu dört tur görülür:
| Tur | Süre | Ölçülen | En çok puan kaybettiren |
|---|---|---|---|
| Canlı DAX kodlama | 30–45 dk | Soruyu ölçüye çevirme, doğrulama alışkanlığı | Sessizce yazıp test etmeden “bitti” demek |
| Model tasarım tahtası | 30 dk | Tanecik, olgu–boyut ayrımı, zor ilişkiler | Doğrudan tablo çizmeye başlamak |
| Rapor eleştirisi | 15–20 dk | Önceliklendirme, iş dili | Renk ve yazı tipiyle başlamak |
| “Bu rakam yanlış” | 20–30 dk | Sistematik hata ayıklama | Tahminle formül değiştirmek |
Canlı DAX turu: sorgu ile çalış
Mülakatçı ekran paylaşımında şunu ister: “Birden fazla kanaldan alışveriş yapmış müşteri sayısını yıl yıl göster.” Ölçüyü model içinde yazmak yerine DAX sorgu görünümünde DEFINE MEASURE ile yaz. Hem tanımı hem sonucu aynı ekranda gösterirsin ve modeli değiştirmeden denersin:
DEFINE
MEASURE Satislar[Çok Kanallı Müşteri] =
COUNTROWS(
FILTER(
VALUES(Satislar[MusteriNo]),
CALCULATE(DISTINCTCOUNT(Satislar[Kanal]), Satislar[Durum] <> "İptal") >= 2
)
)
EVALUATE
SUMMARIZECOLUMNS(Tarih[Yil], "Çok kanallı", [Çok Kanallı Müşteri], "Müşteri", [Müşteri Sayısı])
Sonuç: 2022'de 32 müşteriden 9'u, 2023'te 77'den 48'i, 2024'te 123'ten 88'i birden çok kanal kullanmış. Şimdi sesli doğrula:
- Bağlam geçişi: FILTER her müşteri satırında CALCULATE çağırır; satır bağlamı müşteri filtresine döner ve kanal sayısı o müşteri için hesaplanır.
- Toplam: Tüm dönemde 113. Yılların toplamı (145) değildir, çünkü müşteri yıllar arasında tekrar eder. Bunu mülakatçı sormadan söyle.
- Kenar durum: İptal filtresi içerideki CALCULATE'te. Yalnızca iptal edilmiş bir Mağaza siparişi olan müşteri “çok kanallı” sayılmaz.
Takip sorusuna hazır ol
İkinci görev çoğu zaman bir öncekinin üstüne kurulur: “Her kategorinin lider ürününü yaz.” TOPN(1, VALUES(Urunler[Urun]), [Net Satış]) çoğu hücrede doğru çalışır. Ama satış olmayan aylarda (bu modelde 2022'nin ilk beş ayı) bütün ürünler BLANK ile berabere kalır ve TOPN 40 ürünün hepsini döndürür. Çözüm: önce satışı olan ürünleri filtrele. Bu tuzağı kendin bulup söylemek, kıdemli adayı ayıran davranıştır.
Lider Ürün = VAR Satanlar = FILTER(VALUES(Urunler[Urun]), NOT ISBLANK([Net Satış])) VAR Lider = TOPN(1, Satanlar, [Net Satış], DESC) RETURN CONCATENATEX(Lider, Urunler[Urun], ", ")
Model tasarım tahtası
Örnek soru: “Bir e-ticaret şirketi kampanya etkisini ölçmek istiyor. Bir sipariş birden çok kampanya kodu kullanabilir. Hedefler aylık ve kategori bazında. İadeler ayrı bir sistemden geliyor. Modeli çiz.” Çizmeden önce şu sırayla konuş:
- Tanecik (grain): “Satış olgusu sipariş satırı düzeyinde; hedef ay × kategori düzeyinde; iade, iade satırı düzeyinde.” Bu cümle modelin yarısıdır.
- Olgular: Satislar, Hedefler, Iadeler. Üç olgu, üç ayrı tanecik; birleştirilmez.
- Ortak boyutlar: Tarih, Ürün (kategori dahil), Müşteri, Kanal, Kampanya. Hedefler Tarih ve Kategori'ye bağlanır, Ürün'e değil.
- Zor kısım: Sipariş–kampanya çoka-çok. Bir köprü tablo (SiparisNo, KampanyaNo) ve iki bire-çok ilişki. Kampanya filtresinin satışa ulaşması için ölçü içinde yön açma ya da köprü üzerinden filtre. Bir siparişi iki kampanyaya tam olarak saymanın toplamı şişireceğini söyle ve ağırlık (paylaştırma) seçeneğini öner.
- Güvenlik ve büyüme: RLS hangi boyutta? Veri büyürse artımlı yenileme ve toplama tabloları.
Sık hatalar: her şeyi tek düz tabloya koymak, hedefleri satış satırlarına join etmek, “filtreler aksın” diye her ilişkiyi çift yönlü yapmak. Ayrıntı Model tasarımı II ve Fabric'te yıldız şema derslerinde.
Rapor eleştirisi turu
Bir rapor ekran görüntüsü verilir. İlk dakika konuşma; incele. Sonra eleştiriyi doğruluk → anlam → tasarım önceliğiyle ve gözlem → etki → öneri biçiminde anlat.
- Doğruluk: “Kategori matrisinin toplam satırında marj %249,5 görünüyor. Bu bir oranın satırlarının toplanmış hâli; gerçek marj %36,5. Ölçü SUMX ile kategori marjlarını topluyor olabilir.” Doğruluk hatası her zaman ilk maddedir.
- Anlam: “Net satış kartında karşılaştırma yok; iyi mi kötü mü bilinmiyor.”
- Tasarım: “Yedi dilimli pasta grafikte küçük dilimler ayırt edilmiyor; sıralı çubuk daha iyi.”
Tam liste Rapor tasarımı dersindeki eleştiri kontrol listesinde.
“Bu rakam yanlış” turu: beş adım
Mülakatçı der ki: “CRM 2023'te 77 müşteri alışveriş yaptı diyor, sizin rapor 79 diyor. Bul.”
- Tanımı sor: “CRM neyi sayıyor? İptal edilen siparişler dahil mi?”
- Bağlamı sabitle: Aynı dönem, aynı filtreler. Rapordaki dilimleyicileri yaz.
- En küçük sorguda yeniden üret: İki tanımı yan yana koy.
DISTINCTCOUNT(Satislar[MusteriNo])2023 için 79,[Müşteri Sayısı]77. - Farkı satır düzeyinde bul: Küme farkı sorgusu farkı yapan müşterileri listeler.
- Düzelt ve testi ekle: Rapordaki görsel yanlış ölçüyü kullanıyordu. Doğru ölçüye geç ve bu karşılaştırmayı test sayfasına ekle.
EVALUATE
EXCEPT(
CALCULATETABLE(VALUES(Satislar[MusteriNo]), Tarih[Yil] = 2023),
CALCULATETABLE(VALUES(Satislar[MusteriNo]), Tarih[Yil] = 2023, Satislar[Durum] <> "İptal")
)
Sorgu iki müşteri döndürür (78 ve 102): 2023'te yalnızca iptal edilmiş siparişleri var. Aynı turda sık gelen iki varyasyon:
| Şikâyet | Rapordaki | Beklenen | Kök neden |
|---|---|---|---|
| “Ortalama sipariş tutarı çok düşük” | AVERAGE(Satislar[Tutar]) = 831 ₺ | 1.492,57 ₺ | Satır ortalaması, sipariş ortalaması değil; iptaller de içeride |
| “Net satış finanstan yüksek” | 1.250.772 ₺ | 1.169.937 ₺ | İadeler dahil; fark tam olarak iade tutarı (80.835 ₺) |