Wprowadzenie
GitHub stał się dla wielu rekruterów i inżynierów oprogramowania pierwszym miejscem, gdzie sprawdzają kompetencje kandydatów. Profil na GitHub, dobrze przygotowane repozytoria i sposób prezentacji projektów mogą zadecydować o zaproszeniu na rozmowę techniczną.
Co rekruterzy i zespoły techniczne sprawdzają na GitHub
Rekruterzy i inżynierowie patrzą na repozytoria z kilku perspektyw. Pierwsza to jakość kodu: czy kod jest czytelny, zrozumiały i dobrze zorganizowany. Druga to zrozumienie procesów inżynierskich: czy kandydat używa kontroli wersji poprawnie, czy zna przepływy pracy typu feature-branch, pull request i code review. Trzecia to umiejętności związane z infrastrukturą i automatyzacją: czy repozytorium zawiera konfiguracje CI/CD, testy jednostkowe i skrypty do automatycznego budowania. Kolejna ważna rzecz to dokumentacja: README, instrukcje uruchomienia i komentarze wyjaśniające architekturę projektu. Na końcu rekruterzy patrzą na aktywność: częstotliwość commitów, prace w grupie i udział w projektach open source. Wszystkie te elementy razem obrazują nie tylko umiejętności techniczne, ale i sposób pracy, komunikację oraz dbałość o jakość.
Jak przygotować profil GitHub jako element aplikacji o pracę
Pierwszy krok to zadbanie o profil. Uzupełnione zdjęcie (profesjonalne), krótki opis (bio) z informacją o specjalizacjach, lokalizacji i preferowanych technologiach oraz linki do portfolio lub strony osobistej. Ważne jest uporządkowanie repozytoriów: przypinanie najważniejszych projektów do profilu, uporządkowanie nazw i opisów repozytoriów oraz ustawienie czytelnych tagów i tematów (topics), które ułatwiają znalezienie projektów. Należy przemyśleć strukturę repozytoriów: czy lepiej trzymać osobne projekty w oddzielnych repozytoriach, czy mieć monorepo — decyzja powinna zależeć od powiązań między projektami i od tego, jak chcesz je zaprezentować. Profil powinien też pokazywać aktywność: regularne commity i wkład w projekty open source sygnalizują zaangażowanie i rozwój.
Jakie repozytoria załączyć w aplikacji — ogólne wskazówki
W aplikacji warto załączyć mieszankę repozytoriów pokazujących różne umiejętności: przynajmniej jedno portfolio project pokazujące kompleksowy produkt, jedno repozytorium z krótkim demo technologicznym, repo z testami i konfiguracją CI, oraz ewentualnie przykłady prac open source lub prace zespołowe. Każde repozytorium powinno zawierać wyraźne README z opisem projektu, instrukcją uruchomienia lokalnego środowiska, listą użytych technologii oraz krótkim opisem roli autora w projekcie. Dodatkowo warto dodać sekcję "Co można poprawić" lub "Plany rozwoju", która pokazuje myślenie o dalszym rozwoju produktu. Przy linkowaniu do repozytoriów w CV lub portalu rekrutacyjnym warto wskazać konkretny plik lub commit, który najlepiej prezentuje twoje kompetencje, np. konkretny pull request z ważnym fixem.
Przykłady repozytoriów do załączenia w aplikacji — projekt portfolio
Repozytorium portfolio — czego oczekiwać
Repozytorium portfolio to pełny projekt aplikacji, który pokazuje end-to-end umiejętności: projektowanie architektury, backend, frontend, testy, wdrożenie i dokumentację. Najlepsze portfolio to projekt, który jest działający, łatwy do uruchomienia lokalnie albo ma publiczne środowisko demo. W README warto umieścić zrzuty ekranu, opis architektury, instrukcję instalacji krok po kroku, wymagania systemowe i informacje o tym, które moduły stworzyłeś osobiście. Jeśli projekt jest zespołowy, opisz swoją rolę i zakres odpowiedzialności. To repozytorium ma pokazać, że potrafisz doprowadzić produkt od pomysłu do działającej wersji, dbając o jakość kodu i procesy inżynierskie.
Przykładowy stack i struktura projektu portfolio
Dobrym pomysłem jest wybór technologii znanych na rynku, takich jak Node.js lub Python na backendzie, React lub Vue na frontendzie oraz PostgreSQL lub MongoDB jako baza danych. Projekt powinien mieć oddzielne katalogi dla serwera i klienta, skrypty do uruchomienia kontenerów Docker, plik docker-compose do szybkiego startu oraz konfigurację CI do wykonywania testów i lintowania kodu. W repozytorium umieść pliki konfiguracyjne: .github/workflows dla GitHub Actions, instrukcje migracji bazy danych, przykładowe pliki .env.example oraz zbiór testów jednostkowych i integracyjnych. Całość powinna być opisana, a instalacja możliwa po kilku prostych komendach.
Co szczególnie zwraca uwagę w repozytorium portfolio
Rekruterzy zwracają uwagę na jasny README, strukturę projektu, jakość commitów (czy mają sensowne komunikaty), oraz na obecność testów i konfiguracji CI. Ważne jest, aby kod był zgodny z powszechnymi konwencjami i lintami. Jeśli używasz wzorców projektowych, opisz je w dokumentacji. Dodatkowym atutem jest automatyczne wdrożenie demo, np. na platformie typu Vercel, Netlify, Heroku lub poprzez GitHub Pages, co pozwala rekruterowi szybko zobaczyć działający produkt bez konieczności uruchamiania lokalnego środowiska.
Przykłady repozytoriów do załączenia — projekty demonstracyjne i mini-projekty
Krótkie repozytoria demonstracyjne — cel i przykłady
Krótkie projekty demonstracyjne mają pokazać konkretne umiejętności techniczne w skondensowanej formie. Mogą to być przykłady algorytmów, implementacje wzorców projektowych, małe API pokazujące znajomość REST lub GraphQL, albo komponenty UI pokazujące biegłość w React. Tego typu repozytoria nie muszą być rozbudowane, ale powinny być czytelne i zawierać testy. Idealny rozmiar to pojedyncze funkcjonalności, których działanie można szybko zweryfikować.
Przykładowe mini-projekty do dodania
Przykłady takich repozytoriów to: prosty serwis do zarządzania zadaniami z REST API, demo implementacji autoryzacji JWT, mała aplikacja obsługująca upload plików z podglądem, interaktywny komponent kalendarza w React lub implementacja kolejki z priorytetami. Każde repozytorium powinno mieć minimalne środowisko uruchomieniowe, np. Dockerfile lub skrypt startowy, oraz instrukcję testowania. Warto też umieścić krótkie porównanie alternatywnych rozwiązań i wyjaśnienie, dlaczego wybrałeś konkretne narzędzia.
Jak zaprezentować repozytorium demonstracyjne w aplikacji
W CV lub liście motywacyjnym odnieś się do konkretnych commitów lub pull requestów, które najlepiej pokazują twoje rozwiązania. Daj krótki opis wyzwania, twojego podejścia oraz rezultatów. Możesz podlinkować demo lub filmik pokazujący działanie. Pamiętaj, żeby nie przesadzić z liczbą małych repozytoriów — lepiej mieć kilka dobrze przygotowanych niż wiele niekompletnych.
Przykłady repozytoriów do załączenia — repozytoria z testami i CI/CD
Dlaczego testy i CI/CD są istotne w aplikacji rekrutacyjnej
Umiejętność pisania testów i konfiguracji procesu Continuous Integration/Continuous Deployment jest coraz częściej wymagana. Repozytorium z dobrze zaprojektowanymi testami jednostkowymi, integracyjnymi i e2e pokazuje, że programista myśli o jakości i stabilności kodu. Konfiguracja CI wskazuje na zrozumienie automatyzacji i procesów, które wspierają zespołową pracę oraz szybkie i bezpieczne wdrożenia.
Co powinno zawierać repozytorium z CI
Takie repozytorium powinno zawierać: testy uruchamiane w CI, konfigurację lintera i formattera, skrypty do budowania i uruchamiania testów, oraz przykładowe badge informujące o statusie builda w README. W przypadku GitHub Actions warto dodać workflow wykonujący testy przy każdym pushu i pull requeście, a także opcjonalnie budujący artefakty lub wdrażający aplikację na środowisko stagingowe. Dobrą praktyką jest również konfiguracja caching dla zależności, by skrócić czas buildów.
Przykładowy zestaw testów do pokazania w repozytorium
Pokazanie różnych typów testów jest cenne: testy jednostkowe dla logiki biznesowej, testy integracyjne dla integracji z bazą danych i usługami zewnętrznymi, oraz testy end-to-end dla krytycznych ścieżek użytkownika. Warto także dodać przykłady mockowania i użycia narzędzi do testowania równoległego. Umieszczając te elementy w projektach demonstracyjnych, pokazujesz, że potrafisz budować testowalny kod i automatyzować jego weryfikację.
Przykłady repozytoriów do załączenia — wkład w open source i praca zespołowa
Wartość wkładu w open source w aplikacji o pracę
Udział w projektach open source sygnalizuje umiejętność pracy z cudzym kodem, komunikację z zespołem rozproszonym i zdolność do dostosowywania się do standardów projektu. Nawet małe poprawki, takie jak naprawa błędu lub uzupełnienie dokumentacji, mogą dużo powiedzieć o kandydatach. Linki do pull requestów, które zostały przyjęte, dodają wiarygodności profilowi.
Jak znaleźć i udokumentować wkład w open source
Wybierz projekty zgodne z twoimi zainteresowaniami i technologiami, w którym możesz wnieść wartość. Zanim zaczniesz pisać kod, zapoznaj się z zasadami współpracy projektu (CONTRIBUTING.md) i z listą zgłoszonych problemów. Dokumentuj swój wkład: opis pull requesta powinien być jasny, commit message zwięzły, a w repozytorium własnym warto dodać sekcję "Open source contributions" z krótkim opisem roli i linkami do PR. W aplikacji rekrutacyjnej podaj konkretne PRy i opisz swoje zmiany oraz wpływ na projekt.
Przykładowe zadania do realizacji w open source dla początkujących
Dla początkujących idealne są zadania typu "good first issue", uzupełnianie dokumentacji, dodawanie testów lub naprawa drobnych bugów. Dzięki temu szybciej zdobędziesz pierwsze merge'y. W miarę zdobywania doświadczenia możesz spróbować rozwiązać bardziej złożone problemy lub zaproponować nowe funkcjonalności. W portfolio warto opisać proces — od zgłoszenia kwestii po akceptację PR — aby pokazać umiejętności komunikacyjne i współpracę.
Jak przygotować README i dokumentację repozytorium
Elementy skutecznego README
README to pierwszy i najważniejszy dokument w repozytorium. Powinien zawierać krótki opis projektu, demo lub zrzuty ekranu, listę funkcji, instrukcję instalacji i uruchomienia, przykładowe komendy, opis architektury oraz informację o tym, jak uruchomić testy. Dodatkowo warto dodać sekcję "Contributing" z zasadami współpracy oraz "License" z informacją o licencji. README można wzbogacić o diagramy architektury, linki do dokumentacji API i przykład użycia.
Jak pisać dokumentację techniczną przystępną dla rekrutera
Pisząc dokumentację, pamiętaj, że rekruterzy i inżynierowie mogą nie mieć czasu na głębokie przeglądanie kodu. Używaj jasnych nagłówków, krótkich opisów i przykładowych komend, które pozwolą szybko uruchomić aplikację. Wyjaśnij kluczowe decyzje architektoniczne i uzasadnij wybór technologii. Jeśli w projekcie są trudno dostępne elementy (np. środowiska zewnętrzne), podaj sposób ich zastąpienia (mocki) lub instrukcję konfiguracji środowiska lokalnego.
Przykłady dodatków do README, które zwiększają wartość aplikacji
Dodatkowe materiały, które robią dobre wrażenie, to: diagramy przepływu danych, przykładowe wyniki testów, linki do demo, instrukcje wdrożenia, informacje o kosztach utrzymania (jeśli dotyczy) oraz checklisty uruchomieniowe. Sekcja "Co zostało zrobione i co można poprawić" pokazuje refleksję i planowanie dalszego rozwoju. W portfolio warto też umieścić informacje o skalowalności, bezpieczeństwie i ewentualnych kompromisach projektowych.
Jak używać commitów i historii jako argumentu w aplikacji
Znaczenie dobrych commitów
Dobre commity to nie tylko estetyka — to historia myślenia i procesu rozwoju projektu. Rekruterzy i liderzy techniczni mogą przejrzeć historię commitów, aby zobaczyć, jak kandydat rozwiązuje problemy, jak dzieli pracę na mniejsze kroki i czy stosuje sensowne komunikaty. Commit message powinien być krótki, ale informacyjny: co zostało zmienione i dlaczego. Warto stosować strukturę, np. prefiksy typu feat, fix, docs, refactor, chore, co ułatwia czytanie historii.
Jak porządkować historię dla czytelności
Jeśli w projekcie były okresy intensywnej pracy z wieloma commitami roboczymi, warto przed finalnym zaprezentowaniem repozytorium uporządkować historię przy pomocy rebase i squash, tworząc czytelniejszą narrację. Należy jednak zachować autentyczność i nie usuwać istotnych informacji, szczególnie w projektach open source, gdzie historia współpracy jest ważna. W commitach zespołowych warto zadbać o sensowne opisy PR i linkować do zadań w systemie issue tracker.
Wskazówki, które commity warto wyróżnić w aplikacji
W aplikacji warto wskazać konkretne commity lub pull requesty, które pokazują twoją rolę: np. duży refactor, implementacja kluczowej funkcjonalności, optymalizacja wydajności, dodanie testów lub naprawa krytycznego błędu. W CV lub liście motywacyjnym możesz podać bezpośredni link do commita lub PR i krótko opisać kontekst i rezultat.
Jak przygotować pull requesty i pokazać umiejętności code review
Co powinien zawierać dobry pull request
Dobry pull request ma zwięzły tytuł i opis, który jasno wyjaśnia zmianę, dlaczego została wprowadzona i jakie są jej skutki. Dobrą praktyką jest dodanie instrukcji testowania zmiany, listy zadań (checkbox), odnośników do issue, diagramów oraz informacji o wpływie na istniejącą funkcjonalność. Jeśli PR jest duży, warto go podzielić na mniejsze, bardziej przyswajalne części.
Jak demonstrować umiejętności code review
Wkład w review innych PR-ów świadczy o umiejętności czytania czyjegoś kodu i konstruktywnego feedbacku. Komentarze w review powinny być merytoryczne: wskazywać potencjalne błędy, sugerować alternatywne implementacje, proponować uproszczenia lub pytania o założenia. W aplikacji możesz podkreślić swoje role reviewerskie, linkując do PR-ów, gdzie twoje uwagi zostały zaimplementowane.
Przykłady dobrych praktyk przy PR
Dobre praktyki obejmują tworzenie małych PR-ów, dzielenie zmian na logiczne kroki, pisanie testów razem ze zmianami oraz dbanie o spójność stylu. Zwracaj uwagę na bezpieczeństwo i edge-case'y; jeśli zmiana pociąga za sobą migracje danych, zadbaj o skrypty migracyjne i rollback. W trakcie rozmowy rekrutacyjnej możesz opisać przykładowy PR i uzasadnić wybrane rozwiązania.
Jak wykorzystać GitHub Actions i automatyzacje w repozytoriach aplikacyjnych
Dlaczego automatyzacja jest atutem w aplikacji o pracę
GitHub Actions pozwala zautomatyzować buildy, testy, lintowanie, publikowanie paczek oraz wdrożenia. Pokazanie konfiguracji Actions w repozytorium świadczy o zrozumieniu procesów DevOps i oszczędza czas zespołu. Dla rekruterów to sygnał, że kandydat potrafi tworzyć workflows wspierające jakość i spójność dostaw oprogramowania.
Przykłady workflowów, które warto pokazać
Przydatne workflowy do załączenia to: uruchamianie testów przy każdym push, budowanie i publikowanie obrazu Docker do rejestru, automatyczne uruchamianie lintów i formatowanie kodu, a także deployment na staging lub produkcję z użyciem warunków i review. Warto dodać badge statusu builda w README oraz dokumentację, co dany workflow robi i jak go uruchomić lokalnie.
Bezpieczeństwo i tajne dane w konfiguracji Actions
W konfiguracji Actions nie umieszczaj jawnie kluczy ani tajnych danych. Używaj GitHub Secrets do przechowywania wrażliwych wartości i dokumentuj, jakie secrets są potrzebne do lokalnego testowania. Wyjaśnij w README, w jaki sposób skonfigurować środowisko developerskie bez ujawniania danych produkcyjnych, oraz jak mockować zewnętrzne usługi podczas testów.
Jak pokazać umiejętności architektoniczne i skalowalność w repozytoriach
Dokumentowanie decyzji architektonicznych
Dobre repozytorium to nie tylko kod, ale i dokumentacja architektury: diagramy, opis komponentów, przepływ danych, punkty integracji i kompromisy techniczne. Sekcja ADR (Architecture Decision Records) może być użytecznym elementem, gdzie opisujesz decyzje projektowe, alternatywy i powody wyboru. To pokazuje, że potrafisz planować i oceniać wpływ decyzji na system w dłuższej perspektywie.
Pokazywanie skalowalności i wydajności
W repozytorium warto umieścić testy wydajnościowe lub przykłady skalowania, np. konfiguracje kubernetesowe, script do obciążeniowego testu, konfiguracje cachowania, optymalizacje zapytań do bazy oraz strategie skalowania horyzontalnego. Jeśli projekt ma ograniczenia kosztowe, opisz trade-offy i sposoby monitorowania oraz alertowania.
Przykłady rozwiązań architektonicznych do zaprezentowania
Przykładowe elementy do pokazania to: oddzielenie warstwy API od workerów asynchronicznych, implementacja event-driven architektury, użycie message brokerów, wzorce CQRS, migracje bazy danych z zachowaniem dostępności oraz strategie rolloutów (canary, blue-green). W README opisz, jak te elementy wpływają na dostępność, spójność i łatwość utrzymania.
Jak w aplikacji podkreślić kompetencje w bezpieczeństwie i zgodności
Bezpieczeństwo jako część prezentacji repozytorium
W repozytorium warto wskazać praktyki bezpieczeństwa: skanowanie zależności, konfiguracje bezpieczeństwa serwerów aplikacyjnych, obsługa walidacji danych i sanitizacji wejść, szyfrowanie wrażliwych danych oraz mechanizmy uwierzytelniania i autoryzacji. Pokazanie, że dbasz o bezpieczeństwo od etapu projektu, to silny atut.
Narzędzia i praktyki bezpieczeństwa do pokazania
Warto dodać integracje typu Dependabot, skanery SAST, testy penetracyjne (jeśli możliwe do udostępnienia) oraz instrukcje dotyczące polityk dostępu i zarządzania kluczami. W dokumentacji opisz politykę rotacji kluczy, sposób przechowywania secrets oraz mechanizmy audytu. Jeśli projekt dotyczy danych osobowych, opisz, jak zapewniona jest zgodność z obowiązującymi regulacjami i jakie zasady anonimowania lub pseudonimizacji zastosowano.
Jak w aplikacji opisać incydenty i lekcje wyniesione z problemów
Jeśli w projektach wystąpiły incydenty lub trudne decyzje, warto opisać je w sekcji Lessons Learned. Wyjaśnij, co poszło nie tak, jakie działania naprawcze zastosowano oraz jakie procesy zostały zmienione, aby uniknąć podobnych problemów. Taka transparentność pokazuje odpowiedzialność i dojrzałość zawodową.
Przygotowanie CV i listu motywacyjnego z odwołaniem do GitHub
Jak linkować repozytoria w CV
W CV umieść bezpośrednie linki do najważniejszych repozytoriów i do profilu GitHub. Krótkie opisy obok linków powinny wskazywać konkretną rolę, technologie oraz najważniejsze osiągnięcie w projekcie. Jeśli masz demo, umieść link do działającej wersji. W sekcji doświadczenia opisz projekty z GitHub w kontekście rezultatów: poprawa wydajności, zmniejszenie kosztów, wzrost wykorzystania funkcjonalności.
Co napisać w liście motywacyjnym o projektach z GitHub
W liście motywacyjnym wybierz 1–2 projekty najbardziej związane z ofertą pracy i opisz w kilku zdaniach problem, twoje rozwiązanie oraz efekt. Zamiast ogólników podaj konkretne liczby i rezultaty, np. "skracałem czas odpowiedzi API o 40% dzięki optymalizacji zapytań" lub "zaprojektowałem pipeline CI, który skrócił czas release'ów o 60%". Do każdego projektu dołącz link do repozytorium i wskazówki, które pliki warto obejrzeć.
Jak wybrać, które repozytoria wymienić
Wybieraj repozytoria zgodne z wymaganiami oferty pracy. Jeśli firma szuka inżyniera backend, podkreśl projekty z API, bazami danych i testami integracyjnymi. Dla frontendowych ról pokaż komponenty, UX i dostępność. Jeśli oferta wymaga doświadczenia w chmurze, zaznacz repozytoria z IaC, konfiguracjami deploymentu lub integracjami chmurowymi.
Najczęstsze błędy w repozytoriach i jak ich uniknąć
Kiepskie README, brak instrukcji uruchomienia i brak testów
Brak README lub słabe instrukcje uruchomienia potrafią zniweczyć nawet dobry kod. Upewnij się, że rekruter może uruchomić projekt bez konieczności kontaktowania się z tobą. Testy są często oczekiwane; brak testów może sygnalizować brak praktyk jakościowych.
Nieczytelne commit messages i bałagan w historii
Commit messages typu "fix" lub "update" nic nie mówią. Zadbaj o sensowne opisy i uporządkowaną historię, szczególnie przed udostępnieniem projektu w aplikacji rekrutacyjnej.
Prywatne dane i błędy bezpieczeństwa w repozytorium
Nigdy nie umieszczaj kluczy API, hasła, certyfikatów czy innych wrażliwych informacji w repozytorium. Przejrzyj historię git, by upewnić się, że żadne tajne dane nie zostały tam zapisane. Używaj .gitignore i narzędzi do skanowania repozytoriów pod kątem sekretów.
Praktyczny plan działania krok po kroku przed wysłaniem aplikacji
Krok 1: audyt profilu i repozytoriów
Przejrzyj profil i wszystkie repozytoria, usuń lub ukryj mało reprezentatywne projekty, uporządkuj nazwy i opisy, przypnij najważniejsze repozytoria do profilu. Sprawdź historię commitów i popraw opisy tam, gdzie to ma sens.
Krok 2: uzupełnienie README i dokumentacji
Upewnij się, że każde repozytorium, które chcesz pokazać, ma kompletny README, instrukcję uruchamiania i sekcję opisującą rolę autora. Dodaj zrzuty ekranu i linki do demo.
Krok 3: dodanie testów i konfiguracji CI
Jeśli projekt nie ma testów, dodaj przynajmniej kilka krytycznych przypadków testowych. Skonfiguruj GitHub Actions do automatycznego uruchamiania testów i linterów przy pushu. Dodaj badge statusu builda w README.
Krok 4: przygotowanie listy linków i commitów do CV
Wybierz repozytoria do umieszczenia w CV i zapisz konkretne linki do plików, commitów lub PR-ów, które najlepiej pokazują twoje umiejętności. Przygotuj krótkie opisy dla każdego linku.
Krok 5: finalny przegląd i publikacja
Przed wysłaniem aplikacji zrób finalny przegląd: przetestuj lokalne uruchomienie według README, sprawdź, czy żadne poufne dane nie występują, i upewnij się, że wszystkie linki w CV działają. Gdy wszystko jest gotowe, dołącz linki w CV i liście motywacyjnym.
Przykłady pytań technicznych
Pytania o architekturę i decyzje technologiczne
Podczas rozmowy możesz zostać zapytany o powody wyboru konkretnego stacku lub rozwiązania architektonicznego. Przygotuj narrację bazującą na swoich repozytoriach: wyjaśnij alternatywy, kompromisy i wpływ na wydajność, koszt i utrzymanie.
Pytania o testy i proces CI/CD
Rekruterzy mogą poprosić o szczegóły dotyczące testów, przypadków testowych, pokrycia kodu oraz konfiguracji pipeline. Miej przygotowane przykłady z repozytoriów pokazujące jak uruchamiasz testy i jakie problemy wykryły oraz jak pipeline zabezpiecza wypuszczenie kodu.
Pytania o wkład w open source i pracę zespołową
Bądź gotów omówić swoje PR-y: jak identyfikowałeś problemy, jak przygotowywałeś poprawki, jakie trudności napotkałeś i jakie lekcje wyniosłeś. Linki do PR-ów i dyskusji są tu bardzo pomocne.
Podsumowanie
GitHub to nie tylko miejsce przechowywania kodu — to twoje portfolio, CV techniczne i dokumentacja umiejętności. Przygotuj kilka dobrze opisanych repozytoriów: kompletne portfolio project, kilka krótkich demo, repo z testami i konfiguracją CI oraz dowody pracy w open source. Zadbaj o czytelne README, sensowne commit messages, automatyzację buildów i bezpieczeństwo. W CV i liście motywacyjnym odwołuj się do konkretnych linków, commitów i pull requestów, które najlepiej pokazują twoje kompetencje. Przejrzyj profil, uporządkuj historię i przetestuj instrukcje uruchomienia, aby rekruter mógł szybko ocenić twoje umiejętności. Dobre przygotowanie repozytoriów na GitHub może znacząco zwiększyć twoje szanse na zaproszenie na rozmowę techniczną i otrzymanie oferty pracy jako programista.