Blog / Veri Mühendisliği / Röportaj için 12 Soru: Veri Mühendisine — Küçük Liglerde Adil Eşleştirme, Loglama ve Şeffaf Raporlama Nasıl Kurulur?
Röportaj için 12 Soru: Veri Mühendisine — Küçük Liglerde Adil Eşleştirme, Loglama ve Şeffaf Raporlama Nasıl Kurulur?
Veri Mühendisliği

Röportaj için 12 Soru: Veri Mühendisine — Küçük Liglerde Adil Eşleştirme, Loglama ve Şeffaf Raporlama Nasıl Kurulur?

Giriş: Küçük ligler (amatör spor ligleri, espor topluluk turnuvaları veya yerel turnuva dizinleri) ölçeğinde adil eşleştirme, sağlam loglama ve şeffaf raporlama kurmak, büyük organizasyonlardakinden farklı öncelikler ve kısıtlar gerektirir. Bütçe, oyuncu sayısı, veri kalitesi ve operasyonel kaynaklar sınırlı olabilir. Bu yazıda bir veri mühendisine yöneltilecek 12 temel röportaj sorusunu örnek cevaplarıyla birlikte inceliyor; ayrıca uygulamaya dönük mimari, algoritma seçimleri, loglama pratikleri ve şeffaf raporlama için somut öneriler sunuyorum.

Neden bu sorular önemli?

Küçük ligler için teknik çözümler genellikle "hafif" ama güvenilir olmalı: düşük maliyetli, kolay işletilen, denetlenebilir ve gerektiğinde hızla değiştirilebilen sistemler. Röportaj soruları hem adayın algoritmik ve mimari bilgisini hem de pragmatik mühendislik yaklaşımını gösterir.

12 Temel Röportaj Sorusu ve Ne Aramalısınız

  1. Soru 1: Küçük bir lig için adil eşleştirme (matchmaking) tanımı sizce nedir?

    Adayın cevaplarında sadece "eşit kazanma şansı" değil, maç kalitesi, bekleme süresi, oyuncu deneyimi ve sistem ölçeklenebilirliği gibi çok boyutlu kriterleri tartışmasını bekleyin. İyi bir cevap, nicel metrikler (ör. bekleme süresi percentilleri, eşleştirme uyum skoru) önerecek ve işletme kısıtlarını hesaba katacaktır.

  2. Soru 2: Hangi sıralama/puanlama algoritmasını tercih edersiniz: ELO, Glicko, TrueSkill veya farklı bir yöntem? Neden?

    Burada adayın algoritmaların güçlü/zayıf yönlerini bilmesi gerekiyor. Örneğin:

    • ELO: Basit, az veride çalışır ama değişkenlik ve yeni oyuncular için zayıf.
    • Glicko/Glicko-2: Ölçüm belirsizliğini (rating deviation) işler, hızlı değişen yetenekleri daha iyi takip eder.
    • TrueSkill: Çok oyunculu veya takım tabanlı senaryolarda güçlü, belirsizlik ve ortak oynama modelleri içerir.

    Küçük liglerde genellikle Glicko ya da TrueSkill tercih edilir; fakat adayın örnek senaryoya göre trade-off analizi yapması önemlidir.

  3. Soru 3: Eşleştirme mantığını nasıl test eder ve doğrularsınız?

    İyi bir cevap A/B testleri, simülasyon (agent-based), backtest ( geçmiş maç verisiyle geri oynatma) ve metrik tabanlı izleme (mismatch rate, rematch oranı, bekleme süresi dağılımları) içermelidir. Ayrıca küçük liglerde offline simülasyonların çevrimiçi davranışı tam yansıtmayacağını kabul edip canary rollouts önerilmelidir.

  4. Soru 4: Loglama için hangi veri modelini önerirsiniz? Örnek bir şema çizer misiniz?

    Kısa fakat açık bir şema bekleyin. Örnek temel alanlar:

    • match_id, timestamp, player_ids, team_ids, matchmaking_version, rating_snapshot, decision_reason, latency_ms, outcome

    Logların immutable, zaman damgalı ve JSON-serializable olması, ayrıca unique ID ve versiyonlama (matchmaking_version) içermesi gerekir. Privacy için PII minimal tutulmalı (ör. player_id hashed/psuedoanonymized).

  5. Soru 5: Log toplama ve saklama için hangi teknoloji yığınını tercih edersiniz?

    Ölçek ve bütçeye göre alternatifler: küçük ölçek için Postgres + partitioning veya S3 + Parquet + Athena/BigQuery. Gerçek zamanlı gözlem için Kafka + stream processor (ksqlDB, Flink) + OLAP (ClickHouse) iyi kombinasyonlardır. Adayın maliyet/karmaşıklık balansı sunması olumlu puan getirir.

  6. Soru 6: Şeffaf raporlama nasıl olmalı? Hangi metrikler herkese gösterilmeli?

    Transparan raporlarda oyunculara gösterilebilecek metrikler: genel eşleştirme başarısı (avg wait), skill spread (ortalama rating farkı), itiraz oranı, rematch oranı. Yönetime özel raporlar: algoritma performansı, drift tespiti, bias analizleri. Önemli: raporlar yorumlanabilir, açıklama (explainability) ve sürüm bilgisini göstermeli.

  7. Soru 7: Eşleştirme algoritmalarında bias nasıl tespit edilir ve düzeltilir?

    Bias tespiti için segmentli analiz (örn. yeni oyuncular, gece-gündüz, bölgeye göre) ve karşılaştırmalı A/B testleri gerekir. Düzeltme: fairness-aware objective eklemek (ör. match_quality - lambda * wait_diff), kalibrasyon (rating normalization) ve eksplisit kısıtlama (aynı takım sıklığı sınırlama) yöntemleri kullanılabilir. Adayın concrete örnekler vermesi beklenir.

  8. Soru 8: Veri kalitesi sorunlarıyla nasıl başa çıkarsınız?

    Burada veri doğrulama (schema checks), anomaly detection (istatistiksel eşikler, ML tabanlı), eksik veriyi işleme (imputation politikaları) ve hatalı veriyi karantina altına alma süreçleri önemlidir. Küçük liglerde manuel denetimle otomasyon karışımı önerilir: kritik hataları insan onayıyla düzeltmek genellikle pratiktir.

  9. Soru 9: Denetlenebilirlik ve audit trail nasıl sağlanır?

    Immutable loglar, sürüm kontrollü algoritma konfigürasyonları, feature-store snapshotları ve idempotent event tasarımı gerekir. Uygulamada her eşleştirme kararına decision_id iliştirilip saklanmalı; böylece bir maçın neden hangi koşullarda eşleştirildiği geri izlenebilir.

  10. Soru 10: Anonimlik ve oyuncu gizliliğini nasıl korursunuz?

    PII minimal tutulmalı. player_id hashing/salting, veri maskeleme ve erişim denetimleri (RBAC) uygulanmalı. Loglarda gerektiğinde sadece aggregate metrikler paylaşılmalı. GDPR/KVKK farkındalığı gösteren aday tercih edilir.

  11. Soru 11: Hatalı bir eşleştirme sonrası itiraz sürecini teknik olarak nasıl desteklersiniz?

    İtiraz için otomatik form + ilgili match_id ve decision snapshot'ı sunulmalı. Backend, olayları ve ilgili logları hızlıca çekebilmeli; ayrıca bir "replay" mekanizmasıyla eski veriyi yeniden oynatarak durumu doğrulamak mümkün olmalıdır.

  12. Soru 12: Küçük liglerde maliyet etkin ve sürdürülebilir bir çözümü nasıl tasarlarsınız?

    Adayın cevaplarında maliyet/karmaşıklık/etki üçgenine göre önceliklendirme olmalı. Örnek yaklaşım: başlangıçta basit (ELO + Postgres) kurup telemetriyle toplayıp 6-12 ay sonra Glicko/TrueSkill ve daha sofistike log pipeline'a (Kafka + S3 + OLAP) geçmek. Otomasyon ile manuel onayların oranını azaltmak da maliyet düşürür.

