Portföyünüzü Güçlendirecek Modern Frontend ve Full Stack Proje Fikirleri

Portföy için hangi frontend ve full stack proje fikirleri gerçekten işe yarar?

Portföy için işe yarayan full stack proje fikirleri, tek bir beceriyi açıkça kanıtlayan, canlı demosu olan ve README dosyasında kararlarını anlatan projelerdir. Seviyenize uygun başlarsınız: önce HTML, CSS ve JavaScript temeli, sonra API ve durum yönetimi, en sonunda kimlik doğrulama, veritabanı ve deploy içeren uçtan uca uygulamalar.

Bu yazıda full stack proje fikirleri listesini seviyelere göre sıralıyorum ve her projenin hangi beceriyi öğrettiğini yazıyorum. 2012'den beri web tasarım projelerinde geliştiricilerle aynı masada oturuyorum; işe alım görüşmelerinde portföy incelediğim de oldu. Bu nedenle listeyi "havalı görünen" değil, "görüşmede konuşulabilen" projeler üzerine kurdum. Yol haritası konusunu ayrı tutuyorum; burada yalnızca ne inşa edeceğinize ve onu nasıl sunacağınıza odaklanıyorum.

Seviyelere göre proje haritası neye benziyor?

Aşağıdaki tablo, yazının geri kalanında ayrıntılandırdığım projelerin kısa özetidir. Süreler saha tecrübesine dayalı başlangıç aralığıdır, garanti değil; günlük ayırdığınız zamana göre ciddi biçimde değişir.

Tablodaki her satırı bitirmek zorunda değilsiniz. Ancak her seviyeden en az bir projeyi tamamlarsanız, işverene gelişim çizginizi gösterirsiniz. Üstelik görüşmede "önce şunu yaptım, sonra bunu öğrendim" diye anlatacağınız doğal bir hikâye oluşur.

Başlangıç seviyesinde hangi projeler temeli sağlam gösterir?

Başlangıç projelerinin amacı gösteriş değil, temizliktir. İşe alım yapan kişi bu projelere bakarken etiket seçiminize, CSS düzeninize ve mobil görünüme odaklanır. Bu yüzden küçük ama kusursuz projeler, büyük ama dağınık projelerden daha iyi iz bırakır.

• Kişisel tanıtım sayfası: anlamsal etiketler, erişilebilir menü ve iyi bir tipografi sistemi öğretir.
• Restoran menüsü sayfası: CSS grid ile kategori düzeni ve mobil öncelikli yerleşim öğretir.
• Doğrulamalı iletişim formu: HTML form öznitelikleri, JavaScript ile anlık hata mesajları ve erişilebilir etiketler öğretir.
• Fotoğraf galerisi: flexbox, grid, en boy oranı ve tembel yükleme mantığı öğretir.

Örneğin kişisel sayfada renk paletini seçerken HTML renk kodları aracı ile kontrast denemeleri yapabilirsiniz. Ayrıca tasarımı önce Figma'da kurup sonra koda dökmek, gerçek iş akışını taklit eder. Bu adımları Figma ile web arayüz tasarımı yazımda anlattım.

Bir ipucu daha: bu projelerde framework kullanmayın. Saf HTML, CSS ve JavaScript ile bitirdiğiniz bir sayfa, temeli gerçekten bildiğinizi kanıtlar.

API kullanan küçük projeler size ne öğretir?

API projeleri, statik sayfadan canlı veriye geçişi temsil eder. Bu geçişte öğrendiğiniz en değerli şey, işler ters gittiğinde ne olacağıdır. Yani yükleniyor durumu, boş sonuç ve ağ hatası ekranları asıl beceridir.

Birkaç fikir vereyim. Döviz çevirici, açık bir kur servisinden veri çeker ve kullanıcı girdisini doğrular. Hava durumu uygulaması, konum izni ve birim dönüşümü ister. Film veya kitap arama uygulaması ise arama kutusunda gecikmeli sorgu (debounce) ve sayfalama pratiği sağlar.

