2.4 Portfolio projektek – mit mutass és hogyan

Áttekintő

Minden junior fejlesztő ugyanazt a kérdést teszi fel: „Mennyi projektet tegyünk a portfoliónkba?" Rossz kérdés. A jobb kérdés: „Melyik projektet érdemes megmutatni, és hogyan?"

Egy recruiter átlagosan 30-60 másodpercet néz egy junior GitHub-profilra. Nem a mennyiség számít – a minőség, az áttekinthetőség, és az, hogy a projekted egyáltalán működik-e.

Ebben az alfejezetben megtanulod:

Mi a különbség egy „tanulóprojekt" és egy igazi portfolió-projekt között
Hogyan írj README-t, amit egy idegen is megért
Miért (és hogyan) deployálj élő demót
Mit ne tegyél ki – mert az is számít

Ez miért számít az állásinterjún?
A legtöbb technikai interjú azzal kezdődik: „Mesélj egy projektedről." Ha nincs mit megmutatnod, vagy amit megmutatasz nem működik – már az elején hátrányból indulsz.

Részletes leírás

Mi a különbség tanulóprojekt és portfolió-projekt között?

Gondolkodj így: a tanulóprojekt neked szól – hogy megtanulj valamit. A portfolió-projekt a recruiterre és a hiring managerre van szabva – hogy megmutasd, mit tudsz.

Szempont	Tanulóprojekt	Portfolió-projekt
Cél	Tanulás	Megmutatás
Állapot	Lehet félkész	Befejezett, működő
README	Általában nincs	Van, részletes
Deploy	Nincs	Van (elvárható)
Kód minősége	Kísérletező	Rendezett, olvasható
Commit history	Kaotikus	Értelmező üzenetekkel

A jó hír: egy meglévő tanulóprojektből portfolió-projekt lehet – ha időt szánsz rá.

Hány projekt elég?

2-3 erős projekt messze jobb, mint 10 félkész tutorial-klón.

Az ideális portfolió:

1 kiemelt projekt – ez a „flagship" projekted, amire büszke vagy, amit részletesen elmesélsz interjún
1-2 kiegészítő projekt – különböző területeket mutat meg (pl. frontend-heavy vs. backend-heavy)
(opcionális) 1 nyílt forráskódú hozzájárulás – de ez nem elvárás junioroknál

Ha most nincsenek projektjeid: egy jó projekt elegendő az álláskeresés megkezdéséhez, amíg a többi épül.

A README – a projekted névjegykártyája

A README az első dolog, amit egy recruiter vagy developer lát, amikor megnyitja a GitHub repódat. Ha nincs README, vagy csak „TODO: readme" áll benne – az rossz benyomás.

Egy jó README minimuma:

# Projekt neve

Egy-két mondat: mi ez és mire való.

## Funkciók
- Mit tud a projekt

## Technológiák
- Python 3.11, FastAPI, PostgreSQL, Docker

## Telepítés és futtatás

git clone https://github.com/... cd projekt cp .env.example .env docker-compose up


## Élő demo
https://projektem.fly.dev

## Képernyőképek
(ha van UI)

Amit sokan elfelejtnek:

Az .env.example fájl (hogy másolandó, nem kitöltendő .env kerüljön a repóba)
A telepítési lépések – teszteld le, hogy valóban működnek-e egy friss gépen
A miért – egy-két mondat arról, hogy milyen problémát old meg a projekt

Amit ne írj: "Ez egy iskolai feladat", "Ez csak gyakorlás volt", "Nem fejeztem be". Ha leírod, hogy nem kész – miért mutatod meg?

Deployment – az élő demo

Ha a projekted csak a gépeden fut, az recruiternek semmi. Az élő demo azt mutatja, hogy:

A projekted valóban működik
Tudsz valamit a deploymentről (kis plusz pont)
A recruiter saját maga ki tudja próbálni

Ingyenes deployment opciók (2026):

Platform	Mire jó
Render.com	Backend API-k, full-stack alkalmazások
Fly.io	Docker-alapú deployment, ingyenes tier
Vercel	Frontend (React, Next.js), statikus oldalak
Netlify	Statikus frontend
Railway	Full-stack + adatbázis együtt
Supabase	Ha Postgres-t is deployálsz

Fontos: Az ingyenes tierek általában „sleep after inactivity" módba kapcsolnak. Ez azt jelenti, hogy az első kérés 10-20 másodperc késéssel jön. Tegyél erről egy megjegyzést a README-be:

„Az első betöltés 10-15 másodpercet vehet igénybe, mert a szerver inaktivitás után alszik."

Ha nincs elérhető deploy (pl. desktop alkalmazás, CLI tool, adatbázis-heavy projekt): egy jó demo videó vagy animált GIF is megoldás. Sokkal jobb a semminél.

