Veri Analisti Mülakat Soruları: SQL Sonucundan İş Kararına Giden Örnek Vaka

Veri analisti mülakat soruları, doğru SQL sorgusunu yazmanın yanında o sonucun hangi kararı desteklediğini açıklamanızı gerektirir. Bir tamamlanma oranı düştüğünde hemen “eğitim kötüleşti” demek yerine payı, paydayı, dönemi ve verinin hangi anda görüldüğünü kontrol edin. İyi bir cevap, hesaplanmış sonuçla henüz doğrulanmamış açıklamayı ayırır.

Bu yazıdaki özgün vaka, bir eğitim programının tamamlanma panosunu inceliyor. Önce oranı yeniden üretecek, sonra iki açıklamayı sınayacak ve kısa bir yönetici önerisi hazırlayacaksınız. Başlamadan önce PracHub’daki How do you diagnose a ratio metric change sorusunu açıp bir oran değişikliğini hangi parçalara ayıracağınızı düşünün.

Kanıt sınırı: SQL davranışları için resmi veritabanı belgeleri kullanılıyor. Katılımcılar, zamanlar, iş kuralları ve konuşmalar PracHub’ın ürettiği örneklerdir; gerçek bir şirketin sınavından alınmamıştır. Belirli bir işverenin mülakat turları veya değerlendirme eşikleri hakkında aday raporuna dayalı bir iddia ileri sürülmüyor. Önerilen analiz sırası ise hazırlık amaçlı bir çıkarımdır.

Önce hangi kararın istendiğini sorun

Görüşmeci şöyle bir durum verir: “Eylül eğitimini tamamlama oranı dün yüzde 75, bugün yüzde 60 görünüyor. Programı değiştirmeli miyiz?” İlk adımda grafiği değil, istenen kararı netleştirin. Hangi kararın ne zaman alınacağını ve yanlış kararın maliyetini netleştirin.

Örnekte ekip, gelecek ayın eğitim içeriğini yeniden hazırlamak için kaynak ayırmayı düşünüyor. Ölçüm hatası varsa içerik değişikliği gereksiz iş yaratabilir. Gerçek bir öğrenme sorunu varsa yalnızca panoyu düzeltmek yetersiz kalır. İçeriği değiştirmekle ölçümü düzeltmek farklı kanıt gerektirir.

Şu başlangıç cevabı uygundur: “Önce iki görüntünün aynı dönem, uygun katılımcı tanımı ve veri kesitiyle hesaplanıp hesaplanmadığını kontrol edeceğim. Düşüş sürerse tamamlama davranışını ve program değişikliklerini inceleyeceğim. Yalnızca bu oranla içerik kalitesi hakkında nedensel sonuç çıkarmam.”

Bu yaklaşım kararı sonsuza kadar ertelemek anlamına gelmez. Mülakatta hangi kontrolün hızlıca yapılabileceğini, hangi bulgunun önerinizi değiştireceğini ve eldeki sınırlı bilgiyle ne yapılabileceğini belirtin. “Daha fazla veri lazım” tek başına uygulanabilir bir cevap değildir.

Tamamlanma metriğinin sözleşmesini yazın

Bu vaka için analiz birimi benzersiz katılımcıdır. Bir kişinin birden fazla tamamlanma kaydı olsa bile o kişi uygunluk kuralına göre paydada bir kez sayılır; tamamlayan sayısında en fazla bir kez yer alır. Bir etkinlik satırı ile bir kişiyi aynı birim gibi saymayın.

Ölçülen dönem 1 Eylül 2026 saat 00.00 dahil, 1 Ekim 2026 saat 00.00 hariçtir. Tüm zamanlar UTC kabul edilir. Tamamlanma olayı bu dönemde gerçekleşmelidir. Ayrıca sorgunun gördüğü veri anına kadar sisteme ulaşmış olmalıdır. Olay zamanı ile kayıt geliş zamanı aynı şey değildir.

Yeni uygunluk kuralı, önce hariç tutulan iki kayıtlı katılımcıyı kapsama almıştır. Bu değişiklik kursa yeni birinin o sabah katıldığı anlamına gelmez. Aynı katılımcı listesine farklı bir tanım uygulanmaktadır. İş biriminin onayladığı kural sürümünü raporla birlikte saklayın.

Payın da bu uygun katılımcı kümesinden gelmesi gerekir. Uygun olmayan kişilerin tamamlanmalarını paya ekleyip onları paydadan çıkarmak anlamsız bir oran üretebilir. Birden fazla kurs varsa anahtarın yalnızca kişi değil kişi-kurs çifti olması gerekebilir; bu küçük örnek tek kursla sınırlıdır.

Veriyi okuyun: on kişi, dokuz olay satırı

