Senior Java / Spring Boot Mülakat Hazırlık Rehberi

Bu doküman, 10+ yıl Java deneyimi aranan bir senior pozisyon için hazırlanmış kapsamlı bir mülakat rehberidir. İlanda öne çıkan konuların (Java, Spring/Spring Boot, Microservices/REST, SQL, Git) yanında, senior seviyede genellikle beklenen sistem tasarımı, veritabanı performansı, DevOps farkındalığı ve mimari konuları da içeriyor.

Her başlık altında önce konunun kısa bir özeti var, ardından o konuyla ilgili en sık sorulan kritik sorular ve bunlara verilebilecek net cevaplar yer alıyor. Amaç, her konuyu ezbere değil mantığıyla anlatabilecek şekilde tazelemek. Rehberin sonunda ayrıca örnek kodlama soruları, senin soracağın sorular ve son hafta kontrol listesi bulunuyor.

1. Java (Çekirdek ve İleri Seviye)

JVM ve Bellek Yönetimi

Nesneler heap’te, metod çağrıları ve yerel değişkenler stack’te tutulur. Garbage Collector heap’i generation’lara böler (Young: Eden + Survivor, Old Generation) ve özellikle G1GC Java 9 sonrası varsayılan koleksiyoncu olarak öne çıkar. OutOfMemoryError gibi durumlarda ilk adım her zaman heap dump analizidir.

S: Bir uygulamada OutOfMemoryError alıyorsun, nasıl debug edersin?

C: Önce -XX:+HeapDumpOnOutOfMemoryError ile hata anında heap dump alınır. Eclipse MAT veya VisualVM ile dominator tree incelenir, hangi nesne tipinin sürekli büyüdüğü tespit edilir. Sık nedenler arasında statik koleksiyonlara sürekli ekleme yapılıp temizlenmemesi, kapatılmayan kaynaklar (stream, connection), temizlenmeyen ThreadLocal ve yanlış cache implementasyonu sayılabilir. GC loglarında Old Generation’ın sürekli büyümesi de erken bir sinyaldir.

S: Farklı GC türleri arasındaki temel fark nedir, hangi durumda hangisini seçersin?

C: Serial GC tek thread’li, küçük uygulamalar için uygundur. Parallel GC throughput odaklıdır, duraklamalardan çok toplam işlem hacmini önemser. G1GC (Java 9+ varsayılan) heap’i bölgelere ayırarak hem makul throughput hem düşük duraklama sunar, orta-büyük heap’lerde iyi bir denge noktasıdır. ZGC ve Shenandoah çok büyük heap’lerde milisaniyeler seviyesinde duraklama gerektiren düşük gecikmeli sistemler için tercih edilir.

Concurrency

synchronized, volatile ve java.util.concurrent paketi (ExecutorService, ConcurrentHashMap, CompletableFuture, CountDownLatch) senior mülakatlarda en çok sorulan alandır. volatile görünürlük sağlar ama atomiklik sağlamaz; bu ayrımı net bilmek kritik.

S: volatile ile synchronized arasındaki fark nedir, hangi durumda hangisi yeterli?

C: volatile sadece görünürlük garantisi verir (bir thread’in yaptığı değişikliği diğerleri anında görür), atomiklik sağlamaz. synchronized hem görünürlük hem atomiklik (karşılıklı dışlama) sağlar. Basit bir bayrak (örneğin “durdur” flag’i, tek okuma/yazma) için volatile yeterlidir. Sayaç artırma gibi oku-değiştir-yaz işlemlerinde synchronized, Lock veya AtomicInteger gibi atomik yapılar gerekir.

S: HashMap thread-safe değil, ConcurrentHashMap bunu nasıl çözüyor?

C: Java 7’de segment bazlı kilitleme vardı. Java 8 sonrası segment yapısı kaldırıldı, bunun yerine CAS (compare-and-swap) işlemleri ve sadece ilgili bucket’ın head node’unun senkronize edilmesi kullanılıyor. Bu sayede tüm map değil, sadece çakışan bucket kilitlenir; okumalar genelde kilitsiz yapılabilir. Bu da Hashtable‘a göre çok daha yüksek eşzamanlılık sağlar.

S: Deadlock nasıl oluşur, nasıl önlersin?