Bu projelerde API anahtarını istemci koduna gömmeyin. Anahtar gerektiren servislerde küçük bir sunucu fonksiyonu kullanın ve anahtarı ortam değişkeninde saklayın. Böylece daha başlangıçta güvenlik refleksi kazandığınızı gösterirsiniz. MDN'in Using the Fetch API rehberi, istek ve hata yönetimi için güvenilir bir başlangıçtır.

Kısacası API projesinin başarısını, güzel veri ekranı değil, kötü senaryodaki davranışı belirler. README dosyanızda bu senaryoları nasıl ele aldığınızı mutlaka yazın.

Orta seviye frontend projelerini nasıl seçmelisiniz?

Orta seviyede bir framework seçmiş olmanız gerekir; React, Vue veya Svelte fark etmez. Artık soru "çalışıyor mu" değil, "büyüdüğünde ayakta kalıyor mu" olur. Bu nedenle seçtiğiniz proje durum yönetimini zorlamalıdır.

1. Kanban görev panosu: sütunlar arası sürükle bırak, sıralama ve kalıcı durum. Bileşenleri nasıl böldüğünüzü gösterir.
2. Ürün listesi ve sepet: kategori filtresi, fiyat sıralaması ve filtrelerin URL'de tutulması. Paylaşılabilir durum kavramını öğretir.
3. Analitik paneli: sahte veya açık veriyle grafik, tarih aralığı seçici ve yükleme iskeletleri. Veri görselleştirme ve performans dengesini öğretir.
4. Çok adımlı form: ilerleme göstergesi, adım bazlı doğrulama ve taslak kaydetme. Karmaşık form mantığını öğretir.

Bu projelerden birini seçerken hedeflediğiniz işe bakın. Örneğin e-ticaret ajanslarına başvuracaksanız sepet projesi doğal olarak öne çıkar. Öte yandan kurumsal panel geliştiren şirketler analitik paneli daha anlamlı bulur.

Formlar konusunda derinleşmek isterseniz randevu, teklif ve demo formu tasarımı yazısındaki dönüşüm odaklı kuralları projenize uygulayabilirsiniz.

Erişilebilirliği gösteren bir proje neden fark yaratır?

Çünkü adayların çok azı bunu bilinçli olarak gösterir. Klavyeyle baştan sona gezilebilen, ekran okuyucuda anlamlı okunan bir arayüz, sizi kalabalıktan ayırır. Üstelik birçok kurumsal müşteri artık erişilebilirliği sözleşme şartı olarak soruyor.

Referans noktanız W3C WCAG yönergeleri olmalıdır. Kontrast oranı, odak görünürlüğü, alternatif metin ve form etiketleri gibi kriterler somut ve ölçülebilir. Dolayısıyla projenizde bunları tek tek kontrol edip README'de listeleyebilirsiniz.

Pratik bir fikir: erişilebilir bir modal pencere ve açılır menü bileşeni yazın. Odak tuzağı, Escape tuşuyla kapanma ve ARIA öznitelikleri bu küçük parçada bir araya gelir. Ardından aynı bileşeni ekran okuyucuyla test ettiğiniz kısa bir video ekleyin.

Bu tür bir proje, görüşmede size güçlü bir cümle kurdurur: "Bileşeni klavye ve ekran okuyucuyla test ettim." Bu cümleyi kuran aday sayısı, deneyimime göre hâlâ oldukça azdır.

Performans odaklı bir proje Core Web Vitals bilgisini nasıl kanıtlar?

Performans projesi, bir sayfayı yavaş hâlinden hızlı hâline taşıdığınızı gösteren öncesi ve sonrası çalışmasıdır. Google'ın Core Web Vitals metrikleri burada ortak dili sağlar. web.dev'e göre iyi eşikler LCP için 2,5 saniye, INP için 200 milisaniye ve CLS için 0,1'dir.

Uygulama şöyle olabilir. Önce görselleri büyük, yazı tiplerini engelleyici, JavaScript'i şişkin bir demo sayfası kurun. Ardından Lighthouse ile ölçün, sonuçları kaydedin. Sonra görselleri sıkıştırın, kritik CSS'i öne alın, kod bölme uygulayın ve tekrar ölçün.