Aşağıdaki tabloları boş bir SQLite veritabanına yükleyebilirsiniz. SQLite tarih belgelerinde açıklanan metin temsiliyle, tarihler aynı biçimde UTC zaman dizgeleri olarak tutuluyor. Bu tercih örneği küçük tutar; gerçek sistemde zaman türlerini, saat dilimini ve kaynak doğruluğunu ayrıca kontrol edin.

CREATE TABLE learners (
  learner_id INTEGER PRIMARY KEY,
  old_eligible INTEGER NOT NULL
);
INSERT INTO learners VALUES
 (1,1),(2,1),(3,1),(4,1),(5,1),
 (6,1),(7,1),(8,1),(9,0),(10,0);

CREATE TABLE completions (
  event_id TEXT PRIMARY KEY,
  learner_id INTEGER NOT NULL,
  event_at TEXT NOT NULL,
  ingested_at TEXT NOT NULL
);
INSERT INTO completions VALUES
 ('a',1,'2026-09-30T18:00:00','2026-09-30T18:01:00'),
 ('a_retry',1,'2026-09-30T18:00:00','2026-09-30T18:02:00'),
 ('b',2,'2026-09-30T18:00:00','2026-09-30T18:01:00'),
 ('c',3,'2026-09-30T18:00:00','2026-09-30T18:01:00'),
 ('d',4,'2026-09-30T18:00:00','2026-09-30T18:01:00'),
 ('e',5,'2026-09-30T18:00:00','2026-09-30T18:01:00'),
 ('f',6,'2026-09-30T18:00:00','2026-09-30T18:01:00'),
 ('g',7,'2026-09-30T20:00:00','2026-10-01T11:00:00'),
 ('h',9,'2026-10-01T01:00:00','2026-10-01T01:01:00');

Birinci kişinin iki satırı, iki tamamlayan kişi değildir. Yedinci kişinin olayı Eylül dönemindedir fakat ilk veri anında henüz gelmemiştir. Dokuzuncu kişinin olayı sisteme zamanında ulaşsa da Ekim dönemine aittir. Sekizinci ve onuncu kişiler için tamamlanma olayı yoktur.

Sorguyu yazmadan tekrar kaydı, geç gelen olayı, dönem dışı olayı ve eksik tamamlanmayı ayırın. Böylece beklediğiniz sonucu koddan bağımsız kurarsınız. Beklenen cevabı sorgunun kendi çıktısından türetmek, sorgudaki mantık hatasını kontrolün içine taşır.

SQL sonucunu tanıma göre üretin

Resmi teknik bilgi: PostgreSQL’in aggregate işlevleri belgeleri, COUNT(*) ile tüm satırların, COUNT(ifade) ile NULL olmayan değerlerin sayıldığını açıklar. Tablo ifadeleri belgeleri ise dış birleştirmede koşulun ON veya WHERE içinde olmasının sonucu değiştirebileceğini gösterir. Buradaki uygulama önce kişi düzeyinde özet çıkarır, sonra uygun katılımcılara bağlar.

WITH eligible AS (
  SELECT learner_id
  FROM learners
  WHERE :rule_version = 2 OR old_eligible = 1
), seen AS (
  SELECT learner_id, 1 AS completed
  FROM completions
  WHERE event_at >= '2026-09-01T00:00:00'
    AND event_at <  '2026-10-01T00:00:00'
    AND ingested_at <= :snapshot
  GROUP BY learner_id
)
SELECT COUNT(*) AS eligible_people,
       COALESCE(SUM(seen.completed), 0) AS completed_people,
       100.0 * COALESCE(SUM(seen.completed), 0)
         / NULLIF(COUNT(*), 0) AS completion_pct
FROM eligible
LEFT JOIN seen USING (learner_id);

rule_version için yalnızca 1 veya 2 kabul edildiğini uygulama sınırında doğrulayın. Sorgu, bu iki sürüm arasındaki karşılaştırma içindir; bilinmeyen bir sürümü sessizce eski kural saymak güvenli bir genel tasarım değildir. snapshot da sabitlenmiş, kaydedilmiş bir parametre olmalıdır.

seen bir kişi için en fazla bir satır üretir. Böylece tekrar gönderilen olay payı şişirmez. LEFT JOIN, tamamlanması görülmeyen uygun kişileri paydada tutar. Sağ tabloya ait tamamlanma koşulunu sonradan WHERE içine taşımak bu kişileri eleyebilir ve tamamlanma oranını yapay olarak yükseltebilir.

Resmi koşullu ifadeler belgesindeki NULLIF, sıfır paydada bölmeyi önler; bu sonuç “yüzde sıfır” olarak gösterilmemelidir. Sıfır uygun kişi ile uygun kişilerden kimsenin tamamlamaması farklı durumlardır. 100.0 kullanımı da tam sayı bölmesi nedeniyle ondalığın kaybolmasını önler.