C: İki veya daha fazla thread, birbirinin elinde tuttuğu kilidi beklerken oluşur (circular wait). Önleme yolları: kilitleri her zaman aynı sırayla almak (lock ordering), tryLock ile timeout kullanmak, mümkünse tek bir kilit noktası kullanmak veya lock-free yapılara (atomic sınıflar, concurrent koleksiyonlar) yönelmek.

Koleksiyonlar ve Generics

HashMap’in iç yapısı (bucket, hash çakışması, Java 8 sonrası tree’ye dönüşüm), equals()/hashCode() kontratı ve ArrayList/LinkedList performans farkları klasik ama hâlâ sık sorulan konular.

S: equals() ve hashCode() neden birlikte override edilmeli?

C: Bir nesne HashMap, HashSet gibi hash tabanlı bir koleksiyona konulduğunda önce hashCode() ile doğru bucket bulunur, sonra o bucket içinde equals() ile eşleşme aranır. Sadece equals() override edilip hashCode() edilmezse, eşit kabul edilen iki nesne farklı bucket’lara düşebilir ve koleksiyon tutarsız davranır. Kontrat gereği eşit olan nesnelerin hash kodu da eşit olmalıdır.

S: ArrayList ile LinkedList arasındaki fark nedir, ne zaman hangisini seçersin?

C: ArrayList indeksle erişimde O(1)’dir çünkü ardışık bellek alanı kullanır, ama ortadan ekleme/çıkarmada elemanların kaydırılması gerektiğinden O(n) maliyeti vardır. LinkedList ortadan ekleme/çıkarmada (eğer node referansı elimizdeyse) O(1)’dir ama indeksle erişim O(n)’dir. Pratikte çoğu senaryoda ArrayList tercih edilir; sık sık baştan/ortadan ekleme-çıkarma yapılan kuyruk benzeri kullanımlarda LinkedList veya ArrayDeque düşünülür.

2. Spring Framework ve Spring Boot

Dependency Injection ve Bean Yaşam Döngüsü

Constructor injection, field injection’a göre tercih edilir çünkü immutability sağlar, test edilebilirliği artırır ve circular dependency’yi başlangıç zamanında ortaya çıkarır. Bean’ler singleton, prototype, request, session gibi farklı scope’larda yönetilebilir.

S: Constructor injection ile field injection arasındaki fark nedir, neden birini tercih edersin?

C: Constructor injection’da bağımlılıklar final alanlarda tutulur, bu immutability sağlar ve nesne tam kurulmadan kullanılamaz. Circular dependency varsa uygulama başlangıcında hata verir, yani hata erken yakalanır. Ayrıca Spring context olmadan da unit test yazmak kolaylaşır (new MyService(mockDependency)). Field injection reflection kullanır, bağımlılıkları gizler, null kalma riski taşır ve test için Spring context’e ihtiyaç duyar.

S: @Component, @Service, @Repository arasında pratikte fark var mı?

C: Fonksiyonel olarak hepsi bean tanımlar, ama semantik anlam taşırlar. @Repository ek olarak exception translation sağlar; veritabanı erişim katmanındaki spesifik exception’ları (örneğin SQLException) Spring’in kendi DataAccessException hiyerarşisine çevirir. Bu, katmanlar arası bağımlılığı azaltır ve hata yönetimini standartlaştırır.

Spring Boot Spesifik (Auto-configuration, Profiles, Actuator)

Spring Boot, classpath’teki kütüphanelere ve @Conditional anotasyonlarına bakarak hangi bean’lerin otomatik oluşturulacağına karar verir, bu sayede manuel config ihtiyacı büyük ölçüde ortadan kalkar. Profiles ile ortam bazlı konfigürasyon, Actuator ile de health check ve metrics yönetilir.

S: Spring Boot auto-configuration mekanizması nasıl çalışır?

C: @EnableAutoConfiguration (dolaylı olarak @SpringBootApplication içinde), META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports dosyasındaki (Spring Boot 2.7 öncesinde spring.factories) auto-configuration sınıflarını yükler. Her biri @ConditionalOnClass, @ConditionalOnMissingBean gibi anotasyonlarla, “bu kütüphane classpath’te varsa ve kullanıcı kendi bean’ini tanımlamadıysa” mantığıyla devreye girer. Bu sayede kullanıcı istediği zaman kendi bean’ini tanımlayarak varsayılanı ezebilir.

S: @ConfigurationProperties ile @Value arasındaki fark nedir?

