Yazılımcı Mülakat Soruları

Nasıl yaklaşmalı: Teknoloji listesi saymak yerine bir hikâye anlatın: hangi alanlarda çalıştınız, en çok katkı verdiğiniz proje neydi ve bu pozisyona neden uygunsunuz. 60-90 saniyeyi geçmeyin.

Örnek cevap iskeleti: Birkaç yıldır web tarafında geliştirme yapıyorum; önceki iş yerimde bir e-ticaret projesinde hem backend servislerinde hem de arayüz tarafında çalıştım. En çok keyif aldığım iş, performans sorunlarını bulup çözmek oldu; bu konuda ekip içinde başvurulan kişi hâline geldim. Şimdi daha büyük ölçekli bir üründe, üretim ortamı sorumluluğu da alarak ilerlemek istiyorum; ilanınız tam olarak bunu tarif ediyor.

Olası takip soruları: En çok hangi teknoloji yığınıyla çalışmaktan keyif alıyorsunuz? · Bu projelerdeki rolünüz tam olarak neydi?

Nasıl yaklaşmalı: Şirketin ürününü, teknoloji yığınını veya mühendislik kültürünü araştırdığınızı gösterin ve bunları kendi kariyer hedefinizle ilişkilendirin. Genel geçer cevaplar bu soruda hemen belli olur.

Örnek cevap iskeleti: Ürününüzü inceledim ve çözdüğünüz problemin ölçeği ilgimi çekti; bu ölçekte performans ve veri tutarlılığı gibi konular gerçek mühendislik problemlerine dönüşüyor. Kullandığınız teknolojiler benim derinleşmek istediğim alanla örtüşüyor. Ayrıca ekiplerinizin code review ve test kültürüne önem verdiğini duydum; ben de böyle bir ortamda hem katkı verip hem gelişebileceğime inanıyorum.

Olası takip soruları: Teknoloji yığınımız hakkında ne biliyorsunuz? · Ürünümüzde geliştirilebilecek bir nokta gördünüz mü?

Nasıl yaklaşmalı: Uzmanlık mı, mimari mi, yöneticilik mi — yönünüzü net ama gerçekçi anlatın ve bu pozisyonun o yoldaki yerini gösterin. Kararsız görünmekten kaçının.

Örnek cevap iskeleti: Kısa vadede backend tarafında derinleşmek, özellikle dağıtık sistemler ve performans konularında uzmanlaşmak istiyorum. Orta vadede ise teknik kararlarda söz sahibi olan, tasarım aşamasından itibaren projeye yön veren bir kıdemli geliştirici olmayı hedefliyorum. Bu pozisyondaki sorumluluklar, o hedefe giden yolda ihtiyacım olan deneyimi birebir karşılıyor.

Olası takip soruları: Yöneticilik ilginizi çekiyor mu? · Kendinizi geliştirmek için şu an ne öğreniyorsunuz?

Nasıl yaklaşmalı: STAR ile ilerleyin: gecikmeyi ne kadar erken fark ettiğiniz (Durum), riski nasıl ilettiğiniz ve kapsamı nasıl yönettiğiniz (Eylem) kritik; görüşmeci sessiz kalıp son gün haber vermenizden korkar.

Örnek cevap iskeleti: Bir projede entegrasyon tarafında öngörmediğimiz sorunlar çıkınca sprint ortasında teslim tarihinin riske girdiğini fark ettim. Beklemek yerine durumu aynı gün ekip liderime somut verilerle ilettim: hangi işler bitti, hangileri risk altında, seçenekler neler. Ürün tarafıyla konuşup kapsamı önceliklendirdik; kritik özellikleri tarihinde teslim ettik, ikincil olanları bir sonraki sürüme aldık. Bu şeffaflık sayesinde güven kaybı yaşanmadı ve süreç krize dönüşmedi.

Olası takip soruları: Kapsam daraltma önerinize ürün ekibi karşı çıksaydı ne yapardınız? · Tahminlerinizi nasıl yapıyorsunuz?

Nasıl yaklaşmalı: Egodan arınmış tartışma kültürünü gösterin: görüş ayrılığının teknik gerekçelerini, karşı tarafı nasıl dinlediğinizi ve kararın hangi objektif kritere göre verildiğini anlatın.

Örnek cevap iskeleti: Bir review'da ekip arkadaşımın tercih ettiği yaklaşımın uzun vadede bakım maliyeti yaratacağını düşünüyordum; o ise mevcut çözümün daha hızlı teslim edileceğini savunuyordu. Yorum savaşına girmek yerine kısa bir görüşme ayarladım ve iki yaklaşımı okunabilirlik, test edilebilirlik ve teslim süresi kriterlerine göre birlikte karşılaştırdık. Sonunda onun çözümünü küçük bir düzenlemeyle kabul ettik; benim endişemi de bir refactor notu olarak kaydettik. İlişkimiz zarar görmediği gibi, review tartışmalarımız için ortak bir kriter seti oluşturmuş olduk.

