İlk yazılım işini bulmak: junior geliştirici için portföy, GitHub ve ağ

"İlk yazılım işi" diye arama yapıyorsan büyük ihtimalle şu döngünün içindesin: İlanlar deneyim istiyor, deneyim için de iş lazım. Döngü gerçek, ama sandığın kadar kapalı değil.

Junior bir adaya bakan teknik lider çoğu zaman tek bir şeyi anlamaya çalışır: Bu kişi ekibe girdiğinde küçük bir işi, gerektiğinde yardım isteyerek ama sahiplenerek, baştan sona bitirebilir mi?

Bu yazıdaki her adım o soruya kanıt üretmekle ilgili. Sertifika sayısı ya da ezberlenmiş framework listesi değil; görülebilen, hakkında soru sorulabilen ve birinin kefil olabildiği iş.

Önce hedefi daralt

"Yazılım işi" çok geniş bir tarif. Frontend, backend, mobil, veri, DevOps... Hepsine aynı anda hazırlanmaya çalışırsan hepsinde yüzeysel kalırsın.

Pratik bir yol: Sana ilginç gelen 15–20 junior ilanı topla ve ortak geçen teknolojileri not et. Backend ilanlarında aynı dil, bir ilişkisel veritabanı, Git ve REST API sürekli tekrar ediyorsa portföyünün omurgası bunlar olmalı.

İlan okurken şunu da aklında tut: "Aranan nitelikler" listesi çoğu zaman ideal adayın tarifidir. Maddelerin büyük kısmını karşılıyor ve geri kalanını öğrenebileceğini gösterebiliyorsan başvurmaktan çekinme.

Portföy: az ama derin

On yarım proje, iki bitmiş projenin yerini tutmaz. Hedefin 2–3 proje olsun ve her biri şu soruları cevaplasın:

• Ne yapıyor, kimin için? README'nin ilk iki cümlesi bunu söylemeli.
• Nasıl çalıştırılır? Birisi repoyu klonlayıp makul bir sürede ayağa kaldırabilmeli. Gerekli ortam değişkenleri için bir .env.example dosyası koy, gerçek anahtarları asla commit'leme.
• Canlıda görebilir miyim? Küçük bir sunucuya ya da ücretsiz bir barındırma servisine konmuş çalışan bir link, ekran görüntüsünden çok daha ikna edicidir.
• Hangi kararları verdin? "Neden bu veritabanı, neden bu yapı?" sorularına README'de birkaç cümleyle cevap ver. Mülakatta tam olarak bunlar sorulur.

Eğitim videosundan çıkan projeler yasak değil, ama tek başına yetmez. Bir eğitimden çıkan uygulamayı aldıysan üstüne kendi özelliğini ekle, testini yaz ve README'de "eğitimden sonra şunları ben ekledim" diye açıkça belirt. Burada dürüstlük avantajdır.

Mümkünse projelerden biri ekipli olsun. İş hayatında kod tek başına yazılmıyor; issue açmak, branch'te çalışmak, pull request göndermek ve review almak başlı başına bir beceri. Bunu gösterebilen bir junior, işe başladığı ilk haftalarda çok daha az yeni şeyle boğuşur.

GitHub profilini okunur yap

Profiline bakacak kişinin ayıracağı süre kısa olabilir. O süreyi iyi kullan:

1. Profil README'si ekle. Kullanıcı adınla aynı isimde, herkese açık bir repo oluşturup köküne README.md koyduğunda GitHub bu dosyayı profilinin en üstünde gösterir. Kim olduğunu, neyle uğraştığını ve öne çıkan projelerini birkaç satırda yaz.
2. En iyi işlerini sabitle. Profiline repo ve gist toplamında altı öğe sabitleyebilirsin. Yarım kalmış denemeleri değil, README'si düzgün projeleri seç.
3. Commit geçmişin bir hikâye anlatsın. "update", "fix", "son hali" yerine "Giriş formuna e-posta doğrulaması ekle" gibi mesajlar, nasıl çalıştığını kodu açmadan bile gösterir.
4. Gizli bilgi sızdırma. API anahtarı ya da şifre içeren bir commit, profilinde akılda kalan tek şey olabilir. Bir sızıntı fark edersen dosyayı silmek yetmez; o anahtarı iptal edip yenisini üret.

Her güne yeşil kare yetiştirmeye çalışmana gerek yok. Anlamsız günlük commit'ler yerine haftada birkaç anlamlı değişiklik çok daha iyi görünür.

CV: tek sayfa, her satır bir kanıta bağlı

Junior CV'lerinde sık rastlanan bir sorun, uzun bir teknoloji listesi ve altında hiçbir kanıt olmaması. Bunun yerine her proje ya da deneyim satırını şöyle kur:

• Ne yaptın (bir fiille başla)
• Hangi teknolojiyle
• Sonuç ya da link

Örnek: "Kayıp eşya uygulaması için Kotlin ve Spring Boot ile REST API yazdım; testler her pull request'te GitHub Actions ile çalışıyor (link)."