Ölçüm adımları için Lighthouse ile site performans testi yazıma bakabilirsiniz. Ayrıca mobil tarafı unutmayın; mobil uyumluluk testi rehberindeki kontrolleri de README'ye ekleyin.

Bu projede önemli olan rakamların kendisi değil, her iyileştirmenin nedenini açıklamanızdır. Yani "LCP düştü" demek yetmez; hangi değişikliğin neden etkili olduğunu yazmalısınız.

İlk full stack proje fikirleri hangi becerileri kanıtlar?

İlk full stack proje fikirleri, frontend ile backend arasındaki sözleşmeyi kurabildiğinizi göstermelidir. Yani API tasarlar, veriyi saklar, hataları anlamlı döndürür ve tüm bunları canlı bir adreste çalıştırırsınız.

• Link kısaltıcı: benzersiz kod üretimi, yönlendirme, tıklama sayacı ve basit analitik. Kodları okunabilir tutmak için slug oluşturucu mantığını inceleyebilirsiniz.
• Not veya yer imi uygulaması: kayıt, giriş, şifre sıfırlama ve kullanıcıya özel veri. Kimlik doğrulamanın temelini öğretir.
• Randevu sistemi: müsait saatler, çakışma kontrolü, saat dilimi ve e-posta bildirimi. Tarih mantığının ne kadar zor olduğunu erken gösterir.
• QR menü yöneticisi: işletme menüyü panelden günceller, müşteri QR ile görür. QR üretimini QR kod oluşturucu ile karşılaştırarak test edebilirsiniz.

Bu projelerde en çok şu soruya cevap arıyorum: başka bir kullanıcının verisine erişebiliyor muyum? Adres çubuğundaki kimliği değiştirip başkasının notunu açabiliyorsam, proje görüşmede ters teper. Bu nedenle her uç noktada sahiplik kontrolü yazın ve bunu test edin.

Gerçek zamanlı özellik içeren projeler neden değerlidir?

Gerçek zamanlı projeler, istek ve yanıt modelinin ötesine geçtiğinizi gösterir. Sohbet uygulaması, canlı anket veya ortak beyaz tahta gibi fikirler, WebSocket ya da sunucu gönderimli olaylar (SSE) kullanmanızı gerektirir.

Burada öğrendiğiniz beceriler şunlardır: bağlantı kopunca yeniden bağlanma, mesaj sırası, çevrimiçi durumu ve okunmamış sayacı. Ayrıca aynı anda iki sekmede test etmek, eşzamanlılık hatalarını görmenin en kolay yoludur.

Örneğin canlı anket projesi küçük ama öğreticidir. Sunucu oyları toplar, tüm katılımcılara anlık sonuç gönderir ve aynı kişinin iki kez oy vermesini engeller. Böylece hem gerçek zamanlı iletişimi hem de temel kötüye kullanım önlemini tek projede gösterirsiniz.

Yine de bu seviyeye erken atlamayın. Temel CRUD uygulamasını sağlam kurmadan gerçek zamanlı projeye girerseniz, hataların kaynağını bulmak çok zorlaşır.

İleri seviye full stack proje fikirleri nelerdir?

İleri seviye full stack proje fikirleri, tek kullanıcılı demo mantığından çıkıp gerçek ürün kaygılarını taşır. Veri izolasyonu, arka plan işleri, izleme ve maliyet bu seviyede devreye girer.

1. Çok kiracılı küçük SaaS: her firmanın verisi ayrı, roller ayrı. Kiracı izolasyonunu nasıl sağladığınızı anlatmanız gerekir.
2. Ödeme sandbox entegrasyonu: bir ödeme sağlayıcısının test ortamıyla abonelik akışı, webhook doğrulama ve başarısız ödeme senaryosu.
3. Arama ve filtreleme motoru: binlerce kayıtta tam metin arama, yüzeyli filtreler ve sayfalama. Veritabanı indekslerini öğretir.
4. Arka plan işi kuyruğu: rapor üretimi veya toplu e-posta gibi uzun işleri kuyruğa alma ve durum takibi.

