Yazılımcı Portföyü ve Mülakat Hazırlığı: Nelere Bakılıyor?

Yazılımcı portföyü, işe alım sürecinde özgeçmişten daha güçlü bir belgedir; çünkü söylediklerinizi değil yaptıklarınızı gösterir. Ancak çoğu portföy, kurs projelerinin bir listesine dönüşür ve fark yaratmaz. Bu yazıda hem portföyü hem de mülakat hazırlığını, karşı taraftan bakarak ele alıyoruz.

Portföyde ne aranıyor?

İnceleyen kişi, projeye ortalama iki-üç dakika ayırır. Bu sürede şu sorulara cevap arar: bu ne işe yarıyor, çalışıyor mu, kodu okunabilir mi, kişi hangi kararları vermiş?

Bu yüzden depodaki açıklama dosyası, kodun kendisi kadar önemlidir. İlk cümlede projenin ne yaptığı yazmalı, ardından ekran görüntüsü, kurulum adımları ve varsa canlı bağlantı gelmelidir. Kurulum için beş komut gerekiyorsa, çoğu inceleyici denemeden geçer.

Hangi projeler seçilmeli?

• Veri odaklı bir uygulama: Giriş, yetkilendirme, listeleme, form ve raporlama içeren bir panel. Gerçek iş uygulamalarının iskeletini bildiğinizi gösterir.
• Dış servis entegrasyonu: Bir API’den veri çeken, hata durumlarını yöneten bir uygulama. Gerçek dünyanın belirsizliğiyle çalışabildiğinizi gösterir.
• Kişisel bir problem çözen proje: Kendi ihtiyacınız için yazdığınız araç. Motivasyonunuzu ve düşünme biçiminizi gösterir.

Öğreticiden birebir yapılmış projeler bu üçünün yanında zayıf kalır; çünkü sizin verdiğiniz bir karar içermezler.

Kararlarınızı görünür kılın

Portföyü sıradanlıktan çıkaran en etkili yöntem, kararların kısa gerekçesini yazmaktır. "Neden ilişkisel veritabanı kullandım", "neden bu yapıyı seçtim", "hangi yaklaşımı denedim ve neden vazgeçtim" gibi birkaç paragraf, teknik olgunluğu koddan daha net gösterir.

İşe alım tarafında sık duyulan cümle: Kodun kendisinden çok, kişinin neden öyle yazdığını açıklayabilmesi belirleyici oluyor.

Özgeçmiş: somut olun

Teknoloji listesi sıralamak yaygın ama zayıf bir yaklaşımdır. Bunun yerine her madde şu yapıda olmalıdır: ne yaptınız, hangi araçla, sonuç ne oldu. "Raporlama sayfasının sorgularını yeniden düzenleyerek yüklenme süresini 8 saniyeden 1 saniyeye indirdim" cümlesi, on satırlık bir teknoloji listesinden daha fazlasını anlatır.

Uzunluk konusunda kural basittir: iki sayfayı geçmeyin, en alakalı bilgiyi en üste koyun ve okunmayacak bölümleri (ilgisiz kurslar, uzun kişisel açıklamalar) çıkarın.

Teknik mülakat: süreç değerlendiriliyor

Teknik mülakatta doğru cevaba ulaşmak tek ölçüt değildir. Değerlendirilen şey düşünme sürecidir. Bu yüzden sessizce düşünmek yerine yüksek sesle düşünmek gerekir.

İyi bir yaklaşım şu sırayı izler: soruyu netleştirmek için soru sorun (girdi ne kadar büyük, hangi durumlar geçerli), varsayımlarınızı söyleyin, basit bir çözümle başlayın, çalıştığından emin olun, ardından iyileştirin. Baştan en optimal çözümü bulmaya çalışmak, çoğu zaman hiçbir çözüme ulaşamamakla sonuçlanır.

Sorulacak sorular ve kırmızı bayraklar

Mülakat çift yönlüdür. Sizin de sormanız gereken sorular vardır: kod incelemesi yapılıyor mu, test kültürü nasıl, yayın süreci nasıl işliyor, mesai dışı çağrı beklentisi var mı, yeni gelen biri ilk ayında nasıl yönlendiriliyor?

Bu soruların cevapları çalışma ortamı hakkında ilanlardan çok daha fazlasını anlatır. "Burada herkes çok esnek çalışır" veya "acil işler olur, hep beraber hallederiz" gibi belirsiz cevaplar, genellikle plansızlığın işaretidir.

Uzaktan ve hibrit çalışmada değerlendirme

Uzaktan çalışılan pozisyonlarda değerlendirme ölçütleri kısmen değişir. Teknik yeterliliğin yanında yazılı iletişim becerisi belirleyici hâle gelir; çünkü işin büyük bölümü mesajla, görev açıklamalarıyla ve kod inceleme yorumlarıyla yürür.

Bu nedenle mülakat öncesinde gönderdiğiniz mesajlar, birleştirme isteği açıklamalarınız ve varsa blog yazılarınız da değerlendirmenin parçasıdır. Net, kısa ve bağlam veren yazı yazabilmek, uzaktan çalışan bir ekipte doğrudan verimlilik demektir.

İkinci fark, öz yönetimdir: işi parçalara bölebilmek, tıkandığında zamanında yardım isteyebilmek ve durumu güncel tutmak. Mülakatta bunlarla ilgili örnek vermek, teknik cevaplar kadar etkili olur.

İlk işten sonrası: kariyer birikimi

Uzun vadede fark yaratan şey, öğrenilen teknoloji sayısı değil, çözülen problemlerin çeşitliliğidir. Performans sorunu çözmüş, üretim hatası düzeltmiş, başkasının kodunu devralmış ve yeni birine mentorluk yapmış bir geliştirici, aynı süreyi tek tip işle geçirmiş birinden belirgin biçimde öndedir. Sektördeki genel eğilimler için Stack Overflow geliştirici anketi yıllık olarak izlenebilir.

Sonuç

Portföyünüz, ne bildiğinizden çok nasıl düşündüğünüzü göstermelidir. Üç bitmiş projeyi özenle sunun, kararlarınızı yazıya dökün, özgeçmişte somut sonuçlar verin ve mülakatta süreci sesli yürütün. Bu yaklaşım, uzun teknoloji listelerinden çok daha güçlü bir izlenim bırakır.