"Yetkinlikler" bölümüne yalnızca mülakatta beş dakika konuşabileceğin şeyleri yaz. Bir kez kurulumunu yaptığın bir aracı listeye eklemek, cevaplayamayacağın bir soruya kapı açar.

Referans: kodunu görmüş biri

Referans, seni sevdiği için değil, çalışmanı gördüğü için konuşabilen kişidir. Junior biri için bu kişiler genelde şunlardır:

• Proje dersinde ya da bitirme projesinde danışmanın olan hoca
• Staj yaptıysan seni yöneten kişi
• Bir ekip projesinde pull request'lerini review eden kişi
• Katkı yaptığın açık kaynak projenin bakımcısı

Son ikisini küçümseme. Kodunu satır satır okumuş biri "zamanında teslim etti, geri bildirime iyi cevap verdi, takıldığında sordu" diyebilir. Junior alımında bu tür gözlemler çok değerlidir.

Referans göstermeden önce mutlaka kişiye sor ve birlikte yaptığınız işi kısaca hatırlat. İnsanlar yoğun; sana kefil olmalarını kolaylaştır.

Ağ: ilan çıkmadan önce tanınmak

"Network" kelimesi kulağa satış gibi gelebilir ama özünde şu: Ne yaptığını bilen insan sayısını artırmak. Bunun en doğal yolları:

• Buluşmalara ve topluluklara git. Konuşma dinlemek iyi, ama asıl değer sonrasında bir kişiyle beş dakika gerçekten sohbet etmekte.
• Öğrendiğini paylaş. LinkedIn'de ya da kendi blogunda "bu hafta şu hatayı şöyle çözdüm" türü kısa yazılar, seni araştıran biri için iz bırakır.
• Yardım et. Bir toplulukta başkasının sorusuna cevap vermek, senin soruna cevap verilmesini de kolaylaştırır.

Çalışmak istediğin bir şirketteki bir geliştiriciye yazacaksan mesajı kısa, somut ve kolay cevaplanabilir tut:

Merhaba, ekibinizin geçen ay yayımladığı mimari yazısını okudum. Backend tarafında junior pozisyon arıyorum; Kotlin ve PostgreSQL ile bir kayıp eşya API'si üzerinde çalıştım (link). Ekibinizde junior birinden ilk aylarda en çok ne beklendiğini iki cümleyle paylaşabilir misiniz?

İş istemiyorsun, bilgi istiyorsun. İnsanlar bu tür sorulara çok daha kolay cevap verir ve bu sohbetler zamanla bir tanışıklığa dönüşebilir.

Başvuru ve mülakat

İlanları LinkedIn, Kariyer.net ve Youthall gibi platformlarda, ayrıca doğrudan şirketlerin kariyer sayfalarında takip edebilirsin. Başvurduğun her yeri tarih, pozisyon ve sonraki adımla basit bir e-tabloda tut. Birkaç hafta sonra hangi tür başvurunun dönüş aldığını görmeye başlarsın.

Mülakatlarda junior adaydan genelde her şeyi bilmesi beklenmez. Beklenen şunlar:

• Kendi projeni baştan sona anlatabilmek. "Bu istek geldiğinde hangi katmanlardan geçiyor?" sorusuna takılmadan cevap verebilmelisin.
• Sesli düşünmek. Canlı kodlamada sessizce takılmak yerine ne denediğini ve neden denediğini anlat.
• "Bilmiyorum ama şöyle araştırırdım" diyebilmek. Uydurmak, bilmemekten çok daha kötü sonuç verir.

Ret alacaksın; bu sürecin normal bir parçası. Mümkün olduğunda kısa bir geri bildirim iste ve her retten sonra bir şeyi düzelt.

Dört haftalık başlangıç planı

Hepsini aynı anda yapamazsın. Şöyle bir sıra deneyebilirsin:

1. 1. hafta: Hedef rolü seç, 15 ilan topla, ortak teknolojileri çıkar. GitHub profil README'ni yaz.
2. 2. hafta: En iyi projenin README'sini yeniden yaz, projeyi canlıya al, .env.example ekle.
3. 3. hafta: CV'yi tek sayfaya indir, her satırı bir linke bağla. İki olası referansla konuş.
4. 4. hafta: Bir buluşmaya git ya da bir topluluğa katıl; hedefli başvurularına başla ve takip tablonu tutmaya devam et.

Son söz

İlk işi bulmak çoğu zaman birbirine eklenen küçük kanıtlarla oluyor: bitmiş bir proje, okunur bir profil, kodunu görmüş bir insan. Bunların özellikle sonuncusunu tek başına üretmek zor.

İzmir'de kurulmuş bir topluluk olan re:make'te üyeler projelerde issue, pull request ve review ile birlikte çalışıyor; üyelik ücretsiz ve deneyim seviyesi fark etmiyor. Kodunu okuyacak birilerini arıyorsan pazar 15.00'te Buca'daki buluşmaya gel ya da kısa başvuru formunu doldur.