Offermic
Ücretsiz dene

Yazılım mühendisi mülakat soruları ve cevap verme rehberi

Yazılım mühendisi, Teknoloji ve yazılım. 22 soru.

Güncelleme:

Yazan:

Kısa cevap

Yazılım mühendisi mülakatları neyi ezberlediğini değil, nasıl akıl yürüttüğünü ölçer. Canlı ortam sorunlarında hata ayıklama, tasarım ödünleşimleri, kod incelemesi, teknik borç ve ekip çalışması üzerine sorular bekle. Davranışsal sorulara STAR ile ve gecikme, hata oranı ya da MTTR gibi gerçek metriklerle cevap ver; kavramsal sorularda ödünleşimleri yüksek sesle tart.

Önemli noktalar

  • Mülakatçılar herhangi bir framework ya da dilden çok problem çözme sürecini ve ödünleşimler üzerine akıl yürütmeni puanlar.
  • p99 gecikme ya da hata oranı gibi öncesi ve sonrası rakamları olan iki üç olay ya da hata ayıklama hikâyesi getir.
  • Ne kuracağını söylemeden önce neyi ölçeceğini söyle.
  • Başarısızlıkları açıkça sahiplen; ekip arkadaşlarını ya da 'eski kodu' suçlamak en yaygın uyarı işaretlerinden biridir.
  • Nöbet (on-call), kod incelemesi kültürü ve teknik borcun nasıl önceliklendirildiği hakkında sorular hazırla.

Mülakatçılar ne arıyor

  • Yapılandırılmış bir hata ayıklama yöntemi: yeniden üret, izole et, hipotez kur, doğrula, sonra tekrarını önle
  • Ödünleşimleri adıyla söyleyen tasarım cevapları (tutarlılığa karşı erişilebilirlik, kendin geliştirmeye karşı hazır çözüm, hıza karşı bakım kolaylığı)
  • Testler, izleme ve geri alma planı dahil, canlı ortamdaki kodu sahiplenmek
  • Teknik seçimlerin bir ürün yöneticisinin takip edebileceği netlikte açıklanması
  • Yalnızca yazım hatası yakalamayan, ekibi geliştiren kod incelemesi alışkanlıkları
  • Merak: ihtiyaç duyduğun son yeni dili, aracı ya da alanı nasıl öğrendiğin

Uyarı işaretleri

  • Yayına aldığı bir hata için önceki ekibi, QA'yı ya da 'kötü gereksinimleri' suçlamak
  • Bir tasarım sorusunda ölçeği ya da kısıtları sormadan çözüme atlamak
  • Testleri, belgelemeyi ya da kod incelemesini isteğe bağlı bir yük olarak görmek
  • Bir kesintiyi, sonrasında onu önlemek için neyin değiştiğini söylemeden anlatmak
  • Yalnızca 'biz' demek; böylece mülakatçı adayın bizzat neyi geliştirdiğini anlayamaz
  • Teknolojilerin soruna neden uyduğunu açıklamadan isimlerini saymak

Yanında götürmeye değer rakamlar

  • Bir optimizasyondan önce ve sonra p95/p99 gecikme
  • Bir serviste ya da sürümde hata oranı veya çökme oranı
  • Yönettiğin olaylardan sonra ortalama toparlanma süresi (MTTR)
  • Dağıtım sıklığı ve değişikliklerin canlıya çıkma süresi
  • Sorumlu olduğun modüllerde test kapsamı ve canlıya kaçan hata sayısı
  • Ekibin SLO'suna göre kesintisiz çalışma süresi (uptime) / erişilebilirlik

Sorular

Teknik

  1. 1

    Yalnızca aralıklı olarak ortaya çıkan bir canlı ortam sorununda nasıl hata ayıklayacağınızı adım adım anlatır mısınız?

    İpucu: Önce loglardan, metriklerden ve trace'lerden bahset, sonra kapsamı nasıl daraltıp sorunu güvenle nasıl yeniden üreteceğini anlat.

  2. 2

    Okuma ağırlıklı bir API için önbellek katmanını nasıl tasarlardınız ve neler ters gidebilir?

    İpucu: Geçersiz kılmayı, TTL'leri, cache stampede'i ve önbellek çöktüğünde ne olacağını anlat.

  3. 3

    Bir bileşeni kendiniz geliştirmekle bir kütüphane ya da yönetilen bir servis kullanmak arasında nasıl karar verirsiniz?

    İpucu: Bakım maliyetinden, lisanslamadan, bağımlı kalmaktan (lock-in), ekibin becerilerinden ve değer üretme süresinden bahset.

  4. 4

    Başka birinin pull request'ini incelerken nelere bakarsınız?

    İpucu: Stilin ötesine geç: doğruluk, testler, okunabilirlik, hata senaryoları ve değişikliğin büyüklüğü.

  5. 5

    Her hafta yayına çıkan bir kod tabanında teknik borcu azaltmaya nasıl yaklaşırdınız?

    İpucu: Borç işini teslimattaki sıkıntıya ve riske bağla; baştan yazmayı değil, kademeli refactoring'i anlat.

  6. 6

    Bir değişikliğin dağıtım için güvenli olduğundan nasıl emin olursunuz?

    İpucu: Testlerden, CI'dan, kademeli yayınlardan, feature flag'lerden, izlemeden ve bir geri alma planından bahset.

  7. 7

    API'nin ne olduğunu teknik olmayan bir paydaşa nasıl açıklardınız?

    İpucu: Tek bir sade benzetme kullan ve bir dakikanın altında tut; sınanan şey açıklık.

  8. 8

    Sorumlu olduğunuz bir servis için iyi loglama ve izleme nasıl olmalı?

    İpucu: Yapılandırılmış loglardan, kilit metriklerden, belirtiler üzerine uyarılardan ve başkasının da okuyabileceği panolardan bahset.

