Yıllarca yüzlerce teknik iş görüşmesi yaptım. Sayısız adayla konuştum, bazen aynı gün içinde on kişiyi dinlediğim oldu. Çoğu adayın ezberlenmiş teknik cevaplar verdiğini, “best practices” listelediğini gördüm. Ancak kariyerimde beni gerçekten derinden etkileyen, aklımda kalan tek bir aday oldu. O gün anladım ki, iyi bir aday sadece bildiklerini değil, bilmediklerini ve nasıl öğrendiğini de iyi anlatmalı.
Bu adayın diğerlerinden farkı neydi? Sadece doğru cevaplar vermedi; sorularıma derinlemesine bir anlayışla yaklaştı, hatalarını saklamadı ve her şeyden önemlisi, bir sistemin sadece koddan ibaret olmadığını çok iyi kavramıştı. Benim için bir adayda aradığım en önemli özellik, sadece bir problemi çözmek değil, o problemin kök nedenini anlamak ve bir daha yaşanmaması için ne yaptığını anlatabilmek.
Teknik Bilgi Mi, Gerçek Anlayış Mı?
Çoğu aday teknik bir soru sorduğumda, o konuyu kitaplardan veya dokümantasyondan nasıl ezberlediyse öyle anlatır. Örneğin, “PostgreSQL’de index çeşitleri nelerdir?” diye sorduğumda, B-tree, GIN, BRIN gibi index türlerini sayıp, hangi senaryoda hangisinin daha iyi olduğunu genel geçer ifadelerle dile getirirler. Bu iyi bir başlangıç ama yeterli değil.
Beni etkileyen aday ise, index türlerini saydıktan sonra “bir üretim ERP’sinde, belirli bir raporun yavaş çalıştığını fark ettim” diye başladı. “Loglara baktığımda seq scan gördüm, EXPLAIN ANALYZE ile sorguyu inceledim ve B-tree index’in neden yetersiz kaldığını anladım. Ardından, JSONB alanındaki filtrelemeler için GIN index kurdum ve sorgu süresini 30 saniyeden 200 milisaniyeye düşürdüm.” dedi. İşte bu, gerçek bir deneyimdi ve neyi, neden yaptığını çok net gösteriyordu.
Hata Yapmaktan Çekinmeyen Bir Bakış Açısı
İş görüşmelerinde adayların en çekindiği konulardan biri, hata yaptıklarını itiraf etmek. Halbuki benim gibi 20 yıldır bu işin içinde olan biri için hata yapmak, öğrenme sürecinin doğal bir parçasıdır. Önemli olan hatayı saklamak değil, hatadan ne ders çıkardığınızı göstermektir.
Bu özel aday, bir soru üzerine “Geçen yıl bir CI/CD pipeline’ı yazarken, sleep 360 komutunu kullandığım bir adımda sürekli OOM-killed oluyordu” dedi. “İlk başta anlamadım, çünkü belleği tüketecek bir işlem yapmıyordum. Sonra fark ettim ki, bu bir polling mekanizmasıydı ve sürekli boşta beklemek yerine, wait komutuyla bir önceki adımın tamamlanmasını beklemeliydim. Bu hatam yüzünden, systemd timer’ların reliability’si hakkında daha derinlemesine araştırma yapmam gerektiğini anladım.” Bu itiraf, bana onun problem çözme yeteneğini, dürüstlüğünü ve öğrenme isteğini gösterdi.
Sistem Perspektifi: Sadece Kod Değil, İş Akışı
Benim için yazılım mimarisi çoğu zaman sadece koddan ibaret değildir; organizasyonel akışları, iş süreçlerini ve farklı sistemlerin birbiriyle nasıl etkileşimde olduğunu anlamaktır. Bir adaydan sadece kendi uzmanlık alanını değil, o alanın bütüne nasıl hizmet ettiğini anlamasını beklerim.
Adaya bir bankanın iç platformunda karşılaştığımız bir event-sourcing probleminden bahsettim. Sistemin neden karmaşıklaştığını, eventual consistency sorunlarını sordum. O da sadece teknik terimlerle değil, “bir müşterinin para transferi talebinin, muhasebe kayıtlarına yansımasıyla eş zamanlı olmaması durumunda oluşabilecek finansal riskleri” anlatarak konuyu ele aldı. Bu, sadece event-sourcing’i bilmek değil, onun iş üzerindeki kritik etkilerini de kavramak demekti. Bu seviyede bir anlayış, bir geliştiricinin sadece kod yazan değil, işi anlayan bir mühendis olduğunu gösterir.
Merak ve Öğrenme İsteği: Gerçek Gelişim Motoru
Görüşmenin sonunda, “Sizin bana sormak istediğiniz bir soru var mı?” diye sorduğumda, çoğu aday maaş, çalışma saatleri veya pozisyonun tanımı gibi konulara odaklanır. Bu doğaldır, ancak beni etkileyen aday çok farklı bir soru sordu.
“Bir üretim firmasının ERP’sinde, AI ile üretim planlama konusunda nasıl bir yol izliyorsunuz? Özellikle tedarik zinciri entegrasyonunda ne gibi zorluklarla karşılaştınız?” diye sordu. Bu soru, benim kendi deneyimlerimle, özellikle de bir üretim ERP’sinde karşılaştığım iSCSI tedarik zinciri entegrasyonu ve AI ile üretim planlama çabalarımla doğrudan ilgiliydi. Bu, sadece pozisyonla ilgili değil, şirketin ve teknolojinin geleceğiyle ilgili gerçek bir merakı gösteriyordu. Onunla bir saat daha teknik tartışma yapabilirdim.
Sonuç: Adayda Ne Arıyorum?
Özetle, iş görüşmesinde beni en çok etkileyen aday, teknik bilgiyi ezberlemiş olandan çok, o bilgiyi gerçek hayat problemlerine uygulayabilen, hatalarından ders çıkaran, sistemin büyük resmini gören ve sürekli öğrenmeye açık olan kişiydi. O gün anladım ki, bir adayın CV’sindeki “başarılar” kadar, o başarıların arkasındaki “nasıl” ve “neden” sorularına verdiği cevaplar çok daha değerli.
Siz bir iş görüşmesinde en çok neyden etkilendiniz? Ya da sizi en çok etkileyen aday hangi özelliklere sahipti? Yorumlarda paylaşın, merak ediyorum.