Bu projelerde mimari kararlarınızı yazmak kodun kendisi kadar önemlidir. Hatta büyük ön yüzleri ekipler arasında bölmeyi merak ediyorsanız micro frontend mimarisi yazısı ileri seviye bir tartışma zemini sunar. Ancak portföy projesinde bu mimariyi zorla uygulamayın; neden seçmediğinizi açıklamak da olgunluk göstergesidir.

Gerçek bir işletme için proje yapmak portföyü nasıl güçlendirir?

Gerçek kullanıcısı olan tek bir proje, on demo projeden daha ikna edicidir. Çünkü gerçek kullanıcı beklenmedik girdiler, gerçek geri bildirim ve gerçek tarihler getirir. Bu da size demoda asla yaşamayacağınız sorunları yaşatır.

Mahallenizdeki bir kafe, bir dernek ya da tanıdığınız küçük bir işletme için basit bir site veya randevu aracı yapabilirsiniz. Ancak iş tanımını yazılı netleştirin: kapsam, teslim tarihi ve bakım sorumluluğu belli olsun. Aksi hâlde iyi niyetli bir proje, bitmeyen bir destek yüküne dönüşür.

Bu tür projelerde SEO ve paylaşım görünümünü de ele alın. Sayfa başlıklarını ve açıklamaları meta tag oluşturucu ile düzenleyebilir, işletme bilgilerini schema markup ile yapısal veriye dönüştürebilirsiniz. Böylece yalnızca kod değil, işletmeye değer katan bir sonuç teslim edersiniz.

Müşteri izin verirse README'ye kısa bir alıntı ekleyin. Ölçülebilir bir sonuç varsa kaynağıyla birlikte yazın; yoksa uydurmayın.

Klon projeler portföyde işe yarar mı?

Evet, ama tek başına değil. Bilinen bir uygulamanın arayüzünü klonlamak, ölçü ve düzen becerisini gösterir. Ancak işe alım yapan kişi aynı klonu defalarca görmüştür; bu nedenle klon sizi ayırt etmez.

Klonu değerli kılmanın yolu, üstüne kendi kararınızı eklemektir. Örneğin bir müzik uygulaması arayüzünü klonladıysanız, çevrimdışı çalma listesi ya da erişilebilir oynatıcı kontrolleri ekleyin. Böylece "kopyaladım" değil, "geliştirdim" dersiniz.

Ayrıca klonlarda marka varlıklarını, logoları ve telif hakkı olan içerikleri kullanmayın. Kendi yer tutucu görsellerinizi ve açık lisanslı içerikleri tercih edin. Bu detay, profesyonel çalışma alışkanlığınızı da gösterir.

Kısacası klon, portföyde bir ısınma turudur. Vitrinin ortasına ise kendi fikrinizden doğan ya da gerçek kullanıcıya hizmet eden projeyi koyun.

Test yazmak portföy projesinde neden bu kadar önemli?

Test, kodunuzun yarın da çalışacağına dair verdiğiniz sözdür. Portföy projelerinin büyük kısmında hiç test yoktur; bu nedenle birkaç anlamlı test bile sizi öne çıkarır. İşe alım yapan kişi test klasörünü gördüğünde, ekip içinde nasıl çalışacağınızı daha kolay hayal eder.

Her şeyi test etmeye çalışmayın. Önce iş mantığının kalbini seçin: sepet toplamı, randevu çakışma kontrolü ya da yetki kontrolü gibi. Ardından bir iki uçtan uca test ekleyin; örneğin kullanıcı kayıt olur, giriş yapar ve kendi notunu görür.

Ayrıca testleri her push işleminde otomatik çalıştıran basit bir sürekli entegrasyon akışı kurun. Depo sayfasındaki yeşil onay işareti, küçük ama güçlü bir güven sinyalidir. Üstelik bu akışı kurarken yapılandırma dosyaları, ortam değişkenleri ve gizli anahtar yönetimi konusunda da pratik kazanırsınız.