Davranışsal

  1. 9

    Düzelttiğiniz en zor hatayı anlatır mısınız? Kök nedeni nasıl buldunuz?

    İpucu: Yanlış çıkan gerçek bir hipotezin olduğu bir hata seç; o çıkmaz sokak yöntemini gösterir.

  2. 10

    Yaptığınız ve bugün farklı yapacağınız bir teknik ödünleşimi anlatın.

    İpucu: O zamanki kısıtlarını göster, sonra hangi yeni bilginin görüşünü değiştirdiğini söyle.

  3. 11

    Bir inceleyicinin kodunuza sert şekilde itiraz ettiği bir anı anlatır mısınız? Ne yaptınız?

    İpucu: Egonu koddan ayırdığını göster ve neyi değiştirdiğini ya da durumu nasıl çözdüğünü söyle.

  4. 12

    İçinde yer aldığınız bir kesintiyi ya da olayı ve postmortem'in neyi değiştirdiğini anlatır mısınız?

    İpucu: Etkiyi ve MTTR'yi rakamla söyle ve bir uyarı ya da test gibi kalıcı bir düzeltmeyi adıyla belirt.

  5. 13

    Bir sistemin performansını iyileştirdiğiniz bir durumu anlatın. Bunu nasıl ölçtünüz?

    İpucu: Başlangıç değerini, profil çıkarma adımını ve sonucu ver; örneğin p99'un 900 ms'den 250 ms'ye inmesi.

  6. 14

    Bir şeyi teslim etmek için yeni bir teknolojiyi hızla öğrenmek zorunda kaldığınız bir anı anlatır mısınız?

    İpucu: Yalnızca öğrendiğini değil, nasıl öğrendiğini açıkla: belgeler, prototipler, bir uzmana sormak.

  7. 15

    Junior bir geliştiricinin gelişmesine nasıl yardım ettiniz?

    İpucu: Eşli programlama ya da öğreten inceleme yorumları gibi somut bir uygulamayı ve sonucunu anlat.

Durumsal

  1. 16

    Bir dağıtımdan sonra hata oranları fırladığı için gece saat 2'de çağrı alıyorsunuz. İlk adımlarınız neler?

    İpucu: Önce etkiyi azalt (geri al ya da feature flag ile kapat), durumu bildir, sonra araştır.

  2. 17

    Ürün yöneticiniz, sizin beş hafta sürer diye tahmin ettiğiniz bir özelliği iki haftada istiyor. Ne yaparsınız?

    İpucu: Sadece evet ya da hayır demek yerine ödünleşimleriyle birlikte kapsam seçenekleri sun.

  3. 18

    Bir ekip arkadaşınız ölçeklenmeyeceğine inandığınız bir tasarımda ısrar ediyor. Bunu nasıl ele alırsınız?

    İpucu: Anlaşmazlığı verinin çözmesi için kısa bir deneme (spike), bir benchmark ya da yazılı bir tasarım belgesi öner.

  4. 19

    Zaten canlı ortamda olan kodda bir güvenlik açığı keşfediyorsunuz. Ne yaparsınız?

    İpucu: Ciddiyetini değerlendir, doğru kanaldan bildir, yamayı yap ve açığı herkese açık şekilde ifşa etmekten kaçın.

