Bir yazılım portföyü, CV’deki iddiaları somutlaştıran bir “kanıt paketi” gibi çalışır: Ne yaptığınızı, nasıl düşündüğünüzü ve kodunuzu başkalarının nasıl kullanabileceğini gösterir. Birçok şirkette teknik değerlendirmeler (ör. canlı kodlama veya ev ödevi) hâlâ sürecin önemli bir parçasıdır; bu tür aşamalarda portföy, değerlendirmeye giden yolu kısaltan bir güven sinyali olabilir. Ancak portföyün ağırlığı şirket, rol ve başvuru hacmine göre değişir; bazı süreçlerde ilk eleme hâlâ CV/ATS üzerinden yapılabilir. Bu nedenle hedef, “herkesi etkileyecek dev bir vitrin” değil, hızlı taranabilen ve görüşmede konuşulabilir bir proje seti oluşturmaktır.

Bu yazı bilgilendirme amaçlı kariyer rehberidir; işe alım kriterleri firmaya göre değişir. Aşağıdaki adımlar, portföyünüzü daha anlaşılır, doğrulanabilir ve görüşme odaklı hale getirmeniz için pratik bir çerçeve sunar.

İşe alım ekipleri portföyde ne arar?

İşe alım ekiplerinin portföye bakma motivasyonu genellikle şunlara dayanır:

• Problem çözme yaklaşımı: Belirsiz bir problemi nasıl parçalara ayırdınız, hangi kısıtlar vardı, hangi trade-off’ları seçtiniz?
• Kodun sürdürülebilirliği: Okunabilirlik, modüler yapı, test/linters, hata yakalama, temel güvenlik önlemleri.
• Üretime yakınlık: Kurulum talimatı, örnek veri, yapılandırma, sürümleme, küçük de olsa dağıtım (demo) ve izlenebilirlik.
• İletişim: README ve kısa bir case study ile “ne, neden, nasıl” anlatımı.
• Özgünlük ve şeffaflık: Ekip projesiyse sizin katkınız net mi, dış kütüphaneler/lisanslar doğru mu?

Teknik değerlendirmelerin işe alım süreçlerinde yerini koruduğuna dair genel görünüm için CoderPad’in raporlarına bakabilirsiniz: State of Tech Hiring 2026.

Portföyün omurgası: “Hub” mantığı (GitHub + kısa vitrin)

Genel kitle için en pratik kurgu, GitHub’ı merkez (hub) alıp, isterseniz tek sayfalık bir kişisel site/Notion sayfası ile “vitrin” oluşturmaktır. Uygulamada, başvuruda paylaşılan proje linkleri (sıklıkla GitHub depoları) hızlı bir ilk taramadan geçer; bu yüzden profilinizin ve sabitlenmiş projelerinizin birkaç saniyede net sinyal vermesi değerlidir.

GitHub profilinizi 10 dakikada güçlendirin

• Profil başlığı (bio): Hedef rol + güçlü yan + odak alanı (ör. “Backend | API tasarımı | TypeScript/Node”).
• Profile README: Kısa özet, seçili projelere bağlantı, iletişim, odak teknolojiler.
• Pinned repositories: 3–6 repo sabitleyip “en iyi çalışmalarınızı” en üste alın.
• Güvenlik ve hesap hijyeni: Hesabınızı güvenceye almak (ör. güçlü kimlik doğrulama seçenekleri, gizlilik ayarları) ve repo’larda gizli anahtar/secrets bulundurmamak.

GitHub’ın resmi rehberi, profil README, pinned repo kullanımı ve profilinizi güvenli tutma gibi başlıklarda uygulanabilir öneriler içerir: Beginner’s guide to GitHub: Setting up and securing your profile.

“3–5 proje” kuralı: Neden daha az, daha güçlü?

Portföyde çok sayıda küçük proje listelemek, ilk taramada “derinlik” sinyalini zayıflatabilir. Pratikte daha etkili yaklaşım, 3–5 kapsamlı ve iyi belgelenmiş proje seçmektir. LinkedIn’de teknoloji rolleri için portföy oluşturma üzerine derlenen öneriler, taranabilir ve case-study formatında birkaç güçlü projenin daha ikna edici olabildiğini vurgular: Crafting A Career Portfolio For Tech Roles (sayfa bazı bölgelerde giriş gerektirebilir).

