yoklateknik mülakat
GelişimGeçmiş

Backend Mid Mülakat Soruları

2789 doğrulanmış Backend Mid 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 2
Hangi HTTP metodu idempotent DEĞİLDİR?
  • aGET
  • bDELETE
  • cPOST✓
  • dPUT
Açıklama:Idempotent, aynı isteğin tekrarlanmasının sunucuyu bir kez gönderilmişle aynı state'te bırakması demektir. POST tipik olarak her çağrıda yeni bir resource yaratır; tekrar etkiyi çoğaltır. DELETE, tekrar 404 dönse bile idempotent kalır — resource iki durumda da silinmiştir.
API TasarımıZorluk 2
401 Unauthorized ile 403 Forbidden arasındaki fark nedir?
  • a401 kullanıcının o resource için yetkisi olmadığını, 403 istekte geçerli kimlik bilgisi bulunmadığını belirtir
  • b401 kimlik bilgisi eksik/geçersiz demektir; 403 kimliği doğrulanmış kullanıcının yetkisi yok demektir✓
  • cBirbirlerinin yerine kullanılabilirler; seçim ekip tercihine kalmıştır
  • d401 sadece süresi dolmuş session'lar, 403 sadece banlanmış hesaplar içindir
Açıklama:401 "kim olduğunu kanıtla" der (authentication problemi); 403 ise "kim olduğunu biliyorum ama bunu yapamazsın" der (authorization problemi). (a) şıkkı bunu tam tersinden anlatır — en klasik karıştırma budur.
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 2
Kayıtlı kullanıcı {"name": "Ali", "email": "[email protected]"}. Şu istek geliyor:
PATCH /users/7
Content-Type: application/json

{"email": "[email protected]"}

Doğru implemente edilmiş bir PATCH ile name alanına ne olur?
  • a"Ali" olarak kalır — PATCH yalnızca istekte yer alan alanları değiştirir✓
  • bnull olur, çünkü request body'de gönderilmemiştir
  • cİstek reddedilir: PATCH, resource'un tam halini gerektirir
  • dO alan için tanımlı sunucu tarafı default değerine sıfırlanır
Açıklama:PATCH kısmi güncellemedir: istekte olmayan alanlara dokunulmaz. Gönderilmeyen alanları null'lamak (b), PUT ile tam değiştirme davranışını tarif eder — eksik objeyi PUT ile göndermek, verinin kazayla silinmesinin tam da klasik yoludur.
API TasarımıZorluk 2
Bir request body geçerli JSON olarak parse ediliyor ama bir iş kuralını ihlal ediyor (doğum tarihi gelecekte). Ekip, istemcilerin bunu parse edilemeyen JSON'dan ayırt edebilmesini istiyor. Yaygın konvansiyon hangi status code ayrımıdır?
  • aİki durumda da 400, çünkü tüm istemci hataları tek code paylaşmalıdır
  • bBozuk ya da parse edilemeyen isteğe 422, düzgün ama anlamsal olarak geçersiz olana 400
  • cValidation hatalarına 500, parse hatalarına 400
  • dBozuk/parse edilemeyen isteğe 400, düzgün ama anlamsal olarak geçersiz olana 422✓
Açıklama:Yaygın konvansiyon: sunucu isteği parse bile edemiyorsa 400; parse edilip validation kurallarına takılıyorsa 422 (Unprocessable Content). (b) aynı ikilinin tersidir; 500 (c) ise istemcinin bozuk verisinin suçunu sunucuya atar.
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.

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