Kariyer

Portfolyonuz Mükemmel Görünse de Neden Eski Kalır?

İnanın, Geçen ay Kadıköy’de bir kahvede, önüme iki farklı portfolyo açıldı (ki bu çoğu kişinin gözünden kaçıyor). İkisi de temizdi. İkisi de akıcıydı. Hatta biri o kadar şık görünüyordu ki ilk bakışta “tamam, bu iş olmuş” dedim… ama beş dakika sonra fikrim değişti. E peki, sonuç ne oldu? Çünkü mesele artık sadece güzel görünmek değil; işin aslı şu ki, portfolyo bugün sizi nasıl düşündüğünüzle ölçülüyor.

Şunu fark ettim: Ben bunu ilk kez 2023 sonbaharında, İstanbul’da bir startup’ın işe alım sürecini izlerken çok net gördüm. Tasarım olarak ortalama duran ama kararlarını net anlatan adaylar öne çıktı. Parlak animasyonlu, göz alıcı sayfalar ise çoğu zaman ikinci planda kaldı. Garip geliyor, biliyorum. Ama bugün değerlendirme masası başka çalışıyor (ciddiyim)

Güzel Tasarım Yetmiyor: İnsanlar Artık Başka Şey Arıyor

Portfolyonun cilalı olması kötü değil. Hatta iyi bile sayılır. Fakat tek başına yetmiyor — çünkü işe alan kişi ya da müşteri, sizin renk paletinize değil; nasıl düşündüğünüze bakıyor. Bir projeyi neden o teknolojiyle yaptınız? Neyi kırıp geçirdiniz? Nerede tökezlediniz? İşte bunlar merak ediliyor.

Lafı gevelemeden söyleyeyim: sadece ekran görüntüsü ve GitHub linki koyan portfolyolar biraz “ben buradayım” diyor ama “ben ne yapıyorum” kısmını eksik bırakıyor. Ben 2024 başında bir freelance adayın portfolyosunu incelerken bunu çok hissettim — proje listesi uzundu. Hiçbirinde karar mantığı yoktu. Sanki market fişi gibi. Bu ne anlama geliyor? Ürün var, açıklama yok.

İşverenin kafasındaki soru aslında çok basit: Bu kişi sorun çözüyor mu, yoksa sadece kod yazıp bırakıyor mu? O yüzden modern portfolyo biraz vitrin, biraz da çalışma defteri gibi olmalı. Sadece sonuç değil, yol da görünmeli.

Portfolyo artık “ne yaptım” sayfası olmaktan çıktı; “nasıl düşündüm” sayfasına dönüştü.

Klasik Proje Listesi Neden Eskidi?

Eskiden birkaç React projesi, bir CRUD uygulaması ve düzgün bir ana sayfa çoğu zaman yetiyordu. Şimdi yetmiyor. Neden? Çünkü herkes aynı araçlara erişiyor, aynı eğitim videolarını izliyor ve benzer örnekleri kopyalayıp yapabiliyor. Yani fark yaratan şey teknik seçimden çok teknik gerekçe oluyor.

Bu konuda küçük startup’larla kurumsal ekipler arasında ciddi fark var. Küçük ekip hızlı karar vermek ister; kısa ama ikna edici açıklamalar iş görür. Kurumsal tarafta ise güvenlik, sürdürülebilirlik ve dokümantasyon beklenir — evet, biraz sıkıcı olabilir, tabi. Ama ikisinde de ortak nokta şu: hikâye yoksa proje sıradan kalır.

Bunu biraz açayım.

💡 Bilgi: Portfolyonuzda sadece sonuçları değil, karar anlarını da gösterin. “Neden bu yolu seçtim?” sorusuna cevap veremiyorsanız, sayfa eksik kalır.

Bi saniye — Bir de şu var: insanlar artık AI destekli araçlarla hızlıca demo çıkarabiliyor. Kötü değil bu, hatta bayağı işe yarıyor (ki bu çoğu kişinin gözünden kaçıyor). Ama tam da bu yüzden yüzeydeki işler birbirine benziyor. Farkı yaratan şey derinlik oluyor… yani zor kısım.

Case Study Mantığına Geçin

Ne yalan söyleyeyim, Sade bir proje kartı yerine mini vaka analizi yazmak bence oyunun kurallarını değiştiriyor. Mesela “React ile e-ticaret sitesi yaptım” demek yerine şunu anlatın: hangi problemi çözdünüz, neden bu stack’i seçtiniz, nerede duvara tosladınız ve sonunda ne oldu?

Evet, doğru duydunuz.

Bunu kendi blog düzenimde test ettiğimde ilginç bir şey fark ettim: kısa proje açıklamaları trafik çekiyordu ama uzun vaka anlatımları daha fazla geri dönüş getiriyordu — özellikle LinkedIn üzerinden. İnsanlar detay seviyor; özellikle de detay gerçekse.

Kullanabileceğiniz Basit Yapı

Bölüm Neyi anlatmalı?
Problem Kullanıcının ya da müşterinin acısı neydi?
Yaklaşım Neden bu çözümü seçtiniz?
Zorluklar Nerede takıldınız?
Çözüm Sorunu nasıl hallettiniz?
Sonuç Etkisi ne oldu?