Proje seçimi için hızlı puanlama (5 üzerinden)

Her proje için aşağıdakileri 1–5 puanlayın; toplamı en yüksek olanlar aday listeniz olsun:

• İş hedefiyle uyum: Başvurduğunuz rolle ne kadar örtüşüyor?
• Gösterilebilir çıktı: Demo, ekran görüntüsü, kısa video, çalışan API dokümantasyonu var mı?
• Kod okunabilirliği: Yapı temiz mi, basit testler/linters var mı?
• Anlatılabilir kararlar: “Neden böyle yaptım?” diyebileceğiniz mimari/ürün kararları var mı?
• Sizin katkınız net mi: Ekip işiyse rolünüz ayrışıyor mu?

Her proje için “mini case study” şablonu (kopyala-yapıştır)

Her projenin README’sinde veya ayrı bir sayfada (GitHub Wiki, Notion, kişisel site) şu şablon işe yarar. Amaç, bir işe alım yöneticisinin 2–3 dakikada projenin değerini kavramasıdır.

1) Bir cümlelik özet

Ne? (Ürün) + kim için? (kullanıcı) + hangi problem?

2) Problem ve kapsam

• Hangi ihtiyacı çözüyor?
• Hangi şeyleri özellikle kapsam dışı bıraktınız (scope control)?

3) Sizin rolünüz

• Tek başınıza mı yaptınız, ekipte miydiniz?
• Hangi parçaları siz yazdınız? (API, UI, test, dağıtım, dokümantasyon vb.)

4) Teknik özet

• Stack: dil, framework, DB, hosting (varsa)
• Mimari: 3–6 maddelik kısa açıklama (ör. “REST API + JWT auth + PostgreSQL”).
• Kalite: test yaklaşımı, lint/format, CI (varsa)

5) Çalıştırma (Quickstart)

Kısa ve net:

• Gereksinimler (Node/Python sürümü gibi)
• .env örneği (gerçek anahtarlar olmadan)
• Kurulum ve çalıştırma adımları
• Test komutu

6) Demo ve doğrulama

• Canlı demo linki (varsa) veya kısa ekran kaydı
• Örnek istek/yanıt (API ise)

7) Öğrenimler ve bir sonraki adım

• Bu projede ne öğrendiniz?
• Vakit olsa neyi iyileştirirdiniz?

Portföyde yer verebileceğiniz proje türleri (pratik fikirler)

Aşağıdaki fikirler, “gerçek işe yakın” sinyaller üretmek için tasarlandı. Seçerken başvurduğunuz role göre uyarlayın.

Junior / kariyer başlangıcı için

• Basit ama üretime yakın full‑stack uygulama: Auth, rol bazlı yetki, CRUD, hata yönetimi, temel testler.
• API + dokümantasyon projesi: OpenAPI/Swagger, örnek istekler, rate limit ve doğrulama.
• “Take‑home” formatında proje: Küçük kapsam, temiz README, birim testleri, net commit geçmişi.
• Veri odaklı mini proje: ETL + küçük analiz + tekrar çalıştırılabilir pipeline.

Mid-level ve üzeri için

• Performans/ölçek odağı: cache, pagination, kuyruk, gözlemlenebilirlik (log/metric yaklaşımı).
• Sistem tasarımı anlatımı: Bir bileşeni yeniden tasarlama, trade‑off’lar, riskler.
• Geliştirici deneyimi aracı: CLI, kod üretici, lint kural seti, CI pipeline örneği.

Açık kaynak katkısı (her seviye için güçlü sinyal)

Açık kaynak katkıları; kod inceleme, ekip iletişimi ve gerçek bir kod tabanına uyum gibi becerileri gösterebilir. Bu konuda arXiv’de yayımlanan bir ön baskı, açık kaynak katkılarının özellikle öğrenciler/erken kariyer için işveren beklentileriyle uyumu göstermede yardımcı olabileceğini tartışır: The Open Source Resume (ön baskı; bulgular temkinli yorumlanmalıdır).

• 1–2 depo seçin, “good first issue” tarzı küçük bir iyileştirme yapın.
• PR açıklamasını net yazın: problem, çözüm, test adımı.
• Portföyünüzde “Katkılar” diye ayrı bir bölümle PR linklerini sergileyin.