Özgün çalıştırma kanıtı: Bu sorgu SQLite 3.53.4 ile aşağıdaki sonuçları verdi. Bu bir PostgreSQL çalıştırma iddiası veya gerçek eğitim sisteminin veri sözleşmesi değildir; taşınabilir sorgu mantığına ait yerel doğrulamadır.

Düşüşü iki ayrı köprüyle açıklayın

A ile B arasında gözlenen olaylar aynıdır; yalnızca uygunluk tanımı değişmiştir. Bu karşılaştırmada 15 yüzde puanlık fark, daha geniş paydadan kaynaklanır. B ile C arasında kural sabittir; yedinci kişinin Eylül olayı sisteme ulaşmıştır ve oran 10 yüzde puan artmıştır.

“Yüzde 15 düştü” ifadesi belirsizdir. Yüzde 75’ten yüzde 60’a iniş 15 yüzde puandır; başlangıç oranına göre göreli düşüş yüzde 20’dir. Yüzde puan farkını mı, göreli değişimi mi bildirdiğinizi söyleyin. İş kararı için çoğu zaman kişi sayısını da göstermek daha anlaşılırdır.

A ile C’yi doğrudan karşılaştırıp “gerçek performans beş puan düştü” demeyin. İki farklı kural ve iki farklı veri anı aynı anda değişmiştir. Davranış karşılaştırması için önce tanımı ve gözlem olgunluğunu eşitlemeniz gerekir.

Bu hesap ayrıştırması, köprüyü seçtiğimiz sıraya bağlıdır. Daha büyük bir analizde pay ve payda birlikte değişiyorsa farklı ayrıştırma sıraları farklı katkılar üretebilir. Burada A-B aynı veri anını, B-C aynı kuralı kullanarak her adımda tek değişkeni sabitliyoruz.

İki açıklamayı gerçekten sınayın

İlk açıklama “paneldeki düşüş bir tanım ve veri gelişi sorunu” olsun. Bu örnekte A-B farkı aynı olaylarla yeniden üretilir; geç kayıt da B-C farkını açıklar. Kontroller kural sürümü, etkinlik sayısı, benzersiz kişi sayısı ve kayıt gecikmesi üzerinden yapılır.

İkinci açıklama “eğitim katılımcılar için daha zor veya daha az yararlı oldu” olsun. Mevcut üç hesap bunu kanıtlamaz. Bunun için karşılaştırılabilir katılımcı grupları, benzer tamamlanma fırsatı, içerik değişiklikleri ve mümkünse öğrenme çıktıları gerekir. Tamamlama tek başına öğrenme kalitesinin doğrudan ölçümü değildir.

Geciken tek kaydı bulmak tüm veri hattının eksiksiz olduğunu kanıtlamaz. Kaynak sistemde beklenen kişi veya olay listesiyle karşılaştırma, hata kuyruğu ve son başarılı yükleme bilgisi gerekebilir. Hiç gelmemiş olayları yalnızca mevcut olay tablosundan kesin olarak sayamazsınız.

Bu küçük veri seti bir istatistiksel anlamlılık testi için tasarlanmadı. On kişilik örnekten bütün eğitim programı hakkında genelleme yapmayın. Önce ölçümü düzeltmek, daha sonra daha geniş veriyle davranış ve belirsizlik değerlendirmek mantıklıdır; bir p-değeri tanım uyuşmazlığını çözmez.

İş birimine kısa ve sınırları belli öneri verin

Görüşmede analizinizi şu şekilde özetleyebilirsiniz: “İlk yüzde 75 eski uygunluk kuralıyla hesaplanmış. Aynı veri anında yeni kural yüzde 60 veriyor; düşüşün bu kısmı iki kişinin paydaya alınmasından kaynaklanıyor. Öğlen gelen bir Eylül kaydı yeni kurala göre sonucu yüzde 70’e çıkarıyor.”

Ardından kararınızı ekleyin: “Bu bulgular içerik kalitesinin düştüğünü göstermiyor. İçeriği hemen yeniden yazmak yerine panoya kural sürümü ve veri anı eklemeyi, geçmişi aynı tanımla yeniden hesaplamayı öneriyorum. Kaynakla tamlık kontrolünden sonra benzer gruplarda düşüş sürerse içerik incelemesini başlatırım.”

Bu öneri bir sorumlu ve kontrol noktasıyla uygulanabilir hale gelir. Örneğin veri ekibi uygunluk değişikliğini doğrular; eğitim ekibi tanımın iş açısından doğru olduğunu onaylar. Sonraki raporda aynı kural ve sabit veri kesitiyle sayılar yeniden karşılaştırılır. Örnek için kesin bir üretim teslim süresi uydurmayın.