Bence en kuvvetli bölüm çoğu zaman “sonuç” değil “öğrendiklerim” kısmı oluyor — çünkü orada dürüstlük devreye giriyor. Açık konuşayım: herkes her şeyi mükemmel yapmıyor zaten (inanın bana). Bazen yanlış veri modeli seçiyorsunuz, bazen performans düşüyor, bazen tasarım beklediğiniz kadar iyi oturmuyor… Bu kısımları saklamak yerine anlatmak, sizi aslında daha güvenilir kılıyor — tuhaf ama öyle.

Düşünce Sürecinizi Saklamayın

Tamamlanmış ürünü göstermek kolay. Düşünce sürecini göstermek ise daha kıymetli. Çünkü orada karakter çıkıyor! Bir geliştirici olarak nasıl debug ettiğinizi, hangi metriklere baktığınızı ve neden bazı özellikleri çıkardığınızı anlattığınızda güven oluşuyor.

Editör masasında geçen hafta buna benzer bir örnek gördüm — Ankara’dan gelen bir adaydı. Kod kalitesi fena değildi. Asıl dikkat çeken şey README’deki küçük notlardı: “Bunu böyle yaptım çünkü mobilde ilk yükleme süresi düşsün istedim.” İşte bu tek cümle, tek başına birçok parlak animasyondan daha değerliydi. Ciddi söylüyorum.

Kendinizi Gösterirken Abartmayın

  • Neyi denediğinizi yazın.
  • Neyi yanlış yaptığınızı saklamayın.
  • Neyi sonraki sürüme bıraktığınızı açıkça söyleyin.
  • Metrik kullanıyorsanız sayı verin; boş iddia yerine somut veri koyun.

Mesela “performansı artırdım” demek zayıf kalır. Bunun yerine “yükleme süresini 4 saniyeden 1 saniyenin altına indirdim” derseniz durum değişir. Küçük detay gibi duruyor ama etkisi büyük. Wilmer’e Tool Calling Geldi: Yerel AI Akışı Değişiyor yazımızda bu konuya da değinmiştik.

Hızlı Site = Daha Güçlü İzlenim

Şimdi bak… portfolyonuz yavaşsa güzel görünmesinin pek anlamı kalmıyor. Ben bunu birkaç kez test ettim; özellikle büyük görseller ve gereksiz animasyonlar eklendiğinde site adeta nefes nefese kalıyor. Kullanıcı beklemiyor. Gidiyor. Yapay Zekâ Kod Yazıyor Ama İsim Vermek Hâlâ Zor yazımızda bu konuya da değinmiştik.

Küçük bir detay: Açıkçası bazı tasarımlar bana hep fazla cilalı geliyor ama pratikte hantallaşıyorlar. Kağıt üstünde harika duran efektler (söylemesi ayıp) gerçek cihazda can sıkabiliyor. Hele bir de mobilde durum daha can alıcı — küçük ekranda sabırsızlık iyice artıyor.

Project preview

Bir bakıma, şunu fark ettim: Lazy loading basit bir hamle gibi durur ama etkisi bayağı hissedilir. Bir startup için hız doğrudan dönüşüm demek olabilir; enterprise tarafında ise erişilebilirlik ve standartlara uyum devreye girer. Yani mesele sadece hız değil, aynı zamanda kullanıcıya saygı meselesi. SDLC Modelleri: Hangi Yapı Ne Zaman İşe Yarıyor? yazımızda bu konuya da değinmiştik.

SEO’yu Hafife Alan Portfolyo Kaybolur Gider

Biri sizi aradığında bulunabiliyor musunuz? İşte kritik soru bu. Eğer adınızla birlikte rolünüz ya da uzmanlık alanınız görünmüyorsa portfolyonuz sessiz sedasız kenarda kalır. SEO burada büyülü numara değil; temel düzen işi.

Ben kendi denemelerimde başlıklara isim ve rol eklediğimde ziyaretçi davranışının değiştiğini gördüm. Mesela sade “Projects” yerine “Frontend Developer Portfolio | Ad Soyad” gibi net ifadeler çok daha anlaşılır oluyor. Google da insan da seviyor bunu — sürpriz yok!

Küçük Dokunuşlarla Büyük Fark Yaratın

  • Ana başlıkta adınızı ve uzmanlığınızı belirtin.
  • Kritik projelerde anahtar kelimeyi doğal biçimde kullanın.
  • Sosyal profillerinizi bağlayın.
  • Mümkünse yapılandırılmış veri ekleyin. — ciddi fark yaratıyor
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Ad Soyad",
"url": "https://ornekportfoy.com",
"sameAs": [
"https://github.com/kullaniciadi",
"https://linkedin.com/in/profil"
]
}

Peki Ne Sunmalısınız?

Bence modern portfolyo dört şeyi aynı anda göstermeli: ne yaptığınız, nasıl düşündüğünüz, ne öğrendiğiniz ve bundan sonra ne yapmak istediğiniz. Bunlardan biri eksik olursa tablo yamuk duruyor. Ya çok yüzeysel kalıyorsunuz ya da aşırı teknik olup okuyucuyu kaçırıyorsunuz. İkisi de kötü.