Olası takip soruları: Kıdemli birinin kararına katılmadığınızda ne yaparsınız? · Review yorumlarınızı nasıl bir üslupla yazarsınız?

Nasıl yaklaşmalı: Hatanızı sahiplenin; asıl değerlendirilen şey kriz anındaki davranışınızdır: hızlı müdahale, şeffaf iletişim ve tekrarını önleyen kalıcı düzeltme. Suçu araca veya sürece atmayın.

Örnek cevap iskeleti: Önceki iş yerimde yaptığım bir değişiklik, gözden kaçan bir uç senaryo yüzünden üretimde bazı kullanıcıları etkileyen bir hataya yol açtı. Fark eder etmez ekibe haber verdim ve önce hızlıca geri alma (rollback) yaparak etkiyi durdurdum. Sonrasında kök nedeni analiz ettim: o senaryoyu kapsayan test yoktu. Düzeltmeyle birlikte eksik testleri ekledim ve ekipçe deployment öncesi kontrol listemize bir madde ekledik. O hatanın benzeri bir daha yaşanmadı.

Olası takip soruları: Rollback mümkün olmasaydı ne yapardınız? · Post-mortem süreçlerinde nasıl bir yaklaşım izliyorsunuz?

Nasıl yaklaşmalı: Öğrenme stratejinizi somutlaştırın: resmi dokümantasyon, küçük prototip, deneyimli birine danışma gibi adımlarınızı ve öğrendiğinizi ne kadar sürede üretime yansıttığınızı anlatın.

Örnek cevap iskeleti: Bir projede daha önce hiç çalışmadığım bir mesaj kuyruğu altyapısını kullanmam gerekti. Önce resmi dokümantasyondan temel kavramları çıkardım, ardından bir günümü küçük bir prototip yazarak geçirdim; takıldığım noktaları bu konuda deneyimli bir ekip arkadaşımla yarım saatlik bir görüşmede netleştirdim. İki hafta içinde ilgili modülü üretime aldık ve yazdığım kısa iç dokümantasyon ekipteki diğer geliştiricilere de referans oldu.

Olası takip soruları: Yeni bir teknolojiye başlarken ilk ne yaparsınız? · Öğrendiklerinizi ekiple nasıl paylaşırsınız?

Nasıl yaklaşmalı: Yapılandırılmış cevap verin: önce genel yaklaşımınızı (etkiyi ölçme, log/monitoring, hipotez kurma, izole etme), sonra yaşadığınız gerçek bir örneği, en sonunda da kalıcı önlemi anlatın.

Örnek cevap iskeleti: İlk adımım etkiyi anlamak olur: kaç kullanıcı etkileniyor, hata ne zaman başladı, yakın zamanda deployment var mı? Sonra loglara ve monitoring verilerine bakarak hatayı zaman ve bileşen olarak daraltırım; hipotezimi mümkünse staging ortamında aynı veriyle doğrularım. Örneğin bir projede sadece belirli saatlerde görülen bir hatayı, loglardaki desenden yola çıkarak zamanlanmış bir işle çakışmaya bağlamıştık. Sorunu çözdükten sonra aynı hatayı yakalayacak bir alarm ve test eklerim ki tekrarında insan gözüne gerek kalmasın.

Olası takip soruları: Loglarda hiçbir iz yoksa nasıl ilerlersiniz? · Sorun sadece üretimde ve yeniden üretilemiyorsa ne yaparsınız? · Hangi monitoring araçlarıyla çalıştınız?

Nasıl yaklaşmalı: Öncelik sıranızı belli edin: doğruluk ve güvenlik gibi kritik konular ile stil tercihleri aynı ağırlıkta değildir. İnsan tarafını da ekleyin: yapıcı üslup ve öğrenme fırsatı.

Örnek cevap iskeleti: Önce büyük resme bakarım: değişiklik gereksinimi karşılıyor mu, tasarım mevcut mimariyle uyumlu mu? Sonra doğruluk ve güvenliğe inerim: uç senaryolar, hata yönetimi, girdi doğrulama ve test kapsamı. Okunabilirlik ve isimlendirme üçüncü katmandır; salt stil tercihlerini ise engelleyici yorum yapmadan öneri olarak bırakırım. Review'u hata avı değil bilgi paylaşımı olarak görürüm; iyi bir çözüm gördüğümde bunu da yorum olarak belirtirim.

Olası takip soruları: Çok büyük bir pull request geldiğinde ne yaparsınız? · Review'da en sık yakaladığınız hata türü nedir?