“Her şey veri hatasıymış” ifadesinden kaçının. Yeni uygunluk tanımı doğru bir ürün kararı olabilir; yanlış olan onu eski tanımla açıklamasız karşılaştırmak olabilir. Geç olay da gerçek tamamlanmayı temsil eder. Analistin işi değişikliği gizlemek değil, okuyucunun neyi karşılaştırdığını görünür kılmaktır.

Takip sorularında varsayımı değiştirin

Görüşmeci yeni kurala dahil edilen kişilerin farklı bir eğitim aşamasında olduğunu söylerse tek toplam oranı savunmaya devam etmeyin. Aynı fırsat süresine sahip grupları ayrı gösterin ve birleşik sonucun grup bileşimine bağlı olduğunu açıklayın. Segmentleri sonucu gördükten sonra yalnızca istenen hikâyeyi desteklemek için seçmeyin.

“Tamamlandı olayı sonradan iptal edilebiliyor” denirse GROUP BY learner_id yeterli olmayabilir. Durum geçişleri, düzeltme zamanı ve geçerli son durum gerekir. Yeni sözleşmeyi netleştirmeden mevcut sorguya rastgele MAX eklemek doğru bir çözüm değildir.

“Yönetici bugün karar istiyor” denirse mevcut bulgularla geri alınabilir bir adım önerin: panoya açıklama eklemek ve raporu düzeltmek. Yüksek maliyetli içerik değişikliğini ise karşılaştırılabilir davranış kanıtına bağlayın. Bekleme maliyeti varsa onu da açıkça belirtin; belirsizlik kararsızlıkla aynı şey değildir.

Son provada bir arkadaşınız oran, kural veya veri anından yalnızca birini değiştirsin. Hangi SQL parametresinin, beklenen çıktının ve önerinin değişeceğini söyleyin. Hazır bir cevabı ezberlemek yerine tanımdan karara giden bağlantıyı koruyup koruyamadığınızı bu şekilde görebilirsiniz.

Sonucu yeniden üretilebilir şekilde teslim edin

Bir analiz dosyasını paylaşırken yalnızca yüzde değerini yazmayın. Kullanılan sorguyu, kural sürümünü, veri anını ve beklenen kişi sayılarını birlikte kaydedin. A hesabının sekiz uygun kişiyi, B ve C hesaplarının on uygun kişiyi içerdiği görülebilmelidir. Böylece sonraki kişi farklı bir veri anıyla sorguyu çalıştırdığında değişen sonucu hata sanmaz.

Bu örnekte basit bir teslim kontrolü yapabilirsiniz: her tamamlayan uygun kişiler kümesinde mi, kişi sayısı paydadan büyük mü, aynı kişinin tekrar olayı sayıyı değiştiriyor mu? Ayrıca dönem bitimindeki Ekim olayının Eylül payına girmediğini ve veri anından sonra gelen kaydın ilk hesapta görülmediğini doğrulayın. Beklenen sonuçları sorguyu okumadan hesaplayabilmek güçlü bir çapraz kontroldür.

Hatalı bir ham birleştirme bu küçük tabloda bile sorunu gösterir. İlk veri anında tamamlanma olaylarını kişi düzeyine indirmeden uygun kişilere bağlarsanız tekrar kayıt nedeniyle on bir satır ve yedi dolu olay elde edersiniz. Bunların oranı yaklaşık yüzde 63,64 olur. Bu sonuç kişi tamamlama oranı değildir; SQL çalışmış olsa da analiz birimi değişmiştir.

Kontrol notunda hangi iddianın doğrulandığını yazın. “Tekrar kayıt bu sorgunun kişi sayısını şişirmiyor” dar ve test edilebilir bir ifadedir. “Veri tamamen doğru” çok daha geniştir; kaynak doğruluğu, eksik kayıtlar ve tanım onayı ayrıca kanıt gerektirir. Bu ayrım mülakatta teknik güvenilirliği, gereksiz kesinlik kullanmadan göstermenizi sağlar.

PracHub ile beş ilgili soruyu çalışın

Bunlar belirli bir işverenin gelecekte soracağı soruların listesi değildir. İngilizce başlıkları korunmuş ilgili alıştırmalardır; her birinin kendi veri ve koşullarını yeniden okuyun.

Şimdi How do you diagnose a ratio metric change sorusunu çözün. Cevabınıza bir kontrol tablosu ekleyin ve üç cümlelik öneri yazın: neyi doğruladınız, ne belirsiz kaldı ve hangi kanıt kararınızı değiştirecek?

Sources and Further Reading

• PostgreSQL: aggregate işlevleri ve COUNT davranışı

• PostgreSQL: tablo ifadeleri, JOIN ve filtre yerleşimi

• SQLite: tarih ve zaman değerlerinin temsili

• PostgreSQL: COALESCE ve NULLIF