C: @Value, tek tek property’leri okumak için kullanılır ve karmaşık/iç içe yapılar için pratik değildir. @ConfigurationProperties, bir prefix altındaki tüm property’leri type-safe bir POJO’ya bağlar, validasyon (@Validated) ile birlikte kullanılabilir ve iç içe (nested) yapıları destekler. Çok sayıda ilişkili konfigürasyon varsa @ConfigurationProperties daha sürdürülebilir bir yaklaşımdır.

Spring Data JPA / Hibernate

N+1 problemi ve lazy/eager loading farkı en sık karşılaşılan pratik sorundur. Transaction propagation türleri (REQUIRED, REQUIRES_NEW gibi) gerçek senaryolarla örneklenebilmeli.

S: N+1 problemi nedir, nasıl fark edip çözersin?

C: Bir liste sorgulanır (1 sorgu), sonra her elemanın lazy ilişkili verisi ayrı ayrı çekilir (N sorgu), toplamda N+1 sorgu oluşur. show-sql veya Hibernate statistics açarak arka arkaya aynı paternde çok sayıda SELECT görülünce fark edilir. Çözüm: JPQL’de JOIN FETCH kullanmak, @EntityGraph ile ilişkiyi eager yüklemek, veya hibernate.default_batch_fetch_size ile batch fetching yapmak.

S: @Transactional bir private metodun içinden çağrıldığında neden çalışmaz?

C: Spring AOP, bean’in etrafına bir proxy sarar ve @Transactional gibi anotasyonlar bu proxy üzerinden devreye girer. Aynı sınıf içinden bir metodun kendi içindeki başka bir metodu çağırması (self-invocation) proxy’yi bypass eder, doğrudan this üzerinden çalışır; bu yüzden advice tetiklenmez. Çözüm: transactional metodu ayrı bir bean’e taşımak, self-proxy kullanmak, ya da AspectJ compile-time weaving’e geçmek.

S: Transaction propagation türlerinden REQUIRED ile REQUIRES_NEW arasındaki fark nedir, gerçek bir senaryo verir misin?

C: REQUIRED (varsayılan), çağıran bir transaction içindeyse ona katılır, değilse yeni bir tane açar. REQUIRES_NEW her zaman yeni ve bağımsız bir transaction açar, mevcut transaction’ı askıya alır. Örnek senaryo: bir sipariş işlemi başarısız olup rollback olsa bile, o işlemle ilgili audit log kaydının veritabanına yazılmış olarak kalması isteniyorsa, log metodu REQUIRES_NEW ile işaretlenir; böylece ana işlem geri alınsa bile log kaydı kalıcı olur.

Spring Security

Filter chain mantığı, JWT tabanlı stateless authentication ve method-level security (@PreAuthorize) senior seviyede sık sorulan konulardır.

S: Stateless bir JWT authentication akışı nasıl işler?

C: Kullanıcı giriş yapınca sunucu bir JWT üretir (kullanıcı bilgisi ve süre içeren, imzalı bir token). Bu token her istekte Authorization: Bearer <token> header’ı ile gönderilir. Sunucu her istekte token’ın imzasını doğrular, session tutmaz (stateless). Token süresi dolduğunda genelde ayrı bir refresh token ile yeni access token alınır. Bu yaklaşım yatay ölçeklenmeyi kolaylaştırır çünkü sunucular arasında session paylaşımına gerek kalmaz.

Testing

@SpringBootTest tüm context’i ayağa kaldırırken, @WebMvcTest/@DataJpaTest gibi slice testler sadece ilgili katmanı yükler ve daha hızlı çalışır.

S: @SpringBootTest ile @WebMvcTest arasındaki fark nedir, ne zaman hangisini kullanırsın?

C: @SpringBootTest tüm uygulama context’ini (tüm bean’ler, gerçek konfigürasyon) ayağa kaldırır, entegrasyon testleri için uygundur ama yavaştır. @WebMvcTest sadece web katmanını (controller, filter, MockMvc) yükler, servis katmanı mock’lanır (@MockBean), çok daha hızlıdır ve controller’ın request/response davranışını izole test etmek için idealdir. Benzer şekilde @DataJpaTest sadece JPA katmanını test eder.

3. Microservices ve Sistem Tasarımı

Servisler arası iletişimde senkron (REST) ve asenkron (Kafka, RabbitMQ) yaklaşımların trade-off’ları, resilience pattern’leri (circuit breaker, retry, bulkhead) ve distributed transaction yönetimi (Saga pattern) senior seviyede en sık sorulan sistem tasarımı konularıdır.

