[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"me":3,"catalog:tr:data-engineer\u002Fdata-pipeline-reliability":4,"config":126},null,{"field_key":5,"field_name":6,"seniority":7,"topic_key":8,"topic_name":9,"spec_key":7,"spec_name":7,"locale":10,"cell_total":11,"field_total":12,"seniorities":13,"topics":17,"specs":40,"samples":41},"data-engineer","Data Engineer","","data-pipeline-reliability","Data Pipeline Reliability","tr",75,600,[14,15,16],"junior","mid","senior",[18,21,24,27,30,33,34,37],{"key":19,"name":20,"count":11},"data-governance-lineage","Data Governance Lineage",{"key":22,"name":23,"count":11},"data-modeling-warehousing","Data Modeling Warehousing",{"key":25,"name":26,"count":11},"data-partitioning-scaling","Data Partitioning Scaling",{"key":28,"name":29,"count":11},"data-pipeline-design","Data Pipeline Design",{"key":31,"name":32,"count":11},"data-pipeline-orchestration","Data Pipeline Orchestration",{"key":8,"name":9,"count":11},{"key":35,"name":36,"count":11},"data-quality-validation","Data Quality Validation",{"key":38,"name":39,"count":11},"streaming-fundamentals","Streaming Fundamentals",[],[42,60,74,87,100,113],{"id":43,"topic":9,"difficulty":44,"body":45,"options":46,"correct_key":51,"explanation":59},"019f6a40-d722-7670-a998-5ad2eefcd22d",1,"Bir veri pipeline'ında fail-fast ile dead-letter-queue (DLQ) hata yönetimi stratejileri arasındaki temel fark nedir?",[47,50,53,56],{"key":48,"text":49},"a","Fail-fast, başarısız kaydı sonsuza kadar yeniden dener; dead-letter-queue ise hiçbir kayıt tutmadan onu hemen siler.",{"key":51,"text":52},"b","Fail-fast ilk hatada tüm çalışmayı durdurur; DLQ ise başarısız kayıtları ayırıp devam eder.",{"key":54,"text":55},"c","Fail-fast ve dead-letter-queue, ekiplerin aynı teknik için kullandığı yalnızca iki farklı isimdir.",{"key":57,"text":58},"d","Fail-fast yalnızca streaming pipeline'lara, dead-letter-queue ise yalnızca batch pipeline'lara uygulanır.","Fail-fast, kötü bir durumun daha ileri yayılmaması için ilk hatada tüm çalışmayı durdurur; bu, availability'yi güvenlik lehine feda eder. Dead-letter-queue ise yalnızca sorunlu kayıtları sonradan incelenmek üzere ayırır, geri kalan batch işlenmeye devam eder. (a) her iki stratejiyi de yanlış tarif eder. (c) yanlıştır — farklı trade-off'ları temsil ederler. (d) yanlış bir kısıtlamadır; her iki desen de her iki işleme biçiminde uygulanabilir.",{"id":61,"topic":9,"difficulty":62,"body":63,"options":64,"correct_key":48,"explanation":73},"019f6a40-d723-7646-b0d8-7e553bc1dc9c",2,"Bir retry politikası toplamda en fazla 3 deneme (1 orijinal + 2 retry) yapılmasına izin veriyor; denemeler arasında sabit 5 saniyelik bir bekleme var. Orijinal deneme t=0'da başarısız oluyor. Her retry de anında başarısız olursa, pipeline hangi zamanda pes edip işlemi kalıcı başarısız olarak işaretler?",[65,67,69,71],{"key":48,"text":66},"t=10 saniyede; üçüncü toplam deneme başarısız olup limite ulaşıldığında.",{"key":51,"text":68},"t=15 saniyede; yapılandırılmış limitin ötesinde dördüncü bir deneme daha yapıldıktan sonra.",{"key":54,"text":70},"t=5 saniyede; yapılandırılmış maksimum göz ardı edilip yalnızca ilk retry'den sonra.",{"key":57,"text":72},"Hemen t=0'da; çünkü orijinal deneme zaten kalıcı bir başarısızlık sayılır.","1. deneme t=0'da başarısız olur; 5 saniyelik beklemeden sonra 2. deneme (1. retry) t=5'te başarısız olur; bir 5 saniye daha beklemeden sonra 3. deneme (2. retry) t=10'da başarısız olur. Bu toplam 3 denemedir, yani politikanın limitine ulaşılmıştır ve işlem t=10 saniyede kalıcı başarısız olarak işaretlenir. (b) yapılandırılmış deneme limitini aşar. (c) limite ulaşılmadan durur. (d) retry'lerin hiç yapılandırılmadığını varsayar.",{"id":75,"topic":9,"difficulty":62,"body":76,"options":77,"correct_key":54,"explanation":86},"019f6a40-d724-7606-bb92-3cede6afa54f","Exponential backoff retry stratejisinde, ardışık retry denemeleri arasındaki bekleme süresi tipik olarak nasıl davranır?",[78,80,82,84],{"key":48,"text":79},"Kaç deneme başarısız olmuş olursa olsun tamamen sabit kalır.",{"key":51,"text":81},"Her denemeyle azalır, böylece başarısız olan işlemler zamanla giderek daha hızlı yeniden denenir.",{"key":54,"text":83},"Her başarısızlıkla kabaca üstel olarak büyür; genellikle rastgele jitter ile birlikte kullanılır.",{"key":57,"text":85},"Her denemeden sonra sıfıra sıfırlanır ve yalnızca ilk retry için anlamlıdır.","Exponential backoff, art arda gelen her başarısızlıktan sonra bekleme süresini katlar (ör. 1sn, 2sn, 4sn, 8sn...); birçok istemcinin tam olarak aynı anda yeniden denememesi için genellikle jitter da eklenir. (a) sabit-gecikme stratejisini tarif eder, exponential backoff'u değil. (b) amaçlanan davranışın tam tersidir. (d) deseni tamamen yanlış anlar.",{"id":88,"topic":9,"difficulty":44,"body":89,"options":90,"correct_key":51,"explanation":99},"019f6a40-d725-7772-8e17-ed33dc885687","Bir veri pipeline'ı bağlamında pipeline SLA (service level agreement) tipik olarak neyi tanımlar?",[91,93,95,97],{"key":48,"text":92},"Verinin hedefe yüklenmeden önce dönüştürülmesinde kullanılan tam iç algoritmayı.",{"key":51,"text":94},"Verinin ne zaman hazır olacağına dair beklentiyi ve kabul edilebilir kalite\u002Feksiksizliği.",{"key":54,"text":96},"Pipeline'ın kod tabanı üzerinde çalışmasına izin verilen maksimum mühendis sayısını.",{"key":57,"text":98},"Pipeline'ın kodunda asla bug olmayacağına dair bir garantiyi.","Pipeline SLA'sı, tüketicilerin güvenebileceği sonuçlara dair bir taahhüttür — tipik olarak zamanlılık (veri ne zaman hazır olacak) ve bazen kalite eşikleri — bir implementasyon detayı değil. (a), (c) ve (d) bir SLA'nın gerçekte taahhüt ettiği şeyle ilgisiz konulardır.",{"id":101,"topic":9,"difficulty":62,"body":102,"options":103,"correct_key":51,"explanation":112},"019f6a40-d726-73a0-a36d-fdc5251e4cd9","Bir dataset'in her saat güncellenmesi bekleniyor. En son 14:00'te başarıyla güncellendi. Şu an saat 16:45. Şu andaki veri tazeliği (freshness) gecikmesi nedir?",[104,106,108,110],{"key":48,"text":105},"1 saat 45 dakika",{"key":51,"text":107},"2 saat 45 dakika",{"key":54,"text":109},"45 dakika",{"key":57,"text":111},"3 saat 45 dakika","Freshness lag, son başarılı güncellemeden bu yana geçen süredir: 16:45 - 14:00 = 2 saat 45 dakika. Beklenen sıklık saatlik olduğu için bu, verinin ciddi şekilde gecikmiş olduğu anlamına da gelir. (a), (c) ve (d) basit aritmetik hatalardır.",{"id":114,"topic":9,"difficulty":62,"body":115,"options":116,"correct_key":57,"explanation":125},"019f6a40-d726-7aac-8d10-63594d9458ef","Downstream bir rapor, bir metrik için anormal derecede düşük sayılar gösteriyor, ama pipeline hatasız tamamlandı ve hiçbir job başarısız olmadı. Bu durumu en iyi ne tanımlar?",[117,119,121,123],{"key":48,"text":118},"Bu olamaz; hatasız tamamlanan bir pipeline her zaman doğru çıktı üretir.",{"key":51,"text":120},"Bu normal bir SLA ihlalidir, çünkü SLA ihlalleri her zaman job başarısızlığı olarak görünür.",{"key":54,"text":122},"Bu yalnızca bir retry politikası yanlış yapılandırmasını gösterir; daha fazla retry sorunu yakalardı.",{"key":57,"text":124},"Bu, başarı görünmesine rağmen verinin bozuk olduğu sessiz veri bozulması (silent data corruption) olabilir.","Bir job, örneğin bir upstream schema değişikliği ya da exception fırlatmayan ince bir mantık hatası nedeniyle, başarıyla sonlanırken yine de yanlış veya eksik çıktı üretebilir. Bu, sessiz veri bozulmasının tanımlayıcı özelliğidir: hata sinyali yok ama veri bozuk. (a) yanlıştır — başarı durumu doğruluğu garanti etmez. (b) SLA zamanlılığını veri doğruluğuyla karıştırır. (c) nedeni yanlış atfeder; retry'ler geçici hataları ele alır, sessiz mantık\u002Fschema sorunlarını değil.",{"fields":127,"seniorities":311,"interview_shapes":312,"locales":317,"oauth":319,"question_count":322,"coach_enabled":323,"jd_match_enabled":323},[128,153,173,190,214,227,246,265,287,294,298,305],{"key":129,"name_tr":130,"name_en":130,"sort":44,"specializations":131},"backend","Backend",[132,135,138,141,144,147,150],{"key":133,"name":134,"field":129},"general","Genel",{"key":136,"name":137,"field":129},"go","Go",{"key":139,"name":140,"field":129},"python","Python",{"key":142,"name":143,"field":129},"java","Java",{"key":145,"name":146,"field":129},"csharp","C#\u002F.NET",{"key":148,"name":149,"field":129},"nodejs","Node.js",{"key":151,"name":152,"field":129},"php","PHP",{"key":154,"name_tr":155,"name_en":155,"sort":62,"specializations":156},"frontend","Frontend",[157,158,161,164,167,170],{"key":133,"name":134,"field":154},{"key":159,"name":160,"field":154},"javascript","JavaScript",{"key":162,"name":163,"field":154},"typescript","TypeScript",{"key":165,"name":166,"field":154},"react","React",{"key":168,"name":169,"field":154},"vue","Vue",{"key":171,"name":172,"field":154},"angular","Angular",{"key":174,"name_tr":175,"name_en":175,"sort":176,"specializations":177},"fullstack","Fullstack",3,[178,179,180,181,182,183,184,185,186,187,188,189],{"key":133,"name":134,"field":174},{"key":136,"name":137,"field":129},{"key":139,"name":140,"field":129},{"key":142,"name":143,"field":129},{"key":145,"name":146,"field":129},{"key":148,"name":149,"field":129},{"key":151,"name":152,"field":129},{"key":159,"name":160,"field":154},{"key":162,"name":163,"field":154},{"key":165,"name":166,"field":154},{"key":168,"name":169,"field":154},{"key":171,"name":172,"field":154},{"key":191,"name_tr":192,"name_en":192,"sort":193,"specializations":194},"devops-cloud","DevOps \u002F Cloud",4,[195,196,199,202,205,208,211],{"key":133,"name":134,"field":191},{"key":197,"name":198,"field":191},"aws","AWS",{"key":200,"name":201,"field":191},"gcp","GCP",{"key":203,"name":204,"field":191},"azure","Azure",{"key":206,"name":207,"field":191},"kubernetes","Kubernetes",{"key":209,"name":210,"field":191},"terraform","Terraform",{"key":212,"name":213,"field":191},"linux","Linux",{"key":215,"name_tr":216,"name_en":216,"sort":217,"specializations":218},"ai-engineer","AI Engineer",5,[219,220,221,224],{"key":133,"name":134,"field":215},{"key":139,"name":140,"field":215},{"key":222,"name":223,"field":215},"llm-rag","LLM\u002FRAG",{"key":225,"name":226,"field":215},"mlops","MLOps",{"key":228,"name_tr":229,"name_en":230,"sort":231,"specializations":232},"database","Veritabanı","Database",6,[233,234,237,240,243],{"key":133,"name":134,"field":228},{"key":235,"name":236,"field":228},"postgresql","PostgreSQL",{"key":238,"name":239,"field":228},"mysql","MySQL",{"key":241,"name":242,"field":228},"mongodb","MongoDB",{"key":244,"name":245,"field":228},"redis","Redis",{"key":247,"name_tr":248,"name_en":249,"sort":250,"specializations":251},"mobile","Mobil","Mobile",7,[252,253,256,259,262],{"key":133,"name":134,"field":247},{"key":254,"name":255,"field":247},"ios-swift","iOS (Swift)",{"key":257,"name":258,"field":247},"android-kotlin","Android (Kotlin)",{"key":260,"name":261,"field":247},"flutter","Flutter",{"key":263,"name":264,"field":247},"react-native","React Native",{"key":266,"name_tr":267,"name_en":268,"sort":269,"specializations":270},"security","Güvenlik","Security",8,[271,272,275,278,281,284],{"key":133,"name":134,"field":266},{"key":273,"name":274,"field":266},"appsec","AppSec",{"key":276,"name":277,"field":266},"offensive-pentest","Offensive \u002F Pentest",{"key":279,"name":280,"field":266},"cloud-security","Cloud Security",{"key":282,"name":283,"field":266},"devsecops","DevSecOps",{"key":285,"name":286,"field":266},"blue-team-incident","Blue Team \u002F Incident",{"key":288,"name_tr":289,"name_en":290,"sort":291,"specializations":292},"qa-test-automation","QA \u002F Test Otomasyonu","QA \u002F Test Automation",9,[293],{"key":133,"name":134,"field":288},{"key":5,"name_tr":6,"name_en":6,"sort":295,"specializations":296},10,[297],{"key":133,"name":134,"field":5},{"key":299,"name_tr":300,"name_en":301,"sort":302,"specializations":303},"game-dev","Oyun Geliştirme","Game Development",11,[304],{"key":133,"name":134,"field":299},{"key":306,"name_tr":307,"name_en":307,"sort":308,"specializations":309},"ml-engineer","ML Engineer",12,[310],{"key":133,"name":134,"field":306},[14,15,16],{"junior":313,"mid":315,"senior":316},{"questions":314,"median_sec":3},20,{"questions":314,"median_sec":3},{"questions":314,"median_sec":3},[10,318],"en",[320,321],"google","github",21750,true]