yoklateknik mülakat
GelişimGeçmiş

Backend Senior Mülakat Soruları

2166 doğrulanmış Backend Senior mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

API TasarımıZorluk 3
Aynı DELETE isteği iki kez gönderiliyor:
DELETE /orders/42   ->  204 No Content
DELETE /orders/42   ->  404 Not Found

İki çağrı farklı status code döndürüyor. DELETE'in idempotency'si ihlal edilmiş midir?
  • aHayır — idempotency sunucu state'iyle ilgilidir; iki çağrıdan sonra da sipariş eşit derecede silinmiştir✓
  • bEvet — idempotent bir metod her tekrarda aynı status code'u döndürmek zorundadır; yalnızca aynı son state'e ulaşmak yetmez
  • cEvet — istemci retry'ı bırakana kadar sunucu 204 döndürmeye devam etmeliydi
  • dHayır — çünkü DELETE zaten hiçbir zaman idempotent bir metod olmadı
Açıklama:Idempotency, isteğin tekrarının sunucuyu aynı state'te bırakacağını vadeder; response'un birebir aynı olacağını değil. İki çağrıdan sonra da sipariş yoktur; 404 sadece artık var olmadığını raporlar. Aynı status code beklemek (b), tanımın en sık yanlış okunma biçimidir.
API TasarımıZorluk 3
İki istemci aynı dokümanı düzenliyor. Sunucuda şu an version: 5 kayıtlı. Şu güncelleme geliyor:
PUT /documents/12
Content-Type: application/json

{"title": "Final", "version": 4}

İstek bayat bir versiyona dayanıyor. Bu optimistic-locking tasarımında en uygun response hangisidir?
  • a200 OK — eşzamanlı düzenlemede işleyen tek politika last write wins'tir
  • b409 Conflict — güncelleme eski state'e dayanıyor✓
  • c404 Not Found — dokümanın 4. versiyonu artık sunucuda mevcut değil
  • d401 Unauthorized — istemcinin düzenleme session'ının süresi dolmuş
Açıklama:409 Conflict, isteğin resource'un güncel state'iyle çatıştığını söyler — versiyon uyuşmazlığının standart cevabıdır; istemcinin yapması gereken, güncel hali yeniden çekip tekrar denemektir. Sessizce kabul etmek (a), diğer istemcinin değişikliklerini ezerdi; optimistic locking tam olarak bunu önlemek için vardır. (c) ise versiyonu ayrı bir alt-resource sanma hatasıdır.
API TasarımıZorluk 3
Bir istemci offset tabanlı pagination ile sayfalarda ilerlerken listenin başına sürekli yeni satırlar ekleniyor. Cursor tabanlı pagination bu durumu neden daha iyi yönetir?
  • aCursor, sabit bir referans noktasından (örn. son görülen id) devam eder✓
  • bCursor, veritabanının tabloyu kilitlemesini sağlar; pagination sırasında insert olamaz
  • cCursor pagination tüm sonucu bir kez indirir ve istemci belleğinde sayfalar
  • dOffset pagination ORDER BY ile birleşemez, bu yüzden sonuçlar sırasız döner
Açıklama:Offset, satırları sonucun başından sayar; her ekleme her şeyi kaydırır ve istemci sayfalar arasında tekrar eden ya da atlanan kayıtlar görür. Cursor ise dönen son kaydın sabit anahtarına tutunur ve "bundan sonrasını" ister; başa eklenen satırlar sonraki sayfayı kaydıramaz. Kilitleme (b) söz konusu değildir — ölçekte kullanılamaz olurdu.
API TasarımıZorluk 3
Production'daki bir mobil uygulama JSON API'ni tüketiyor ve kullanıcıları uygulamayı güncellemeye zorlayamıyorsun. Hangi değişikliği yeni bir API versiyonu çıkarmadan yayınlayabilirsin?
  • aİsimlendirme tutarlılığı için created alanını createdAt olarak yeniden adlandırmak
  • bResponse objesine yeni bir opsiyonel avatarUrl alanı eklemek✓
  • cUUID desteği için id alanını JSON number'dan string'e çevirmek
  • dCreate isteğinde daha önce opsiyonel olan phone alanını zorunlu yapmak