README kontrol listesi (işe alım odaklı)

Birçok portföy projesi “çalıştırma” kısmı eksik olduğu için zayıf görünür. Aşağıdaki listeyi her repo için uygulayın:

• Üst bölüm: 1 paragraf özet + 3 maddeyle özellikler
• Ekran görüntüsü: Varsa kısa; erişilebilirlik için açıklayıcı metin ekleyin
• Kurulum: Tek komutla başlatma hedefi (mümkünse)
• Yapılandırma: .env.example, gerçek anahtar yok
• Test: “Nasıl test edilir?” ve temel senaryolar
• Dağıtım/Demo: Link veya adımlar
• Lisans: Repo lisansı ve üçüncü taraf kullanımına saygı
• Katkı rehberi: Basit CONTRIBUTING notu (opsiyonel ama artı puan)

Şeffaflık ve özgünlük: AI araçları, ekip projeleri, lisanslar

İşe alım ekiplerinin “bu işi gerçekten sen mi yaptın?” sorusu, özellikle üretken AI araçlarının yaygınlaşmasıyla daha görünür hale geldi. Bu eğilimi tartışan kaynaklardan biri olarak CoderPad’in raporuna göz atabilirsiniz: State of Tech Hiring 2026.

Portföyünüzü güvenilir kılmak için:

• Katkı beyanı ekleyin: “Bu projede X, Y, Z kısımlarını ben geliştirdim.”
• AI kullandıysanız dürüstçe çerçeveleyin: Örn. “Boilerplate için kullandım, final tasarım kararları ve hata ayıklama bana ait.”
• Commit geçmişini temiz tutun: Mantıklı mesajlar ve küçük, açıklanabilir adımlar.
• Ekip projesinde sınırları belirtin: Tasarım, backend, devops gibi sorumluluk alanınız.

Görüşmede portföyünüzü anlatma: 60 saniyelik proje konuşması

Portföy, görüşmede “konuşma materyali”dir. Her proje için şu kısa akışı hazırlayın:

1. Problem (10 sn): “Şunu çözmek için yaptım…”
2. Çözüm (15 sn): “Bunu şu mimariyle çözdüm…”
3. Karar (15 sn): “Şu iki seçenek vardı; bunu seçtim çünkü…”
4. Sonuç/öğrenim (20 sn): “Şunu öğrendim, şunu iyileştiririm…”

CV ve LinkedIn’e bağlama

• CV’de her proje için tek satırlık özet + GitHub linki kullanın.
• LinkedIn “Featured” bölümünde en iyi 1–2 projeyi sabitleyin.
• İş ilanındaki gereksinimlere göre pinned repo sırasını güncelleyin.

Hızlı karşılaştırma: “İyi” ve “geliştirilebilir” portföy işaretleri

7 günlük uygulanabilir plan

1. Gün 1: GitHub profil bio + iletişim + pinned repo düzeni.
2. Gün 2: 8–10 projeyi puanlayın, 3–5 projeyi seçin.
3. Gün 3: Proje 1 README’yi şablona göre yenileyin, .env.example ekleyin.
4. Gün 4: Proje 2 ve 3 için aynı düzeni uygulayın.
5. Gün 5: Demo/ekran kaydı ekleyin; bağlantıları güncel tutun.
6. Gün 6: Her proje için 60 saniyelik anlatımı yazın; job description’a göre 1–2 vurgu çıkarın.
7. Gün 7: CV ve LinkedIn’de projelere link verin; pinned repo sırasını hedef role göre ayarlayın.

Son not: Portföy “mükemmel” değil, “anlaşılır ve doğrulanabilir” olmalı

Portföyün amacı her şeyi sergilemek değil, işe alım ekibinin risk algısını azaltmaktır: Kodunuzu okuyabilsinler, çalıştırabilsinler, kararlarınızı anlayabilsinler. Bu hedefi tuttuğunuzda, portföyünüz hem başvuru aşamasında hem de teknik görüşmede daha verimli bir araç haline gelir.

Kaynaklar

• CoderPad — State of Tech Hiring 2026
• GitHub Blog — Beginner’s guide to GitHub: Setting up and securing your profile
• LinkedIn — Crafting A Career Portfolio For Tech Roles (erişim/giriş gerektirebilir)
• arXiv — The Open Source Resume (ön baskı)