💼 Mülakat Soruları

Mülakat Soruları: Bu sorular yukarıdaki her şeyi kapsıyor: temel onboarding bilgisi, günlük kullanım ve trade-off'lara dair orta seviye, ve production/mimari senaryolarına dair i

Bu sorular yukarıdaki her şeyi kapsıyor: temel onboarding bilgisi, günlük kullanım ve trade-off'lara dair orta seviye, ve production/mimari senaryolarına dair ileri seviye. Burada basic ≠ "tanım ezberi" — kolay sorular bile işte gerçekten alacağın bir karar etrafında kurulu. Bunu bir aşçılık mülakatı gibi düşün: kimse şefe suyun kaç derecede kaynadığını sormaz. Eline malzemeleri verir ve önce neye uzandığını izler. Bilgi zaten varsayılır; ölçülen şey kararların sırasıdır. Peki "Bruno'yu bilen" bunca aday neden yine de burada tökezliyor? Çünkü bir aracı bilmek ile onu seçmeyi savunabilmek farklı becerilerdir. "Bruno collection'ları dosya olarak saklar" cümlesi herkesin tekrarlayabileceği bir bilgidir. "Dosya tabanlı collection'a geçtik çünkü API testlerimizin de repo'nun geri kalanı gibi code review'dan geçmesi gerekiyordu ve cloud sync bize hiçbir diff vermiyordu" ise bir **argüman**dır — ve mülakatçıya bunu gerçekten bir ekipte koşturduğunu söyleyen şey ikincisidir. Aynı ayrım Java mülakatlarında da vardır: `PreparedStatement`'ın ne yaptığını ezberden söylemek, string birleştirmeyi bir code review'da neden reddedeceğini açıklamaktan daha az ayırt edicidir. Her iki durumda da ayırt edici olan tanım değil, ona bağlanan akıl yürütmedir. QA için burada gömülü pratik bir kural var: her cevabın yanında kabul ettiğin trade-off'u da hazır tut. Her araç seçimi bir bedel öder — Bruno'nun bedeli, secret yönetiminin bir vendor'ın değil senin ekibinin sorumluluğuna geçmesidir. Bedeli adlandıran aday, ürün çıkarmış birine benzer; bedeli yok diyen aday ise bir tanıtım sayfası okumuş birine.

Mülakat Merceği — Bruno UI'sini Bir Mülakatçı Gibi Oku

🎬 Aynı DELETE İki Kez: İdempotency Testi Ne Bekler?

200 (idempotency bug)

Bir "delete order" akışı test ediliyor. İlk soru: aynı DELETE isteği İKİ KEZ gönderilirse ne olmalı?

Adım 1 — ilk DELETE gönderilir: kaynak gerçekten var, sunucu onu siler ve 200/204 döner.

Adım 2 — kaynak artık gitti. bru.setVar() ile orderId saklanır ki ikinci istek AYNI ID'yi tekrar dener, farklı bir ID değil.

Adım 3 — aynı orderId ile İKİNCİ DELETE gönderilir. Bu, gerçek idempotency testinin kalbi: kaynak zaten yokken ne dönmeli?

Adım 4 — doğru davranış: 404 "Not Found". "Zaten yoktu" demek, tekrar "başarıyla silindi" demekten farklıdır — assert 404'ü BEKLER.

Final (kontrast) — bir idempotency bug'ı olsaydı: ikinci DELETE de 200/204 dönerdi, sanki bir şey silinmiş gibi — bu, backend'in "zaten silinmiş" durumunu HİÇ takip etmediğinin kanıtıdır ve assert bu farkı yakalamak için özellikle var.

Adım Adım: 50 İstek İçin Tek Bir Token-Refresh Yeri

Collection-level pre-request script

Refresh mantigi TEK bir yere, koleksiyonun (veya ust klasorun) pre-request script'ine konur — 50 istegin her birine kopyalanmaz.

Süresi dolmuş mu kontrol et