Kodėl pet projektai svarbiau nei atrodo
Jei esi pradedantysis programuotojas arba tiesiog ieškai darbo IT sektoriuje, turbūt ne kartą girdėjai frazę „parodyk savo portfolio”. Ir čia prasideda tikroji problema – ką ten rodyti, jei neturi komercinio darbo patirties? Atsakymas paprastas: pet projektus. Bet ne bet kokius.
Pet projektas – tai asmeninis projektas, kurį kuri savo iniciatyva, be jokio darbdavio ar kliento spaudimo. Gali rinktis technologijas, kurios tau įdomios, gali eksperimentuoti, gali padaryti klaidų ir iš jų mokytis. Tai vieta, kur nėra „production je dega” panikos ir kur gali išbandyti tą naują framework’ą, kurį matei Twitter’yje.
Tačiau čia yra subtilybė, kurią dažnai ignoruoja pradedantieji: ne kiekvienas pet projektas yra vienodai vertingas portfolio’ui. Dar vienas todo list’as ar skaičiuotuvas tikrai nepadarys įspūdžio jokiam recruiter’iui. Reikia kažko, kas parodo, kad moki spręsti realias problemas, kad supranti, kaip veikia sistemos, ir kad gali priimti architektūrinius sprendimus.
Klasikinės idėjos, kurias verta perdaryti kitaip
Prieš einant prie originalių idėjų, pakalbėkime apie tai, kaip galima paimti „nuobodžią” klasikinę idėją ir padaryti ją įdomią. Nes kartais problema ne idėja, o jos implementacija.
Imkime todo list’ą. Visi jį daro. Bet ką, jei tavo todo list’as turėtų:
- Real-time sinchronizaciją tarp kelių įrenginių naudojant WebSocket’us
- Offline palaikymą su Service Worker’iais ir IndexedDB
- Automatinį užduočių prioritizavimą pagal deadline’us ir darbo krūvį
- Statistikos dashboardą su vizualizacijomis
Matai skirtumą? Tai jau nebe paprastas todo list’as – tai produktyvumo įrankis su realiu technical depth’u. Tas pats principas veikia su bet kuria „nuobodžia” idėja. Skaičiuotuvas gali tapti finansų planuokliu su grafais. Oras gali tapti personalizuotu oro prognozių agregatorium su notifikacijomis.
Esmė ta, kad recruiter’iai ir senior’ai, žiūrintys į tavo portfolio, ieško ne originalios idėjos – jie ieško techninio sudėtingumo ir gebėjimo priimti sprendimus. Originali idėja yra bonus, bet ne būtinybė.
Projektai, kurie tikrai išsiskiria
Dabar prie konkrečių idėjų. Pabandysiu pateikti ne tik idėją, bet ir paaiškinti, kodėl ji veikia ir ką techniškai galima implementuoti.
1. Asmeninis finansų tracker’is su banko statement’ų parsavimo funkcija
Tai projektas, kurį galima naudoti realiai. Parsink CSV failus iš savo banko, kategorizuok išlaidas, vizualizuok tendencijas. Techniškai čia yra file parsing, duomenų normalizavimas (skirtingi bankai eksportuoja skirtingais formatais), kategorijų atpažinimas naudojant paprastą ML arba tiesiog regex’us, ir gražios vizualizacijos su Chart.js ar D3.js. Jei nori pridėti daugiau sudėtingumo – implementuok budget’o planavimą su alert’ais, kai artėji prie limito.
2. Decentralizuota knygų apsikeitimo platforma
Žmonės turi krūvas knygų, kurių nebeskaitys. Sukurk platformą, kur vartotojai gali registruoti savo knygas ir ieškoti match’ų su kitais. Čia yra geolokacija (rodyti knygas netoli tavęs), matching algoritmas, messaging sistema ir user authentication. Jei nori – implementuok rating sistemą ir reputacijos mechanizmą.
3. Kodo review bot’as GitHub’ui
Tai jau rimtesnis projektas, bet labai įspūdingas. Sukurk GitHub Action arba webhook’ą, kuris automatiškai komentuoja pull request’us pagal tavo nustatytas taisykles – tikrina kodo stilių, ieško common anti-pattern’ų, skaičiuoja complexity metrikas. Čia yra GitHub API integracija, AST parsing (Abstract Syntax Tree), ir galbūt OpenAI API integracija, jei nori „smart” komentarų.
Full-stack projektai, kurie parodo sisteminį mąstymą
Jei taikais į full-stack arba backend pozicijas, tau reikia projektų, kurie parodo, kad supranti, kaip veikia sistemos kaip visuma – ne tik kaip parašyti React komponentą.
URL shortener’is su analytics – klasika, bet su twist’u. Visi žino bit.ly. Sukurk savo versiją, bet su detaliu analytics dashboardu: kiek kartų paspaustas link’as, iš kokių šalių, kokiais įrenginiais, kokiu laiku. Čia yra rate limiting (kad niekas negalėtų spaminti), Redis caching (trumpi URL’ai turi būti greitai atrenkami), geolocation API integracija ir time-series duomenų saugojimas. Tai projektas, kuris parodo, kad galvoji apie performance ir scalability.
Distributed task queue – tai jau senior lygio projektas. Implementuok paprastą task queue sistemą, panašią į Celery arba Bull. Producers siunčia tasks, workers jas apdoroja, yra retry logika, dead letter queue ir monitoring dashboard’as. Čia yra message broker’iai (Redis arba RabbitMQ), concurrent processing, error handling ir observability. Tai projektas, kuris parodo, kad supranti distributed systems konceptus.
Real-time collaboration tool – kažkas panašaus į Google Docs, bet paprastesnė versija. Implementuok real-time teksto redagavimą su Operational Transformation arba CRDT algoritmais. Tai techniškai sudėtinga, bet labai įspūdinga. WebSocket’ai, conflict resolution, presence indicators (kas šiuo metu redaguoja) – visa tai yra puikus technical showcase.
Machine Learning projektai, kurie neatrodo kaip tutorial’ai
ML portfolio projektai turi vieną didelę problemą – dauguma jų yra tiesiog Kaggle tutorial’ų kopijos su Titanic arba Iris dataset’ais. Recruiter’iai tai mato iš karto. Štai kaip padaryti kitaip.
Asmeninis rekomendacijų variklis – sukurk sistemą, kuri rekomenduoja filmus, knygas arba muzikos albumus pagal tavo paties istoriją. Bet ne naudojant Netflix dataset’ą – naudok savo duomenis. Eksportuok savo Letterboxd, Goodreads arba Spotify istoriją ir sukurk collaborative filtering arba content-based filtering modelį. Tai parodo, kad gali dirbti su „messy” realiais duomenimis, o ne švariais tutorial duomenimis.
Spam detector’ius savo email’ams – parsink savo email’ų istoriją (Gmail leidžia eksportuoti), pažymėk spam ir ne-spam laiškus, ir ištreniruok klasifikatorių. Čia yra NLP preprocessing (tokenizacija, stop words removal, TF-IDF), modelio treniravimas ir evaluacija, ir galbūt net deployment kaip browser extension. Tai labai praktiškas projektas, kurį gali naudoti realiai.
Kainų prognozavimo sistema – pasirink kokią nors nišą (pvz., naudotų automobilių kainos, butų nuoma tam tikrame mieste) ir sukurk modelį, kuris prognozuoja kainas. Scrape’ink duomenis, atlik feature engineering, palygink kelis modelius ir sukurk API endpoint’ą, per kurį galima gauti prognozes. Tai parodo visą ML pipeline’ą nuo duomenų surinkimo iki deployment’o.
DevOps ir infrastruktūros projektai
Jei taikais į DevOps, SRE arba tiesiog nori parodyti, kad supranti daugiau nei tik kodą, šie projektai tau labai pravers.
Sukurk savo monitoring stack’ą – naudok Prometheus ir Grafana, kad sukurtum monitoring sistemą savo pet projektams. Instrumentuok savo aplikacijas, sukurk dashboardus, nustatyk alert’us. Tai parodo, kad galvoji apie observability ir production readiness. Bonus: dokumentuok viską kaip Infrastructure as Code naudojant Terraform arba Ansible.
CI/CD pipeline’as nuo nulio – sukurk pilną CI/CD pipeline’ą savo projektui: automatiniai testai, code quality checks, Docker image build’inimas, deployment į cloud provider’į. Naudok GitHub Actions arba GitLab CI. Tai labai praktiškas projektas, nes tokius pipeline’us reikia konfigūruoti beveik kiekviename darbe.
Kubernetes cluster’is ant Raspberry Pi – jei turi kelis Raspberry Pi (arba nori investuoti į juos), sukurk namų Kubernetes cluster’į. Tai labai hands-on patirtis su container orchestration, networking ir storage. Tai ne tik įdomu, bet ir parodo, kad esi tikras entuziastas, kuris mokosi ne tik iš tutorial’ų.
Kaip pristatyti projektą, kad jis atrodytų profesionaliai
Net geriausias projektas gali atrodyti blogai, jei jis blogai pristatytas. Štai keletas praktinių patarimų, kurie labai skiriasi nuo to, ką daro dauguma.
README yra tavo pardavimo laiškas. Daugelis programuotojų rašo README kaip techninę dokumentaciją. Bet pirmiausia jis turi atsakyti į klausimą: „Kodėl šis projektas egzistuoja ir ką jis sprendžia?” Pradėk nuo problemos, tada paaiškink sprendimą, tada techninę implementaciją. Pridėk screenshots arba GIF’us – vizualinis turinys labai padeda.
Architecture Decision Records (ADR) – tai dokumentai, kuriuose paaiškini, kodėl priėmei tam tikrus architektūrinius sprendimus. Pvz., „Kodėl pasirinkau PostgreSQL vietoj MongoDB?” Tai parodo, kad ne tik moki rašyti kodą, bet ir galvoji apie kompromisus. Senior’ai tai labai vertina.
Live demo yra privalomas. Jei projektas neturi live demo, daugelis recruiter’ių jo tiesiog neatidarys. Naudok Vercel, Netlify, Railway arba Render – visi jie turi free tier’us. Jei projektas reikalauja backend’o, sukurk demo account’ą su pavyzdiniais duomenimis, kad recruiter’is galėtų iš karto pamatyti, kaip viskas veikia.
Testai nėra optional. Bent jau unit testai. Tai parodo, kad rašai production-ready kodą, o ne tik „veikia ant mano kompiuteryje” kodą. Jei nori extra points – pridėk code coverage badge’ą į README.
Commit istorija turi prasmę. Jei tavo projektas turi vieną commit’ą „initial commit” arba „fix stuff”, tai labai blogai atrodo. Rašyk aiškius commit message’us, naudok conventional commits formatą, rodyk, kad projektas vystėsi palaipsniui.
Kai portfolio tampa daugiau nei tik darbo paieška
Pats geriausias dalykas, kuris gali nutikti su pet projektu – jis tampa kažkuo daugiau. Žmonės pradeda jį naudoti. Atsiranda issues GitHub’e. Kažkas padaro pull request’ą. Tai jau open source patirtis, kuri yra aukso vertės portfolio’ui.
Todėl rinkdamasis pet projekto idėją, pagalvok: ar tai kažkas, ką patys žmonės norėtų naudoti? Ar tai sprendžia realią problemą, net jei ir nedidelę? Jei taip – yra tikimybė, kad projektas užaugs į kažką daugiau.
Kitas aspektas – mokymasis. Pet projektai yra geriausia vieta išbandyti technologijas, kurias nori išmokti. Nori išmokti Rust? Sukurk CLI įrankį Rust’u. Nori išmokti Go? Sukurk HTTP serverį. Nori išmokti Kubernetes? Deployink savo projektą į k8s. Mokymasis per praktiką yra daug efektyvesnis nei tutorial’ų žiūrėjimas.
Ir paskutinis, bet ne mažiau svarbus dalykas: nesistenkite padaryti visko iš karto. Geriau turėti du-tris gerai išbaigtus projektus nei dešimt pusiau padarytų. Recruiter’iai tai mato. Jei projektas turi 3 commit’us ir pusę implementuotos funkcionalumo – geriau jo nerodyk. Portfolio kokybė svarbiau nei kiekybė. Pasirink vieną idėją, kurią tikrai nori padaryti, ir padaryk ją gerai – su dokumentacija, testais, live demo ir aiškia commit istorija. Tai padarys daug didesnį įspūdį nei dešimt „work in progress” projektų.