Mit NE mutass a portfolióban

Ez legalább annyira fontos, mint az, amit megmutatsz.

❌ Tutorial-klónok „as-is"
Ha Udemy-n vagy YouTube-on követtél egy tutorialt és azt töltöd fel – az nem számít portfolió-projektnek. Mindenki megcsinálja ugyanazt. Ha mégis felteszed: bővítsd ki saját ötlettel, és írd le a README-ben, hogy mi az, amit te adtál hozzá.

❌ Félkész projektek
Ha egy projekt 60%-ban kész, nem tölt fel semmiféle bizalmat. Ha nincs kész: vagy befejezed, vagy nem töltöd fel (vagy archiválod a repót).

❌ Üres repók vagy „initial commit" projektből
Ha az utolsó commit 2 éve volt, és csak 1-2 commit van, az rosszabb, mintha nem lenne ott.

❌ API kulcsok és jelszavak a kódban
Szinte minden junior elkövet egyszer – de ha a portfolióban van, az komoly red flag. Mindig .env + .gitignore, mindig.

❌ 10+ projekt, mind rossz állapotban
A sok félkész projekt azt mutatja, hogy nem fejezel be semmit. Kevesebb, de jobb.

Hogyan alakíts meglévő tanulóprojektből portfolió-projektet?

Egy meglévő projektet így lehet „portfolió-ready" állapotba hozni:

Távolítsd el a TODO kommenteket és debug kódot
Írj README-t (a fenti sablon alapján)
Ellenőrizd, hogy a .gitignore helyes-e (nincs .env a repóban)
Deployáld vagy készíts demo videót
Rendezd át a commit historyt – ha tele van „asdf" vagy „fix" commitokkal, legalább a jövőbeli commitokat írd értelmesen
Adj hozzá egy saját funkciót – ha tutorial-klón volt, bővítsd ki valamivel

Nem kell tökéletesnek lennie – de befejezettnek kell látszania.

A projekt kiválasztása: miről szóljon?

Legjobb, ha a projekt egy valódi problémát old meg – akár egy kis, személyes problémát is.

Példák:

„Lejárat-figyelő app a hűtőbe tett ételekhez" – egyszerű, de eredeti
„Saját könyvjegyző CLI tool" – technikai, de egyedi
„Kis webshop egy fiktív termékre" – CRUD + auth + deployment megvan

Kerüld: „Todo app" (mindenki csinálja), „Weather app" (tutorial standard), „Calculator" (nem mutat semmi valódit).

Életszerű példák

Példa 1: A recruiter és a GitHub profil

Kata frissen végezte el a bootcamp-et. 12 repója van, de:

8 az üres vagy "init commit" állapotban van
3 tutorial-klón README nélkül
1 projekt félig kész

Péter 3 hónapja tanul, de csak 2 projektet töltött fel:

Egy saját ötlet (recepttároló app) – kész, README-vel, deployálva
Egy backend API – dokumentált, Postman collection csatolva

A recruiter 45 másodperc után továbblép Katánál. Péternél 3 percet tölt, és e-mailt ír.

Példa 2: Az „ez csak tanulásra volt" trap

Gábor feltölt egy projektet, aminek neve: react-learning-2024. A README-ben:
"Ez egy kísérlet volt, nem kész, csak tanulásnál csináltam."

Ezzel ő maga mondja meg a recruitérnek, hogy ez nem számít. Soha ne magyarázkodj előre. Ha nem éri el a portfolió-projekt szintet – ne töltsd fel, vagy archiváld el.

Példa 3: A README ereje

Két projekt, ugyanaz a funkcionalitás (egyszerű todo alkalmazás):

A verzió (tipikus):

Repó neve: todo-app
README: nincs
Deploy: nincs
Commit history: "first commit", "fix", "update"

B verzió (portfolió-ready):

Repó neve: task-flow (jobb név!)
README: telepítési útmutató, tech stack, screenshot, élő demo link
Deploy: Render.com-on fut
Commit history: feat: add task creation endpoint, fix: resolve date parsing edge case

Melyiket veszi észre a hiring manager? Nem kérdés.

Példa 4: Tutorial-klón bővítése

Mari megcsinálta a klasszikus YouTube "Build a blog with Django" tutorialt. Ahelyett, hogy feltölti 1:1-ben, hozzáad 3 extra funkciót:

Email-alapú bejelentkezés (nem username)
Tag-rendszer a cikkekhez
RSS feed

A README-be beírja: "A projekt alapja egy Django tutorial, amit a következő funkciókkal egészítettem ki: ..."

Ez már portfolió-projekt. Az extra munka + az őszinteség = pozitív benyomás.

Tesztfeladatok

1. feladat – Portfolió-projekt felismerése

Az alábbiak közül melyik számít erős portfolió-projektnek? (Több helyes válasz is lehetséges)

