Toate ghidurile

Un portofoliu GitHub care îți aduce interviuri

Ce proiecte să construiești, cum scrii README-uri bune și cum îți organizezi profilul GitHub ca să convingi recruteri și developeri.

Pentru un junior, profilul de GitHub este adesea singura dovadă concretă că știe să scrie cod. Un recruiter îl deschide pentru câteva clipe, iar un developer care te evaluează poate petrece mai mult timp citindu-ți proiectele. Ghidul acesta îți arată cum să-l organizezi astfel încât amândoi să găsească repede ce caută.

Ce caută cine îți deschide profilul

Doi oameni diferiți, două liste diferite.

Recruiterul verifică rapid:

  • dacă profilul arată îngrijit (nume, poză, bio);
  • dacă proiectele fixate au nume clare și descrieri;
  • dacă există un demo sau capturi de ecran;
  • dacă tehnologiile se potrivesc cu rolul.

Developerul deschide un proiect și se uită la:

  • README: ce face proiectul și cum îl rulează;
  • structura folderelor și denumiri;
  • calitatea codului: funcții scurte, nume clare, fără blocuri mari de cod comentat;
  • istoricul de commit-uri;
  • existența testelor și a unui CI minimal.

Nimeni nu se așteaptă ca un junior să scrie cod perfect. Se așteaptă să vadă grijă, consecvență și capacitatea de a duce un proiect până la capăt.

Profilul: prima impresie

Ordinea de lucru:

  1. Numele real și o poză clară. Un username fantezist nu e un capăt de lume, dar numele real îl ajută pe recruiter să lege profilul de CV.
  2. Un bio scurt: rolul țintă și stack-ul. Exemplu: „Junior backend developer · Python, FastAPI, PostgreSQL · Cluj-Napoca”.
  3. Proiectele fixate (pinned). GitHub îți permite să fixezi câteva repository-uri pe profil. Pune acolo doar proiectele după care vrei să fii judecat.
  4. README-ul de profil. Dacă creezi un repository public cu exact același nume ca username-ul tău, fișierul său README.md apare pe pagina de profil.

Un README de profil scurt e mai eficient decât unul încărcat cu badge-uri, statistici și animații:

### Salut, sunt Ana

Mă reprofilez din contabilitate în backend development.
Lucrez cu Python, FastAPI și PostgreSQL.

**Proiecte principale**
- buget-asociatie: API pentru cheltuielile unei asociații de proprietari
- raport-facturi: script care generează rapoarte lunare din fișiere CSV

Caut un rol de Junior Backend Developer (Cluj-Napoca sau remote).

Câte proiecte și de ce fel

Două-trei proiecte bine făcute bat oricând douăzeci de clone după tutoriale. Un proiect „bine făcut” rezolvă o problemă clară, are README, poate fi rulat de altcineva și arată că ai luat decizii proprii.

DirecțieExemple de proiecte relevante
Frontendaplicație care consumă un API public, formular complex cu validare, interfață responsive și accesibilă
BackendAPI REST cu autentificare, bază de date relațională, teste și documentație
Full-stackaplicație completă: frontend, backend, bază de date și deploy
Dataanaliză pe un set de date public, cu notebook curat și concluzii scrise
QAsuită de teste automate pentru o aplicație demo, rulată în CI
DevOpsaplicație containerizată, pipeline CI/CD, infrastructură descrisă în cod

Cele mai convingătoare idei vin din experiența ta. Dacă ai lucrat în logistică, construiește un tracker de livrări. Dacă ai fost profesor, o aplicație care generează teste. Astfel ai o poveste bună pentru interviu și, de multe ori, utilizatori reali care îți dau feedback.

Anatomia unui repository bun

README-ul

README-ul este pagina de prezentare a proiectului. Scrie-l în limba în care aplici, de obicei engleză. Un schelet care funcționează (aici în română, pentru claritate):

# Buget Asociație

API pentru evidența cheltuielilor unei asociații de proprietari:
facturi, repartizare pe apartamente și rapoarte lunare.

## Demo
Link către demo și 2-3 capturi de ecran.

## Funcționalități
- Autentificare pentru administrator
- Import de facturi din CSV
- Calcul automat al cotelor pe apartament

## Tehnologii
Python, FastAPI, PostgreSQL, Docker, pytest

## Rulare locală
docker compose up

## Decizii tehnice
De ce am ales PostgreSQL, cum am structurat calculul cotelor,
ce aș face diferit într-o versiune următoare.

Secțiunea „Decizii tehnice” este cea pe care o sar majoritatea juniorilor, deși e una dintre cele mai utile pentru un evaluator tehnic. Arată că știi de ce ai făcut ceva, nu doar cum.

Fișierele care arată profesionalism

  • un .gitignore potrivit pentru stack (fără node_modules, fără fișiere de build, fără .env);
  • un fișier .env.example cu variabilele necesare, dar fără valori reale;
  • teste pentru logica principală, chiar dacă sunt puține;
  • o licență, dacă vrei ca alții să poată folosi codul;
  • un Dockerfile sau instrucțiuni clare de instalare.

Un CI minimal cu GitHub Actions

Un workflow care rulează testele la fiecare push arată că lucrezi ca într-o echipă. Un exemplu pentru un proiect Node.js:

name: CI
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: lts/*
      - run: npm ci
      - run: npm test

Fișierul se salvează în .github/workflows/ci.yml. Badge-ul cu statusul workflow-ului, pus în README, e un detaliu mic, dar vizibil.

Codul: ce observă un evaluator în primele minute

Un developer care îți deschide proiectul nu citește tot codul. Deschide două-trei fișiere importante și își face o părere rapidă. Lucrurile care contează cel mai mult în acele minute:

  • Formatare consecventă. Folosește un formatter și un linter (de exemplu Prettier și ESLint pentru JavaScript, Ruff sau Black pentru Python) și rulează-le automat. Codul formatat inconsecvent sugerează neatenție, chiar dacă logica e corectă.
  • Nume care explică intenția. calculeazaCotaApartament() spune mai mult decât calc2(), iar facturiNeplatite mai mult decât lista.
  • Funcții scurte, cu o singură responsabilitate. O funcție de 150 de rânduri care citește, validează, calculează și salvează e un semnal că structura n-a fost gândită.
  • Erori tratate explicit. Ce se întâmplă dacă API-ul extern nu răspunde sau fișierul CSV are o coloană lipsă? Un mesaj clar valorează mai mult decât o aplicație care se oprește brusc.
  • Fără resturi de debugging. Șterge console.log-urile uitate, blocurile mari de cod comentat și fișierele de test temporare.
  • Configurația separată de cod. URL-uri, porturi și chei vin din variabile de mediu, nu sunt scrise direct în fișiere.

Un truc simplu: înainte să fixezi un proiect pe profil, citește-i codul ca și cum l-ar fi scris altcineva. Tot ce te face să te încrunți va avea același efect și asupra unui evaluator.

Commit-uri care spun o poveste

Istoricul de commit-uri arată cum lucrezi. Un singur commit „final version” cu tot proiectul ridică semne de întrebare, iar zeci de commit-uri numite „fix” nu spun nimic.

git switch -c feature/csv-import
git commit -m "Add CSV import for invoices"
git commit -m "Validate required columns on import"
git commit -m "Add tests for incomplete CSV files"
git push -u origin feature/csv-import

Obiceiuri bune:

  • commit-uri mici, fiecare cu o singură schimbare logică;
  • mesaje care spun ce face schimbarea;
  • branch-uri pentru funcționalități și pull request-uri, chiar dacă lucrezi singur; în descrierea PR-ului explici ce ai schimbat, exact ca într-o echipă;
  • issues pentru ce urmează să faci, ca un mic backlog.

Unele echipe folosesc convenții precum Conventional Commits (feat:, fix:, docs:). Nu sunt obligatorii, dar arată că știi că în echipe există reguli comune. Mesajele pot fi în română sau în engleză; alege o limbă și fii consecvent. Pentru proiectele din portofoliu, engleza e de obicei alegerea mai sigură, pentru că oricine îți poate citi istoricul.

Demo live și capturi de ecran

Un proiect pe care îl poți vedea în câteva secunde are mult mai multe șanse să fie explorat.

  • Site-uri statice și aplicații frontend: GitHub Pages este gratuit și se integrează direct cu repository-ul.
  • Aplicații cu backend: platformele de hosting cu plan gratuit își schimbă des condițiile, așa că verifică ofertele actuale înainte să alegi. Dacă aplicația „adoarme” când nu e folosită și pornește greu, menționează asta în README.
  • Când nu ai demo: pune capturi de ecran sau un GIF scurt și asigură-te că proiectul pornește local cu o singură comandă, de exemplu docker compose up. Dacă n-ai lucrat încă cu containere, roadmap-ul Docker e un bun punct de plecare.

Ce să eviți

  • Secrete în cod. Chei de API, parole sau token-uri urcate pe GitHub sunt o greșeală gravă. Dacă s-a întâmplat, nu e suficient să ștergi fișierul: istoricul Git le păstrează, așa că cheia trebuie revocată și înlocuită imediat.
  • Forkuri fără nicio modificare, care doar umplu profilul.
  • Repo-uri numite test, proiect-nou sau asdf. Fă-le private sau arhivează-le.
  • node_modules, fișiere de build sau baze de date locale urcate în repository.
  • Obsesia graficului de contribuții. Pătrățelele verzi nu sunt un obiectiv în sine. Un commit artificial pe zi nu impresionează pe nimeni care se uită la conținut.

Contribuțiile open source

Nu sunt obligatorii pentru un junior, dar ajută dacă sunt reale. Caută proiecte pe care le folosești deja și etichete precum good first issue. Începe cu documentație, teste sau bug-uri mici și citește fișierul CONTRIBUTING.md înainte să deschizi un pull request. Un PR mic, acceptat după o discuție cu maintainerii, valorează mai mult decât zece corecturi cosmetice trimise în serie.

Cum legi portofoliul de CV și LinkedIn

  • Fiecare proiect din CV are link direct către repository și demo.
  • Proiectele fixate pe GitHub sunt aceleași cu cele din CV.
  • În secțiunea „Featured” de pe LinkedIn poți pune proiectul principal.
  • Descrierile sunt consecvente peste tot: aceleași tehnologii, aceeași poveste.

Checklist rapid

  • Nume, poză și bio completate.
  • 2-4 proiecte fixate, toate cu descriere.
  • Fiecare proiect fixat are README cu demo sau capturi de ecran și instrucțiuni de rulare.
  • Niciun secret în cod sau în istoricul Git.
  • Cel puțin un proiect are teste și CI.
  • Repo-urile irelevante sunt private sau arhivate.

Pașii următori

  1. Alege cel mai bun proiect și rescrie-i README-ul după scheletul de mai sus.
  2. Dacă nu te simți sigur pe branch-uri, pull request-uri și Actions, parcurge roadmap-ul Git și GitHub și documentația oficială GitHub.
  3. Planifică un proiect nou pornind de la o problemă din domeniul tău anterior.
  4. Roagă un developer să se uite la profilul tău timp de două minute și să-ți spună ce a reținut.