Motivasyon

  1. 20

    Neden özellikle bizim ürün ve mühendislik ekibimizde çalışmak istiyorsunuz?

    İpucu: Şirketin karşı karşıya olduğu gerçek bir teknik zorluğu yaptığın ya da yapmak istediğin işe bağla.

  2. 21

    Hangi tür mühendislik problemleri size en çok enerji veriyor?

    İpucu: Somut ol (güvenilirlik, geliştirici araçları, kullanıcıya dönük arayüz) ve yakın zamandan bir örnek ver.

  3. 22

    Önümüzdeki iki yılda teknik olarak hangi yönde gelişmek istiyorsunuz?

    İpucu: Sistem tasarımı ya da teknik liderlik gibi bir yön söyle ve bunun için şu anda ne yaptığını anlat.

Bu pozisyon için bir iş ilanını ücretsiz iş ilanı aracına yapıştır ve işaret ettiği soruları gör

Yazılım mühendisi mülakat soruları, problemleri nasıl düşündüğüne odaklanır: canlı ortamdaki bir sorunda hata ayıklamak, tasarımlar arasında seçim yapmak, kod incelemek, olayları yönetmek ve bir ekiple çalışmak. En güçlü cevaplar akıl yürütmeni adım adım açıklar, ödünleşimleri adıyla söyler ve sonuçları gecikme, hata oranı ya da toparlanma süresi gibi rakamlarla destekler.

Yazılım mühendisi mülakatları gerçekte neyi ölçer?

ABD Çalışma İstatistikleri Bürosu (BLS), yazılım geliştiricileri “bilgisayar uygulamaları ya da programları tasarlayan” kişiler olarak tanımlıyor (kaynak İngilizce, çeviri bize ait). Büro, ABD’de geliştiriciler, QA analistleri ve test uzmanları için istihdamın 2025-2035 arasında %10 artmasını bekliyor. Mülakatlarda araç listelerinin ötesine bakan ve muhakemeni yoklayan sorular bekle.

Sözlü turlarda genellikle dört şeyi sınarlar:

  • Problem çözme yöntemi. Belirsiz bir sorunu adımlara bölüp hipotezleri test edebiliyor musun?
  • Ödünleşimler üzerine akıl yürütme. Önerdiğin dahil, her seçimin bedelini görüyor musun?
  • Sahiplenme. Testleri, izlemeyi, yayını ve geri almayı düşünüyor musun, yoksa işin merge’de mi bitiyor?
  • İletişim. Bir ürün yöneticisi ya da yeni bir ekip arkadaşı açıklamanı takip edebiliyor mu?

Kabaca davranışsal sorular (geçmiş olaylar, çatışmalar, mentorluk), kavramsal teknik sorular (“Buna nasıl yaklaşırdınız…”), durumsal sorular ve birkaç motivasyon sorusundan oluşan bir karışım bekle. Teknoloji sektörü rehberimiz mühendislik, veri ve DevOps rollerindeki genel örüntüyü anlatıyor.

Kavramsal teknik sorulara nasıl cevap vermelisin?

Onları bir sınav değil, bir sohbet olarak gör. Güvenilir bir kalıp:

  1. Netleştir. Ölçeği, kullanıcıları, kısıtları ve “bitti”nin ne anlama geldiğini sor.
  2. Hedefi ve metriği söyle. “Saniyede 5.000 istekte p99’un 300 ms’nin altında olmasını istiyoruz.”
  3. İki seçenek sun ve onları dürüstçe karşılaştır.
  4. Birini seç ve fikrini neyin değiştireceğini söyle.
  5. Risklerle bitir: hata senaryoları, izleme, geri alma.

Burada yüksek sesle düşünmek bir zayıflık değildir. Sessizliğin ardından gelen kusursuz bir cevap, mülakatçıya bir kez rota düzelten görünür bir süreçten daha az şey söyler.

Mühendis olarak davranışsal sorulara nasıl cevap verirsin?

STAR yöntemini kullan ve Durum kısmını kısa tut. Yaygın bir hata, cevabın çoğunu bağlama ve küçük bir kısmını ne yaptığına ayırmaktır; bunu tersine çevir. Kendi eylemlerin için “ben” de ve ölçülebilir bir sonuçla ve sonrasında neyin değiştiğiyle bitir.

Yaygın davranışsal sorular, muhtemelen zaten sahip olduğun hikâyelerle eşleşir:

Soru Kullanılacak hikâye
Çözdüğün karmaşık bir problem En zor hatan ya da performans düzeltmen
Bir hata ve ondan çıkan ders Kötü giden bir dağıtım ya da gözden kaçan bir uç durum
Bir ekip arkadaşıyla çatışma Verilerle çözülen bir tasarım anlaşmazlığı
Birine mentorluk yapmak Junior bir geliştiriciyi işe alıştırmak ya da onunla eşli çalışmak

Örnek STAR cevabı: aralıklı bir canlı ortam hatası