A) Egy tutorial-alapú blog app, amit saját funkciókkal bővítettél, és README-vel töltöttél fel
B) 15 repó, mind 1-2 committal
C) Egy CLI eszköz, amit te terveztél, Fly.io-n deployálva, jó dokumentációval
D) Egy React frontend egy nyilvános API-hoz, Vercel-en élőben, animált GIF demóval a README-ben
E) Egy befejezetlen „social media platform" projekt, amit nem tudtál deployálni

2. feladat – README elemek

Melyik elem NEM szükséges egy junior portfolió-projekt README-jébe?

A) A projekt rövid leírása
B) Telepítési és futtatási utasítások
C) Az összes commit history magyarázata
D) Használt technológiák listája
E) Élő demo link vagy képernyőkép

3. feladat – Mit NE mutass?

Döntsd el, hogy az alábbi projektek közül melyeket érdemes portfoliójában szerepeltetni, melyeket nem, és miért!

A) weather-app-tutorial – Udemy tutorial, pontosan úgy ahogy a videón volt, README nélkül
B) expense-tracker – saját ötlet, kész, SQLite adatbázissal, README-vel, de nincs deploy
C) my-first-react-app – "Hello World" szintű, 1 commit
D) reading-list-api – REST API könyvekhez, Docker-rel, Postman dokumentációval, Railway-en fut

4. feladat – Deployment döntés

Melyik állítás igaz az élő demókra vonatkozóan?

A) Ha az alkalmazás ingyenes szerveren van, a recruiter biztosan nem veszi komolyan
B) Egy animált GIF vagy videó a README-ben elfogadható alternatíva, ha nincs deploy lehetőség
C) Csak akkor érdemes deployálni, ha a projekt 100%-ban kész
D) A deployment nem számít, csak a kód minősége

5. feladat – Projektek száma

Mit jelent a „minőség > mennyiség" elve a portfoliónál?

A) Mindig pontosan 3 projekted kell, hogy legyen
B) 2-3 befejezett, dokumentált, működő projekt jobb benyomást kelt, mint 10 félkész repó
C) Az 1 projekt nem elég – legalább 5 kell az álláskeresés megkezdéséhez
D) A mennyiség is számít, mert megmutatja a szorgalmat

6. feladat – Tutorial-klón kezelése

Hogyan alakítasz egy tutorial-klónból portfolió-projektet?

A) Átnevezed a projektet és úgy töltöd fel, mintha saját ötleted lett volna
B) Kiegészíted saját funkciókkal, README-be leírod mi a saját hozzájárulásod, és deployálod
C) Pontosan úgy töltöd fel, ahogy a tutorial végén elkészült
D) Tutorial-klónokat soha nem szabad feltölteni semmilyen formában

7. feladat – README hiba azonosítása

Egy junior ezt írja a README-be:

"Ez egy iskolai projekt volt, nem fejeztem be, sok hibája van, de feltöltöttem tanulás céljából."

Mi a probléma ezzel?

A) Semmi, ez őszinte és a recruiter értékeli az átláthatóságot
B) A README nem elég részletes – kellene telepítési útmutató is
C) A junior maga gyengíti a projekt értékét – ha nincs kész, nem kellene feltenni
D) Az iskolai projekteket nem szabad GitHub-ra feltölteni

8. feladat – Projekt ötlet értékelés

Melyik projekt ötlet a legerősebb portfolió-projektnek?

A) todo-app – klasszikus CRUD alkalmazás, amit mindenki megcsinált már
B) weather-app – OpenWeatherMap API-t használ, mindenki csinálja
C) grocery-expiry-tracker – értesít, amikor lejárnak az élelmiszerek a hűtőben
D) calculator – összeadást, kivonást, szorzást kezel

9. feladat – Commit history és portfolió

Miért számít a commit history a portfolió-projektben?

A) Nem számít, csak a végeredmény látszik
B) A jó commit üzenetek megmutatják, hogy szakszerűen dolgozol és gondolsz a jövőbeli olvasókra
C) Minél több commit, annál jobban látszik a munka mennyisége
D) A commit historyt a recruiterek sosem nézik

10. feladat – Komplex döntés

Két hét múlva állásinterjúra mész. Jelenleg 0 portfolió-projekted van. Mi a legjobb stratégia?

A) Elkezdeni 5 projektet egyszerre, hogy legyen mire mutatni
B) Megcsinálni egy nagy, komplex projektet teljesen (2 hét nem elég)
C) Egy egyszerű, de befejezett projektet teljesen kész állapotba hozni: README, deploy, tiszta kód – és azt megmutatni
D) Lemondani az interjúról, amíg nincs portfoliód

Következő alfejezet: 2.5 – Tömeges jelentkezés stratégiája – a 100+ jelentkezés módszertana