Nasıl yaklaşmalı: Tanımları kısa tutup karşılaştırmaya ve seçim kriterlerine odaklanın; "duruma göre değişir" deyip kriterlerinizi somutlaştırmanız, tek taraflı savunmadan daha olgun bir cevaptır.

Örnek cevap iskeleti: REST, kaynak tabanlı ve endpoint başına sabit veri döner; GraphQL ise istemcinin ihtiyacı olan alanları tek sorguda seçmesine izin verir. GraphQL, farklı veri ihtiyaçları olan birden çok istemcinin (web, mobil) olduğu ve over-fetching'in sorun yarattığı durumlarda avantajlıdır; buna karşılık cache'leme, rate limiting ve sorgu maliyeti kontrolü ek çaba ister. Basit, kaynak odaklı bir servis veya üçüncü taraflara açılan bir API için REST'in yalınlığını ve olgun araç ekosistemini tercih ederim. Bir projede mobil ekibin ekran başına üç-dört istek yapmak zorunda kalması üzerine GraphQL'e geçişin ciddi fayda sağladığını gördüm.

Olası takip soruları: GraphQL'de N+1 problemini nasıl çözersiniz? · REST API'de versiyonlamayı nasıl yaparsınız?

Nasıl yaklaşmalı: Önce kavramı iş etkisiyle tanımlayın, sonra yönetim yaklaşımınızı (görünür kılma, önceliklendirme, planlı geri ödeme) ve yaşadığınız bir örneği anlatın.

Örnek cevap iskeleti: Teknik borç, hız kazanmak için bilinçli ya da bilinçsiz verilen ödünlerin zamanla geliştirme hızını ve kaliteyi düşürmesidir; asıl tehlike borcun kendisi değil, görünmez kalmasıdır. Ben borcu görünür kılmaktan yanayım: fark edilen her borç için bir kayıt açılır ve iş etkisiyle birlikte not edilir. Önceki iş yerimde sprint kapasitesinin bir bölümünü düzenli olarak borç azaltmaya ayırıyorduk; en sık dokunulan modüllerden başladık ve birkaç ay içinde o modüllerdeki hata sayısı belirgin şekilde düştü. Yeni özellik geliştirirken de dokunduğun yeri biraz daha temiz bırak ilkesini uygularım.

Olası takip soruları: Yönetime teknik borcu nasıl anlatır, kaynak ayrılmasını nasıl sağlarsınız? · Hangi borç ödenmeli, hangisiyle yaşanabilir — nasıl ayırt edersiniz?

Nasıl yaklaşmalı: Katmanlı bir strateji anlatın: birim, entegrasyon ve uçtan uca testlerin rolü, neyi test edip neyi etmediğiniz ve CI sürecindeki yeri. Yüzde saymak yerine riske dayalı düşündüğünüzü gösterin.

Örnek cevap iskeleti: Temelde piramit yaklaşımını izlerim: iş mantığını hızlı ve bol birim testiyle, modüller arası sözleşmeleri entegrasyon testleriyle, kritik kullanıcı akışlarını ise az sayıda uçtan uca testle korurum. Kapsam oranını tek başına hedef yapmam; riskli ve sık değişen kod yollarına öncelik veririm. Testler CI'da her değişiklikte koşar ve kırmızı test varken merge edilmez. Bir projede ödeme akışını bu şekilde katmanlı test altına aldıktan sonra, üretim hatalarının çoğunu daha kod review aşamasında yakalar hâle gelmiştik.

Olası takip soruları: Hiç test edilmemiş eski bir kod tabanına nereden başlarsınız? · TDD hakkında ne düşünüyorsunuz, uyguluyor musunuz?

Nasıl yaklaşmalı: Ölçmeden optimize etmediğinizi vurgulayın: önce ölçüm ve darboğaz tespiti, sonra en yüksek etkili iyileştirme, ardından sonucun doğrulanması. Gerçek bir örnekle destekleyin.

Örnek cevap iskeleti: İlk kuralım tahminle değil ölçümle başlamak: hangi istek yavaş, darboğaz veritabanında mı, uygulamada mı, ağda mı — bunu profiling ve APM verileriyle netleştiririm. Sonra en büyük etkiyi yaratacak iyileştirmeden başlarım; çoğu zaman bu eksik bir indeks, N+1 sorgu ya da cache'lenebilecek tekrarlı bir hesaplamadır. Bir e-ticaret projesinde liste sayfasının yavaşlığını sorgu planına bakarak eksik bir indekse bağlamış, tek indeksle yanıt süresini birkaç kat iyileştirmiştik. Değişiklik sonrası aynı metrikleri tekrar ölçer ve gerilemeyi önlemek için izlemeye alarm eklerim.

Olası takip soruları: Frontend kaynaklı performans sorunlarına nasıl yaklaşırsınız? · Cache kullanırken nelere dikkat edersiniz? · Veritabanı sorgularını nasıl optimize edersiniz?