README içinde test komutunu ve neyi neden test ettiğinizi iki üç cümleyle yazın. Böylece testleriniz yalnızca kodda değil, anlatımda da görünür olur.

Portföy sitenizi de bir proje gibi mi ele almalısınız?

Evet, çünkü portföy siteniz ziyaretçinin gördüğü ilk projedir. Yavaş açılan, mobilde dağılan ya da bozuk bağlantılar içeren bir portföy sitesi, içindeki iyi projelerin değerini düşürür. Bu yüzden siteye de diğer projelerdeki özeni gösterin.

İyi bir portföy sitesinde şunlar bulunur: kısa bir tanıtım, öne çıkan üç dört proje, her proje için bir paragraf özet, demo ve kaynak kod bağlantıları, iletişim bilgisi. Özgeçmişinizi PDF olarak eklemek de işe alım sürecini hızlandırır.

Örneğin her proje kartında "sorun, çözüm, teknoloji" üçlüsünü kullanabilirsiniz. Ziyaretçi bu üç satırı okuyarak projeye tıklayıp tıklamayacağına karar verir. Ayrıca sitenin başlık ve açıklama etiketlerini düzenlerseniz, adınızı arayan kişi sizi arama sonuçlarında daha kolay bulur.

Son olarak siteyi sade tutun. Animasyon ve efekt, projelerinizin önüne geçmemeli; vitrin, ürünü göstermek için vardır.

Takım çalışmasını gösteren projeler nasıl bulunur?

Tek başına yaptığınız projeler teknik becerinizi gösterir, ancak ekip içinde çalışma becerisini göstermez. Bu boşluğu kapatmanın en iyi yolu, başkalarıyla birlikte kod yazdığınız bir proje eklemektir.

Birkaç yol var. İlk olarak, açık kaynak bir projede küçük bir hata düzeltmesi veya dokümantasyon katkısı yapabilirsiniz; "good first issue" etiketli konular bunun için iyi bir başlangıçtır. İkinci olarak, iki üç arkadaşınızla birlikte bir hackathon projesi geliştirebilirsiniz. Üçüncü olarak, bir tasarımcıyla eşleşip onun tasarımını koda dökebilirsiniz.

Bu projelerde asıl değerli olan, pull request açıklamalarınız ve kod inceleme yorumlarınızdır. Çünkü işe alım yapan kişi, geri bildirime nasıl yanıt verdiğinizi burada görür. Dolayısıyla açıklamalarınızı net, saygılı ve gerekçeli yazın.

Kısacası tek bir kabul edilmiş katkı bile, "ekiple çalışabilirim" cümlesini somut bir kanıta dönüştürür.

Kaç proje yeterli ve hangi sırayla yapmalısınız?

Benim önerim üç ile beş arası güçlü projedir. On yarım proje yerine dört bitmiş proje her zaman daha iyi okunur. Sıralama için şu planı öneririm:

1. Bir başlangıç projesi: saf HTML, CSS ve JavaScript ile kusursuz bir duyarlı sayfa.
2. API projesi: hata ve boş durumları iyi yöneten küçük bir uygulama.
3. Bir orta seviye framework projesi: durum yönetimi ağır bir panel veya sepet.
4. Full stack proje: kimlik doğrulama, veritabanı ve canlı deploy.
5. İsteğe bağlı bir uzmanlık projesi: erişilebilirlik, performans ya da gerçek zamanlı iletişim.

Bu sıralama, full stack proje fikirleri arasında kaybolmamanızı sağlar. Ayrıca her proje bir öncekinin becerisini kullandığı için tekrar değil, birikim yaşarsınız.

Son olarak projeler arasında tutarlı bir tasarım dili kullanın. Aynı tipografi ve renk sistemi, portföyü tek bir ürün gibi gösterir.

İyi bir README dosyasında neler olmalı?