S: Bir mikroservis çağrısı zaman aşımına uğradığında sistemin geri kalanını nasıl korursun (circuit breaker mantığı)?

C: Resilience4j gibi bir kütüphane çağrıyı sarar ve başarısızlık oranını izler. Eşik aşıldığında circuit “açık” duruma geçer, belirli bir süre boyunca çağrılar başarısız servise hiç gönderilmez, doğrudan hata döner ya da fallback devreye girer. Belirli bir bekleme süresinden sonra circuit “yarı açık” olur, birkaç test çağrısı yapılır; başarılıysa kapanır. Bu mekanizma, çöken bir servisin thread pool’unu tüketip zincirleme olarak diğer servisleri de düşürmesini engeller.

S: REST’te idempotency ne demek, PUT ile POST arasındaki fark nedir?

C: İdempotent, aynı isteğin birden fazla kez gönderilmesinin tek seferlik gönderimle aynı sonucu vermesi demektir. GET, PUT, DELETE idempotenttir. POST idempotent değildir, her çağrı genelde yeni bir kayıt oluşturur. Ödeme gibi kritik POST işlemlerinde idempotency key kullanarak (client’ın ürettiği benzersiz bir anahtar, sunucu tarafında daha önce işlenip işlenmediği kontrol edilerek) çift işlem önlenir.

S: İki mikroservis arasında veri tutarlılığını (distributed transaction) nasıl sağlarsın?

C: Klasik 2PC mikroservislerde performans ve kilitlenme sorunları yüzünden pratik değildir. Bunun yerine Saga pattern kullanılır: her servis kendi lokal transaction’ını yapar, bir sonraki adımı event ile tetikler (choreography) veya merkezi bir orkestratör yönetir (orchestration). Bir adım başarısız olursa önceki adımlar için compensating action çalıştırılır. Sonuç olarak strict consistency değil, eventual consistency hedeflenir.

S: Monolith’ten mikroservise ne zaman geçilmeli?

C: Mikroservise geçiş otomatik bir kazanç değildir, operasyonel karmaşıklık (deployment, monitoring, distributed debugging) maliyeti getirir. Ekip büyüklüğü artıp bağımsız deployment ihtiyacı doğduğunda, farklı modüllerin farklı ölçeklenme ihtiyaçları olduğunda veya organizasyon farklı takımlara bölündüğünde (Conway’s Law) mikroservis mantıklı hale gelir. Küçük bir ekip ve düşük trafik varken mikroservise geçmek genelde erken optimizasyon olur.

4. Veritabanı ve Performans

SQL sorgu optimizasyonu, index kullanımı, connection pooling ve caching stratejileri senior seviyede pratik deneyimle desteklenmesi beklenen konulardır.

S: Yavaş çalışan bir sorguyu nasıl analiz edip optimize edersin?

C: EXPLAIN veya EXPLAIN ANALYZE ile execution plan incelenir; full table scan var mı, planlanan index kullanılıyor mu kontrol edilir. Sık nedenler: WHERE/JOIN/ORDER BY kolonlarında index eksikliği, indexli kolon üzerinde fonksiyon kullanımı, SELECT * ile gereksiz veri çekimi, güncel olmayan tablo istatistikleri. Çözüm genelde doğru composite index eklemek ve sorguyu index dostu şekilde yeniden yazmaktır.

S: Index’in yazma performansına etkisi nedir, her kolona index koymak neden yanlış?

C: Her index, tabloya yapılan her INSERT/UPDATE/DELETE’te ayrıca güncellenmesi gereken bir veri yapısıdır. Çok fazla index, yazma işlemlerini yavaşlatır ve disk kullanımını artırır. Index’ler gerçek sorgu paternlerine göre, mümkünse doğru sırayla composite index olarak eklenmelidir, körlemesine her kolona konulmamalıdır.

S: Connection pool boyutunu nasıl belirlersin, neden “ne kadar büyük o kadar iyi” değildir?

C: Her connection, veritabanı tarafında bellek ve thread kaynağı tüketir. Çok büyük bir pool, veritabanı sunucusunda kaynak yarışına ve context-switching maliyetine yol açabilir; genelde optimal pool boyutu CPU çekirdek sayısına yakın küçük bir değerdir (HikariCP’nin kendi önerdiği formüller buna dayanır). Doğru boyut, yük testleriyle ve gerçek eşzamanlı istek sayısına göre belirlenmelidir.

5. Git