Uygulama Rehberi: Teknik Adımlar ve Mimari Öneriler

1. İlk mimari (Minimum Viable Architecture)

Hızlı başlangıç için öneri:

  • API (matchmaking service) -> Postgres (matches, players, ratings)
  • Her match event JSON olarak S3'e yedeklenir (günlük partition)
  • Basit dashboard (Grafana veya Metabase) ile temel metrikler

Bu yapı düşük maliyetli, denetlenebilir ve değişiklikleri hızlı uygulatabilir.

2. Orta seviye: Güçlü telemetri ve analiz

İlerledikçe:

  • Event bus: Kafka
  • Stream processing: ksqlDB veya Flink (gerçek zamanlı eşleştirme telemetriği)
  • OLAP: ClickHouse veya BigQuery (analitik sorgular için)
  • Feature store: Basit bir tablo/servis ile rating snapshot'ları

3. Audit ve replay

Her kararı immutable event olarak saklayın. Replay mekanizması, geçmişte kullanılmış konfigürasyon ve feature snapshotları ile kararın tekrar üretilebilmesini sağlamalıdır.

Pratik Kontroller ve Metrikler

  • Match fairness score (ortalama rating farkı)
  • Wait time percentilleri (P50, P95)
  • Rematch/appeal oranı
  • Algoritma drift (rating dağılımındaki değişim)
  • Log completeness (event başına beklenen alanların doluluk oranı)
Not: Küçük liglerde kullanıcı iletişimi de şeffaflığın parçasıdır: belirgin, anlaşılır bir eşleştirme politikası sayfası ve itiraz akışı güven inşa eder.

Somut Örnek: Basit Eşleştirme Kararı Akışı

1) Gelen oyuncu isteği -> 2) Uygun havuzdan aday seçimi (rating aralığı + bölge + latency) -> 3) Aday havuzdan en iyi eşleşme skoru hesaplanır -> 4) Karar verilir, karar logu immutable olarak kaydedilir (decision_id ile) -> 5) Oyuncular bilgilendirilir ve maça alınır.

Sonuç

Röportaj soruları hem teorik bilgiyi hem de uygulamadaki pragmatiği sorgulamalıdır. Küçük ligler için doğru çözüm, genellikle "en sofistike" değil, "en tutarlı" ve "denetlenebilir" olandır. Adayın cevaplarında algoritma bilgisinin yanısıra veri mühendisliği pratikleri (loglama, immutable event, replay), maliyet bilinci ve kullanıcı odaklı şeffaflık olması gerekir. Bu rehberdeki 12 soru ve verilen uygulama önerileri, hem teknik yetkinliği hem de operasyonel olgunluğu değerlendirmek için bir çerçeve sunar.

Kısa eylem planı:

  • Başlangıç için hafif mimari kurun (Postgres + S3), temel log şemasını oluşturun.
  • İki aylık telemetri toplayıp eşleştirme performansını ölçün.
  • Daha sonra adım adım stream & OLAP ekleyin, audit/replay mekanizmasını hayata geçirin.

Ek kaynak önerisi: Glicko/TrueSkill literatürü, ClickHouse performans kılavuzları, GDPR/KVKK uçtan uca veri yönetimi rehberleri.