README, projenizin satış sayfasıdır. İşe alım yapan kişi çoğu zaman kodu açmadan önce README'yi okur ve orada karar verir. GitHub'ın README belgeleri dosyanın depo ana sayfasında otomatik gösterildiğini belirtir; yani ilk izlenim burada oluşur.

• Tek cümlelik tanım: proje ne yapar, kim için yapar.
• Canlı demo bağlantısı ve varsa test kullanıcısı bilgisi.
• Ekran görüntüsü veya kısa hareketli önizleme.
• Kullanılan teknolojiler ve her birini neden seçtiğiniz.
• Kurulum adımları: klonlama, ortam değişkenleri, çalıştırma komutu.
• Karşılaştığınız zorluklar ve çözümleriniz.
• Bilinen eksikler ve sonraki adımlar.

Özellikle "zorluklar" bölümünü atlamayın. Bu bölüm, görüşmede size sorulacak soruların cevabını önceden hazırlar. Üstelik düşünme biçiminizi kodu okumadan gösterir.

Yazım dilinde de özen gösterin. İngilizce ilanlara başvuruyorsanız README'yi İngilizce yazın; Türkçe pazarı hedefliyorsanız iki dilli bir yapı kurabilirsiniz.

Canlı demoyu nasıl yayınlamalı ve nelere dikkat etmelisiniz?

Canlı demo, "bende çalışıyordu" bahanesini ortadan kaldırır. Statik projeler için GitHub Pages gibi ücretsiz barındırma seçenekleri yeterlidir. Full stack projelerde ise sunucu ve veritabanını barındıran bir platform gerekir.

Demoda dikkat etmeniz gereken birkaç nokta var. İlk olarak, ücretsiz planlarda uygulama uyku moduna geçebilir; ilk açılışın yavaş olabileceğini README'de belirtin. İkinci olarak, test hesabı verin ki inceleyen kişi kayıt olmakla uğraşmasın. Son olarak, demo verisini gerçekçi ama sahte tutun.

Ayrıca demoyu periyodik olarak açıp kontrol edin. Süresi dolmuş bir API anahtarı ya da kapanmış bir veritabanı, portföyünüzü bir gecede bozabilir. Bozuk bir demo, hiç demo olmamasından daha kötü bir izlenim bırakır.

Mümkünse kendi alan adınızı kullanın. Kısa ve akılda kalan bir adres, CV'de ve LinkedIn profilinizde daha profesyonel durur.

GitHub profilinizi bir vitrin gibi nasıl düzenlersiniz?

GitHub profiliniz, portföy sitenizin tamamlayıcısıdır. En iyi projelerinizi sabitleyin, yarım kalmış denemeleri arşivleyin ya da gizleyin. Böylece ziyaretçi ilk bakışta en güçlü işinizi görür.

Profil README'si de iyi bir fırsattır: kullanıcı adınızla aynı isimde bir depo açıp içine README koyduğunuzda, bu metin profil sayfanızın üstünde görünür. Kısa bir tanıtım, odaklandığınız teknolojiler ve öne çıkan üç proje bağlantısı yeterlidir.

Commit geçmişi de okunur. Anlamlı commit mesajları, küçük ve düzenli değişiklikler, işe alım yapan kişiye çalışma disiplininizi anlatır. Öte yandan tek seferde yüklenmiş dev bir commit, projenin bir yerden kopyalandığı şüphesini doğurabilir.

Son olarak projelerinize konu etiketleri (topics) ekleyin ve depo açıklamalarını doldurun. Bu küçük detaylar, profilinizi arama sonuçlarında ve öneri listelerinde daha görünür kılar.

Yapay zekâ destekli kodlama araçlarını portföy projelerinde kullanabilir misiniz?

Kullanabilirsiniz, ama projeyi sizin anlamanız şartıyla. Bugün birçok ekip kod önerisi veren araçlarla çalışıyor; bu nedenle bu araçları hiç kullanmamak da gerçekçi değil. Asıl soru, ürettiğiniz kodun her satırını açıklayabilip açıklayamadığınızdır.