Branching stratejisi, rebase ile merge farkı ve commit geçmişi yönetimi senior seviyede iş akışına hakimiyeti gösteren pratik konulardır.

S: git rebase ile git merge arasındaki fark nedir, hangi durumda hangisini kullanırsın?

C: merge iki branch’in geçmişini birleştirip bir merge commit oluşturur, geçmiş dallanmış şekilde korunur, non-destructive’dir. rebase commit’leri yeni bir base üzerine tekrar oynatır, lineer bir geçmiş yaratır ama commit hash’lerini değiştirir. Paylaşılmış branch’lerde (main, develop) merge tercih edilir. Henüz kimseyle paylaşılmamış lokal feature branch’te, geçmişi sadeleştirmek için rebase kullanılabilir. Genel kural: zaten push edilip başkaları tarafından kullanılan bir branch asla rebase edilmemeli.

S: Yanlışlıkla push edilmiş bir commit’i nasıl geri alırsın?

C: Kimse pull etmediyse git reset --hard HEAD~1 ile commit kaldırılıp git push --force-with-lease yapılabilir. Ancak başkaları o commit’i çoktan çektiyse force push geçmişi bozar; bu durumda git revert <commit> kullanılmalı, bu değişikliği iptal eden yeni bir commit oluşturur ve geçmişi bozmaz. Paylaşılan branch’lerde her zaman revert, kişisel branch’lerde reset+force tercih edilir.

6. DevOps / Cloud Farkındalığı

Senior Java geliştiricilerden tam DevOps uzmanlığı beklenmez ama container, CI/CD ve observability konularında rahat konuşabilmek önemli bir sinyaldir.

S: Bir Java uygulaması container içinde çalışırken bellek yönetiminde nelere dikkat edilmeli?

C: Java 10 öncesinde JVM, host makinenin toplam belleğini görürdü, container’ın kendi limitini değil; bu da container limiti aşılıp OOMKilled almaya yol açabilirdi. Java 10 sonrası (-XX:+UseContainerSupport, varsayılan açık) JVM container’ın cgroup limitlerini doğru algılar ve heap boyutunu buna göre ayarlar. Yine de -Xmx gibi limitleri container memory limitinin biraz altında, açık şekilde belirlemek üretim ortamında daha güvenli bir pratiktir.

S: Kubernetes’te liveness ve readiness probe arasındaki fark nedir, Spring Boot ile nasıl entegre edilir?

C: Liveness probe, uygulamanın “hayatta” olup olmadığını kontrol eder; başarısız olursa Kubernetes pod’u yeniden başlatır. Readiness probe, uygulamanın trafiği karşılamaya hazır olup olmadığını kontrol eder; başarısız olursa pod trafikten çıkarılır ama yeniden başlatılmaz. Spring Boot Actuator, /actuator/health/liveness ve /actuator/health/readiness endpoint’lerini otomatik sağlar, bu sayede uygulamanın veritabanı bağlantısı gibi bağımlılıkları hazır olmadan trafik almasının önüne geçilir.

7. Mimari ve Kod Kalitesi

SOLID prensipleri, clean/hexagonal architecture ve code review yaklaşımı, senior seviyede “kod yazabiliyor musun” sorusunun ötesinde “sürdürülebilir sistem tasarlayabiliyor musun” sorusuna cevap arar.

S: SOLID prensiplerinden Dependency Inversion’ı gerçek bir örnekle anlatır mısın?

C: Dependency Inversion, üst seviye modüllerin alt seviye modüllere değil, her ikisinin de soyutlamalara (interface) bağımlı olması gerektiğini söyler. Örneğin bir OrderService, doğrudan MySQLOrderRepository sınıfına bağımlı olmak yerine bir OrderRepository interface’ine bağımlı olmalı; somut implementasyon (MySQL, PostgreSQL, in-memory) Spring’in DI mekanizmasıyla enjekte edilmeli. Bu sayede veritabanı değişse veya test için mock kullanılsa bile OrderService hiç değişmez.

S: Code review yaparken en çok neye dikkat edersin?

C: Öncelik sırası genelde şöyle olur: doğruluk (edge case’ler kaçırılmış mı, hata yönetimi var mı), güvenlik (input validation, yetkilendirme kontrolleri), sonra okunabilirlik ve isimlendirme, en son da stil tercihleri. Küçük stil tartışmalarına takılıp asıl riskli noktaları (örneğin bir transaction sınırının yanlış yerde olması) kaçırmamak önemli. Geri bildirim verirken de “neden” açıklamak, sadece “böyle olmalı” dememek, junior’ların gelişimine katkı sağlar.