Açıklama:Opsiyonel bir response alanı eklemek additive'dir: düzgün yazılmış istemciler tanımadıkları alanları yok sayar, hiçbir şey kırılmaz. Yeniden adlandırma (a) eski alanı yok eder, tip değişikliği (c) parser'ları bozar, yeni zorunlu girdi (d) ise önceden başarılı olan istekleri reddettirir — üçü de breaking change'tir.
API TasarımıZorluk 3
JSON body'li cross-origin bir PUT isteğinden önce browser, aynı URL'e kendi kendine bir OPTIONS isteği gönderiyor. Bu preflight isteği ne içindir?
  • aTCP bağlantısını ısıtır, böylece asıl istek daha hızlı tamamlanır
  • bİstemci payload'ı doğrulayabilsin diye endpoint'in şemasını indirir
  • cAsıl isteği göndermeden önce sunucuya cross-origin metod ve header'lara izin verilip verilmediğini sorar✓
  • dKullanıcının kimliğini önceden doğrular ve session cookie'si kaydeder; böylece gelecek PUT isteği yetkili olarak ulaşır
Açıklama:Basit sayılmayan cross-origin istekler — PUT/DELETE gibi metodlar, JSON content type'lar, özel header'lar — preflight tetikler. Sunucu Access-Control-Allow-* header'larıyla cevap verir; ancak izin çıkarsa browser asıl isteği gönderir. Performansla (a) ya da authentication ile (d) ilgisi yoktur.
API TasarımıZorluk 3
Bir ödeme API'si POST /payments isteği alıyor. Network timeout'ları istemcileri retry'a zorluyor ve bazı kullanıcılardan iki kez para çekiliyor. Hangi API tasarımı double charging'i contract seviyesinde çözer?
  • aİstemcilerin POST isteklerini asla retry etmemesi gerektiğini dokümante etmek
  • bİstemcinin ürettiği bir Idempotency-Key kabul edip retry'ları tekilleştirmek✓
  • cHer istemciyi dakikada bir isteğe rate-limit'lemek, böylece retry'lar reddedilir
  • dEndpoint'i PUT'a çevirmek, çünkü PUT tanımı gereği idempotent'tir
Açıklama:Idempotency key, sunucunun aynı mantıksal işlemin retry'ını tanıyıp tekrar para çekmek yerine saklanan sonucu döndürmesini sağlar. "PUT'a çevir" (d) kavramı yanlış anlamaktır: PUT'un idempotency'si tam-değiştirme semantiğinden gelir, "yeni bir ödeme oluştur"u tarif etmez — metodun adını değiştirmek hiçbir şeyi tekilleştirmez. (a) ise gerçekle kavgadır: timeout varsa retry kaçınılmazdır.

Konular

API Tasarımı 75Caching 75Eşzamanlılık 75Csharp Concurrency Async 75Csharp Exceptions 75Csharp Generics Interfaces 75Csharp Memory Performance 75Csharp Stdlib Http 75Csharp Testing Tooling 75Veritabanı / SQL 75Go Concurrency 75Go Errors 75Go Interfaces Generics 75Go Memory Performance 75Go Stdlib Http 75Go Testing Tooling 75Java Concurrency 75Java Exceptions 75Java Generics Interfaces 75Java Memory Jvm 75Java Stdlib Http 75Java Testing Tooling 75Mesajlaşma / Kuyruklar 75Ağ / HTTP 75Nodejs Error Handling 75Nodejs Event Loop Async 75Nodejs Memory Performance 75Nodejs Modules Streams 75Nodejs Stdlib Http 75Nodejs Testing Tooling 75Php Concurrency Async 75Php Exceptions 75Php Generics Interfaces 75Php Memory Performance 75Php Stdlib Http 75Php Testing Tooling 75Python Concurrency Async 75Python Errors Context 75Python Memory Performance 75Python Stdlib Http 75Python Testing Tooling 75Python Typing Oop 75Güvenlik 75Test 75

Uzmanlığa göre

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

Kıdeme göre

Backend JuniorBackend MidBackend Senior

Diğer alanlar

FrontendFullstackDevOps / CloudAI EngineerVeritabanıMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

3300 soruluk Backend bankasında kendini sına.

Mülakata başla