Örnek cevap: orta kıdemli backend mühendisi, soru: “Düzelttiğiniz en zor hatayı anlatır mısınız?”

  1. Durum

    Ödeme servisimiz rastgele zamanlarda ödeme isteklerinin yaklaşık %2'sinde hata vermeye başladı. Sorun yerelde hiç tekrar üretilemiyordu ve destek talepleri artıyordu.

  2. Görev

    O hafta nöbetçi bendim; yani ekibin geri kalanı için dağıtımları dondurmadan kök nedeni bulmak ve hataları durdurmak benim sorumluluğumdaydı.

  3. Eylem

    Loglara istek ID'leri ekledim ve hataları bir trace görünümüyle ilişkilendirdim. Hatalar, boşta kalınan sürelerden sonra belirli bir bağlantı havuzuna giden isteklerde yoğunlaşıyordu. İlk hipotezim, yani ödeme sağlayıcısında bir zaman aşımı, yanlış çıktı. Ardından staging ortamında havuzu boşta bırakarak sorunu yeniden ürettim, bayat bağlantıların yeniden kullanıldığını doğruladım ve bağlantıları kullanmadan önce doğrulayan bir düzeltmeyi bir feature flag arkasında yayına aldım.

  4. Sonuç

    Ödeme hataları bir gün içinde yaklaşık %2'den %0,1'in altına düştü. Postmortem'i yazdım, bağlantı hataları için bir uyarı ve bir regresyon testi ekledim; aynı türden bir hata bir daha yaşanmadı.

Neden işe yarıyor: bir yöntem gösteriyor (ölçüm ekle, ilişkilendir, hipotez kur, doğrula), yanlış bir tahmini kabul ediyor ve rakamlarla ve önlemle bitiyor.

Mülakatçıya hangi soruları sormalısın?

İyi sorular, asıl işi düşündüğünü gösterir. İki üç tane seç:

  • “Burada nöbet sistemi nasıl işliyor, mühendisler ne sıklıkla çağrılıyor?”
  • “Bir değişiklik pull request’ten canlı ortama nasıl ulaşıyor?”
  • “Teknik borca ne zaman vakit ayıracağınıza nasıl karar veriyorsunuz?”
  • “Bu pozisyonda iyi geçmiş bir ilk altı ay sizce neleri içerir?”
  • “Ekibin bu yıl karşı karşıya olduğu en büyük teknik zorluk ne?”
  • “Tasarım kararları nasıl belgeleniyor ve inceleniyor?”

Daha fazla seçenek için mülakatçıya sorulacak sorular rehberimize bak.

Nasıl pratik yapmalısın?

Cevaplarını yüksek sesle söyle. Yazılı notlar, konuştuğunda belli olan lafı dolandırmayı gizler. Yukarıdaki listeden üç soruyu cevaplarken kendini kaydet, her cevabın sonuç kısmında bir rakam olup olmadığını kontrol et ve Durum kısmını iki cümleye indir. Mülakata nasıl hazırlanılır rehberimizde bir haftalık bir plan var; bir şirket tek yönlü video ön elemesi kullanıyorsa video mülakat ipuçlarını da oku.

Özellikle frontend rollerine başvuruyorsan frontend geliştirici soruları tarayıcılara, erişilebilirliğe ve arayüz performansına daha derin iniyor.

Sık sorulan sorular

Yazılım mühendisi mülakatlarında her zaman canlı kodlama olur mu?

Birçoğunda olur ama çoğu mülakat turunun büyük kısmı sohbete dayanır: davranışsal sorular, sistem ve tasarım tartışmaları ve hata ayıklama senaryoları. Bu sayfa, net akıl yürütmeyi ve somut örnekleri ödüllendiren bu sözlü turlara odaklanıyor.

Bir yazılım mühendisliği mülakatı için kaç hikâye hazırlamalıyım?

Bir olayı, zor bir hatayı, bir anlaşmazlığı, bir ödünleşimi, bir mentorluk anını, bir başarısızlığı ve gurur duyduğun bir projeyi kapsayan beş ila yedi hikâye hazırla. Çoğu davranışsal soru bunlardan biriyle cevaplanabilir.

Bir yazılım mühendisi hangi metriklerden bahsetmeli?

Gerçekten takip ettiğin rakamları kullan: gecikme, hata oranı, çalışma süresi, dağıtım sıklığı, MTTR, test kapsamı ya da dönüşüm gibi kullanıcıya dönük metrikler. Tek bir gerçek rakam üç belirsiz iddiadan iyidir.

Kaynaklar

  1. Software Developers, Quality Assurance Analysts, and Testers: Occupational Outlook Handbook, U.S. Bureau of Labor Statistics

Yazan:, Kurucu ve geliştirici

Ken Garry bu uygulamanın kurucusu ve geliştiricisi. Yapay zekâ ile mülakat provası ürününü geliştiriyor ve mülakat hazırlığı rehberlerini yazıyor.

Nasıl yazıyoruz