8. Davranışsal / Liderlik Soruları

Senior pozisyonda teknik bilgi kadar, ekip içindeki etkin ve karar alma yeteneğin de değerlendiriliyor. Kendi hikayelerini STAR formatında (Situation, Task, Action, Result) önceden hazırlamak, mülakat anında rastgele cevap vermek yerine net ve etkili anlatım sağlar.

S: Bir üretim (production) kesintisini nasıl yönettiğini anlatır mısın?

C: Bu cevabı kendi somut deneyiminden vermelisin, ama genel çerçeve şöyle kurulabilir: önce etkiyi durdurmaya odaklan (rollback, feature flag kapatma, trafik yönlendirme), paralelde ilgili taraflara durum bildir, kök nedeni sakin şekilde araştır (loglar, metrikler, son deploy’lar), kalıcı çözümü uygula, sonrasında blameless bir post-mortem yaz ve tekrarını önleyecek somut aksiyon çıkar. “Önce stabilize et, sonra kök nedeni bul” sırasını vurgulamak, panikle kod değiştirmeye çalışmak yerine kontrollü davrandığını gösterir.

Hazırlanman faydalı olacak diğer soru başlıkları: bir teknik kararda ekip arkadaşınla anlaşamadığın bir durum, yanlış bir teknik karar aldığını fark ettiğin bir an, junior bir geliştiriciye mentorluk deneyimin, deadline baskısı altında kod kalitesi konusunda nasıl karar aldığın. Kendi ajansını kurup yönetmiş olman, hem teknik hem yönetimsel bakış açını gösteren özgün ve güçlü bir örnek olarak kullanılabilir.

9. Örnek Canlı Kodlama / Whiteboard Soruları

Senior seviyede genelde LeetCode tarzı algoritma sorusundan çok, gerçekçi tasarım problemleri sorulur:

• Basit bir rate limiter’ı Java ile implemente et (token bucket algoritması).
• Thread-safe bir LRU cache tasarla (LinkedHashMap ile veya manuel doubly linked list + HashMap).
• Bir producer-consumer problemini BlockingQueue kullanarak çöz.
• Bir REST endpoint için idempotent bir ödeme işlemi nasıl tasarlarsın (idempotency key kullanımı).
• Basit bir connection pool’u sıfırdan tasarla (mantığını anlat, kod şart değil).

10. Mülakatta Sen Soracaksın

Senior seviyede bu bölüm de değerlendirilir, doğru sorular sormak olgunluk gösterir:

• Takımın mevcut teknik borcu nedir, önceliklendirme nasıl yapılıyor?
• Deployment sıklığı nedir, CI/CD süreci nasıl işliyor?
• Kod review süreci ve teknik karar alma mekanizması nasıl (RFC, ADR kullanıyorlar mı)?
• Ekip mikroservis mimarisine mi gidiyor, yoksa monolith’i mi koruyor, bu kararın arkasındaki motivasyon ne?
• Senior olarak bu pozisyonda ilk 90 günde başarı nasıl ölçülür?

11. Son Hafta Kontrol Listesi

• [ ] JVM bellek yönetimi ve GC türlerini kendi cümlelerinle anlatabiliyor musun?
• [ ] Concurrency konularında en az 3 farklı senaryo (deadlock önleme, volatile/synchronized farkı, ConcurrentHashMap iç yapısı) anlatabiliyor musun?
• [ ] Spring Boot auto-configuration mekanizmasını adım adım açıklayabiliyor musun?
• [ ] N+1 problemini ve çözüm yollarını örnekle anlatabiliyor musun?
• [ ] Transaction propagation türlerinden en az iki tanesini gerçek senaryoyla eşleştirebiliyor musun?
• [ ] Circuit breaker ve idempotency kavramlarını net anlatabiliyor musun?
• [ ] Yavaş bir SQL sorgusunu nasıl analiz edip optimize edeceğini adım adım anlatabiliyor musun?
• [ ] rebase ile merge farkını ve ne zaman hangisini kullanacağını biliyor musun?
• [ ] 3-4 STAR formatında davranışsal hikaye hazır mı (çatışma çözümü, hata ve öğrenim, mentorluk, kriz yönetimi)?
• [ ] Mülakat sonunda soracağın 3-5 soru not edildi mi?