Görüşmede işe alım yapan kişi, projenizden rastgele bir fonksiyon seçip neden böyle yazdığınızı sorabilir. Cevap veremezseniz proje size puan değil, şüphe kazandırır. Dolayısıyla araçtan gelen öneriyi kabul etmeden önce okuyun, test edin ve gerekirse sadeleştirin.

Dürüstlük burada da işe yarar. README dosyasında hangi kısımlarda yardımcı araç kullandığınızı kısaca belirtmek, olgun bir yaklaşım olarak görünür. Ayrıca bu açıklama, görüşmede size zor bir soru yerine rahat bir sohbet başlangıcı sağlar.

Kısacası araç hızınızı artırır; ancak karar, mimari ve hata ayıklama hâlâ sizin sorumluluğunuzdadır.

Mülakatta projenizi nasıl anlatmalısınız?

Proje anlatımı, teknik mülakatın en çok puan kazandıran kısmıdır. Ancak birçok aday bunu teknoloji listesi okumaya dönüştürür. Bunun yerine sorun, karar ve sonuç sırasını izleyin.

Örneğin şöyle bir çerçeve kullanabilirsiniz: "Randevu sisteminde çakışan kayıtlar oluşuyordu. Veritabanında benzersiz kısıt ekledim ve istemci tarafında iyimser güncellemeyi geri alan bir akış kurdum. Sonuç olarak çift kayıt sorunu ortadan kalktı." Bu anlatım, hem teknik bilgiyi hem de problem çözme biçiminizi gösterir.

Ayrıca bir sonraki soruya hazırlıklı olun: "Bugün baştan yapsan neyi değiştirirdin?" Bu soruya dürüst ve somut cevap veren aday, kendini geliştiren biri olarak algılanır. Dolayısıyla her projeniz için en az bir "yeniden yapsam" notu hazırlayın.

Son olarak demoyu görüşme öncesinde mutlaka açın. Canlı paylaşımda çöken bir demo, iyi hazırlanmış bir anlatımı bile gölgeleyebilir.

Portföy projelerinde en sık hangi hataları görüyorum?

Yıllar içinde incelediğim portföylerde aynı hatalar tekrar ediyor. Bunları bilmek, full stack proje fikirleri listesinden seçim yaparken de işinizi kolaylaştırır.

• Mobil görünümü test etmemek: masaüstünde kusursuz, telefonda dağınık arayüz.
• README olmadan depo paylaşmak ya da şablon README'yi olduğu gibi bırakmak.
• API anahtarlarını veya şifreleri depoya yüklemek.
• Her projede farklı framework denemek ve hiçbirinde derinleşmemek.
• Kırık demo bağlantıları ve boş veri ekranları.

Bu hataların ortak noktası, projeyi bitirdikten sonra kullanıcı gözüyle bakmamaktır. Bu nedenle her projeyi yayınlamadan önce bir arkadaşınıza telefonda açtırın ve ne yaptığını izleyin. Böylece siz fark etmediğiniz sorunları beş dakikada görürsünüz.

Eğer ileride müşterilere web projesi teslim etmeyi düşünüyorsanız, bu kontrol alışkanlığı işin kendisidir. Web tasarım hizmetimde de her teslimden önce aynı mobil, erişilebilirlik ve hız kontrollerini uyguluyorum.

Sonuç: hangi projeyle başlamalısınız?

Bugün başlayacaksanız kişisel tanıtım sayfanızla başlayın; ama onu sıradan bir kartvizit değil, erişilebilir ve hızlı bir örnek olarak kurun. Ardından bir API projesi, bir framework projesi ve bir full stack uygulama ekleyin.

Her projede aynı üç soruyu sorun: bu proje hangi beceriyi kanıtlıyor, README bunu anlatıyor mu, demo canlı ve sağlam mı? Bu üç sorunun cevabı evetse, portföyünüz liste uzunluğuyla değil, kalitesiyle konuşur.

Kısacası full stack proje fikirleri sınırsız, ama zamanınız sınırlı. Az sayıda, iyi anlatılmış ve gerçekten çalışan projeler seçin; gerisini zamanla eklersiniz.