💡 Bilgi: Tutorial projeleri hâlâ faydalı olabilir ama tek başlarına yetmezler. Gerçek hayata yakın kullanım senaryosu olmayan işler artık çabuk sırıtıyor.

Daha İyi Bir Portfolyo İçin Kaba Kontrol Listesi

Soru Cevap evetse iyi haber
Anlatım net mi? Evet / Hayır
Metrik var mı? Evet / Hayır
Düşünce süreci görünüyor mu? Evet / Hayır
Sitede CTA açık mı? Evet / Hayır

Eğer üçten fazla yerde kafa karışıklığı varsa durup yeniden bakmak lazım. Bazen tasarımı bozmak pahasına metni sadeleştirmek gerekir — bu hoş olmayabilir ama işe yarar. Peki bunu neden söylüyorum? Beklediğim kadar iyi olmayan yerleri düzeltmek çoğu zaman yeni efekt eklemekten daha değerlidir — dürüst olayım, biraz hayal kırıklığı —

Kapanışa Doğru Küçük Bir Gerçeklik Kontrolü

Sizin portfolyonuz belki bugün temiz görünüyor. Ama yarın başka adayların arasına karışınca eskimiş hissedebilir. Çünkü değerlendirme ölçütü sürekli kayıyor; dün yeterli olan bugün sıradanlaşıyor. Maalesef.

Bence yapılacak en akıllıca şey şu: portfolyoyu canlı tutmak. Her projeye küçük notlar ekleyin, birkaç ayda bir metni güncelleyin, eski tutorial işlerini gölgeleyip gerçek deneyimleri öne alın. Ha, neredeyse unutuyordum: iletişim çağrısı net olsun. “Bana ulaşın” demek yetmez — neden ulaşmaları gerektiğini de hissettirin.

Açık konuşayım, Aşağıda ilgili birkaç yazıya da göz atabilirsiniz. En çok da içerik üretimi, AI akışı ve frontend tarafındaki pratik konulara bakınca bağlantılar daha net kuruluyor:

Bilmem anlatabiliyor muyum, Karpathy’nin Defteri SEO’yu Nasıl Düzeltiyor?

Şunu söyleyeyim, React’te Dosya Yükleme: Sürükle-Bırak ve Önizleme

Freelance Pazarındaki Kargaşa Bitiyor mu?: Assignly Ne Vadediyor

Sıkça Sorulan Sorular

Portfolyumda kaç proje olmalı?

Dürüst cevap şu:Sayıdan çok kalite önemli. Üç güçlü vaka çalışması,on tane yüzeysel projeden daha iyi durur. Her projenin farklı beceri göstermesi işleri güçlendirir.

Tutorial projeleri neredeyse tamamen kaldırmalı mıyım?

Tamamen kaldırmanız şart değil. tek omurganız onlar olmasın. Tutorial projesini alıp gerçek probleme uyarlarsanız değer kazanır,aksi halde sıradan görünür.

No-code ya da AI ile hazırlanan işler zarar verir mi?

Zarar vermez;ama bağlam lazımdır. Nasıl kullandığınızı,neyi siz yönettiğinizi açıkça söylerseniz sorun olmaz. Aksi halde emeğiniz bulanıklaşabilir.

Portfolyoda teknik detay vermek şart mı?

Evet,ama dozunda. Her satırı dökmek zorunda değilsiniz fakat teknoloji seçiminizin nedeni mutlaka görünmeli. Mesela ekip çalışmasına uygunluk açısından bu önemli.

Kaynaklar ve İleri Okuma

PageSpeed Insights Resmi Aracı

Google SEO Starter Guide

Best README Template GitHub Sayfası

}

Aşkın KILIÇ

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

Bu içerik işinize yaradı mı?

Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.

Haftalık Bülten

Her pazar özenle seçilmiş teknoloji yazıları doğrudan e-postanıza gelsin.

← Onceki Yazi
Gemini CLI ve Apps Script ile Uzak Alt Ajan Kurulumu
Sonraki Yazi →
Railway, E-Ticaret İçin Güvenilir mi? 2026’da Net Cevap

Yorum Yaz

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Haftalık Bülten

Azure, DevOps ve Yapay Zeka dünyasındaki en güncel içerikleri her hafta doğrudan e-postanıza alın.

Spam yok. İstediğiniz zaman iptal edebilirsiniz.
📱
Uygulamayı Yükle Ana ekrana ekle, çevrimdışı oku
Kategoriler
Ara
Paylaş
İçindekiler
← Gemini CLI ve Apps Script ile ...
Railway, E-Ticaret İçin Güveni... →
📩

Gitmeden önce!

Her pazar özenle seçilmiş teknoloji yazıları ve AI haberleri doğrudan e-postanıza gelsin. Ücretsiz, spam yok.

🔒 Bilgileriniz güvende. İstediğiniz zaman ayrılabilirsiniz.

📬 Haftalık bülten: Teknoloji + AI haberleri