Jak mądrze wybierać hackathony, by wzmacniały CV i portfolio projek­towe

Gdzie znika czas i efekty – typowy problem z hackathonami

Typowy scenariusz na polskiej uczelni technicznej: ktoś z roku rzuca hasło „idziemy na hackathon, będzie pizza i koszulki”. Jedziesz na trzy takie weekendy pod rząd, wracasz zmęczony, z dwoma dyplomami uczestnika, paroma selfie… i kompletnym brakiem czegokolwiek, co da się wkleić do CV czy portfolio.

Po kilku miesiącach aktualizujesz LinkedIn i pojawia się pokusa, żeby wpisać: „uczestnik 5+ hackathonów”. Rekruter patrzy na to jednym okiem i przechodzi dalej, bo nie widzi:

• żadnych linków do repozytoriów,
• brak konkretnych projektów i opisanych efektów,
• zero informacji o twojej roli i stacku technologicznym.

Na rynku juniorskich ofert IT samo hasło „hackathony” bez mięsa nic już nie znaczy. Firmy szukają dowodu, że potrafisz:

• dowieźć działające MVP (Minimum Viable Product),
• pracować w zespole w konkretnym stosie technologicznym,
• opisać problem biznesowy i rozwiązanie.

Konflikt jest prosty: ty traktujesz hackathon jako narzędzie do budowy CV i portfolio projektowego, a większość eventów jest projektowana bardziej jako impreza integracyjno‑marketingowa. Jeżeli nie zaczniesz selekcjonować wydarzeń i ustawiać ich pod swój cel, skończysz z ładnymi wspomnieniami i pustym GitHubem.

Różnica między hackathonem jako przygodą a hackathonem jako narzędziem kariery jest brutalnie praktyczna: po tym drugim powinno zostać coś, co możesz wkleić do CV, do sekcji „projekty” i pokazać na rozmowie technicznej. Jeżeli po weekendzie nie da się wygenerować nawet sensownego wpisu na LinkedIn z linkiem do dema – to był to raczej event, nie inwestycja w karierę.

Skąd się biorą słabe efekty – przyczyny zmarnowanych hackathonów

Zapis „w ciemno” i pogoń za nagrodami

Najczęstsza przyczyna rozczarowań: wybór hackathonu wyłącznie na podstawie plakatu. Widoczna jest duża nagroda, głośne hasło typu „największy hackathon w Polsce” albo egzotyczny temat. Brakuje natomiast odpowiedzi na kluczowe pytanie: czy będę miał po tym projekcie coś konkretnego do pokazania?

Jeżeli zapisujesz się „w ciemno”, bez przeczytania regulaminu, listy partnerów, tematyki wyzwań i agendy, to w praktyce oddajesz decyzję o tym, jaki projekt trafi do twojego portfolio, komuś zupełnie obcemu. Często kończy się to zadaniem z losowej branży, technologiami, których nie znasz i kodem, którego nie możesz potem pokazać publicznie.

Efekt: hackathon zjada ci jeden lub dwa weekendy, ale z perspektywy CV jest to co najwyżej jedna linijka w stylu „uczestnik XYZ Hackathon 2024” – bez repo, bez dema, bez sensu.

Brak myślenia o własnej ścieżce i profilu kandydata

Drugi klasyk: student, który celuje w backend w Javie albo .NET, ląduje na kilku eventach IoT, VR czy AR, bo „fajnie brzmi” i „tam podobno łatwiej coś wygrać”. Dla nauki i zabawy – super. Dla spójnego przekazu kariery – słabo.

Rekruter patrząc na twoje CV próbuje zrozumieć: kim chcesz być za 1–2 lata. Jeżeli w sekcji projektów dominują dziwne, jednorazowe tematy w losowych technologiach, trudno mu uwierzyć, że poważnie myślisz o konkretnej specjalizacji. Dwa hackathony z obszaru IoT u kandydata „na backend developera” trzeba będzie każdorazowo tłumaczyć na rozmowie: dlaczego, po co, co z tego wyniosłeś.

Brak planu sprawia też, że po hackathonie nie masz jasnej historii do opowiedzenia. Gdy słyszysz pytanie „który projekt z hackathonu najlepiej pokazuje twoje umiejętności backendowe?”, odpowiedź brzmi: „w sumie żaden, bo robiłem dashboard pod VR na Unity”.

Eventy stricte marketingowe i niejasne zasady

Osobna kategoria to hackathony „pod PR” jednej marki – często dużej korporacji. Mogą mieć świetne nagrody, ale z perspektywy portfolio bywają bezużyteczne. Typowe objawy:

• brak jasnej informacji, kto jest właścicielem kodu,
• zakaz upubliczniania repo lub dema po wydarzeniu,
• zadania tak ściśle związane z wewnętrznymi systemami firmy, że nie da się ich pokazać na zewnątrz.

Scenariusz z życia: byłeś na „wielkim korporacyjnym hackathonie”, projekt nawet zadziałał, ale kod musiał zostać na serwerach organizatora, nie wolno ci go publikować, a demo działało tylko na ich infrastrukturze. Rezultat: nie masz ani linku, ani screena, ani nawet realnego opisu problemu, bo obowiązuje NDA (Non-Disclosure Agreement). Na rozmowie rekrutacyjnej możesz co najwyżej napomknąć, że coś takiego się odbyło.

Słaby skład zespołu i brak struktury pracy

Wiele hackathonów opiera się na spontanicznie dobieranych zespołach. Jeżeli nie zadbasz o to, z kim i jak pracujesz, łatwo lądujesz w grupie, gdzie:

• nikt nie chce przejąć roli osoby odpowiedzialnej za produkt (product owner / lead),
• brakuje stricte technicznych osób do dowiezienia MVP,
• nikt nie pilnuje repo, commitów, dokumentacji i dema.

W takiej konfiguracji projekt często rozpada się w połowie nocy na serię niepołączonych proof-of-conceptów (POC), których nie da się pokazać jako spójnej aplikacji. Nawet jeśli coś tam zakodziłeś, po weekendzie nie ma jednego sensownego repo ani działającej wersji demo, którą można wkleić do portfolio.

Jeżeli dodatkowo rola przypadnie ci „prezentacyjna” (slajdy, pitch), bez kodowania, to z perspektywy CV technicznego nie masz co pokazać, poza suchą wzmianką, że mówiłeś do mikrofonu.

Jak rozpoznać wartościowy hackathon zanim się zapiszesz

Organizatorzy, partnerzy, agenda – szybki audyt wydarzenia

Przed kliknięciem „zapisz się” warto zrobić krótki audyt wydarzenia. Nie zajmie to więcej niż 10–15 minut, a może uratować ci weekend.

1. Organizator – kto stoi za hackathonem?

• Uczelniane/akademickie – często dobrze postrzegane w Polsce, zwłaszcza jeśli to znana politechnika lub wydział informatyczny. Projekty bywają później linkowane na stronach kół naukowych.
• Firmowe/komercyjne – organizowane przez software house’y, banki, telco, firmy produktowe. Dobre, jeśli partnerem jest dział IT, a nie tylko marketing.
• Branżowe/społecznościowe – np. data science meetupy, społeczności Python/JS, fundacje govtech. Często bardzo merytoryczne, z realnymi mentorami z branży.

Im bardziej organizator jest rozpoznawalny w środowisku IT, tym większa szansa, że rekruter skojarzy nazwę hackathonu.

2. Cykliczność i reputacja

Sprawdź, czy to kolejna edycja czy jednorazowy strzał. Jeżeli:

• są relacje z poprzednich edycji (foto, wideo, artykuły),
• istnieją listy zwycięzców z nazwami projektów,
• w sieci można znaleźć repozytoria lub prezentacje poprzednich laureatów,

to sygnał, że wydarzenie jest poważne i uczestnicy faktycznie dostarczają projekty, o których można potem mówić. Dodatkowy plus, jeżeli znajdziesz wzmianki, że ktoś dostał po takim hackathonie propozycję stażu lub mentoringu.

3. Partnerzy i mentorzy

Spójrz, jakie logotypy widnieją na stronie i kogo organizator deklaruje jako mentorów lub jurorów:

• firmy technologiczne (software house’y, product company, fintechy),
• działy IT dużych korporacji (nie tylko marketing),
• osoby z realnymi technicznymi rolami: senior developer, architect, data scientist, devops.

Jeżeli lista mentorów to wyłącznie „brand manager”, „PR specialist” i „event coordinator”, to trudno oczekiwać wartościowego feedbacku technicznego czy networkingu rekrutacyjnego. Obecność rekruterów IT też jest plusem – często mają oni potem wpływ na shortlisty do programów stażowych.

4. Agenda i format

Dobry hackathon z punktu widzenia CV zwykle ma:

• demo day – sesja prezentacji przed jury i innymi zespołami,
• czas na feedback – Q&A po demo, możliwość dopytania mentorów,
• networking – oficjalne lub nieformalne spotkania z partnerami,
• jasne kamienie milowe – call checkpoint, oddanie prototypu, finał.

Jeżeli agenda wygląda jak długi maraton bez struktury („start w piątek wieczór, oddanie w niedzielę, międzyczasie pizza i integracja”), jest większe ryzyko chaosu i „projektu do kosza”.

Techniczne i formalne czerwone flagi

Sama lista sponsorów nie wystarczy. Trzeba jeszcze sprawdzić techniczne i formalne szczegóły, które potrafią zabić wartość projektu dla portfolio.

1. Prawa do kodu i możliwość publikacji

Zajrzyj do regulaminu i szukaj fragmentów dotyczących:

• własności intelektualnej (kto jest właścicielem rozwiązań),
• możliwości publikowania kodu i dema po wydarzeniu,
• ewentualnego NDA (klauzule poufności).

Czerwona flaga: zapis w stylu „całość kodu i pomysłów staje się własnością organizatora i nie może być publikowana bez jego zgody”. To najprostsza droga, aby wykonać wartościową robotę, której nie pokażesz na GitHubie. Jeżeli taki zapis istnieje, zastanów się dwa razy, czy to dobry wybór na hackathon „pod CV”.

2. Brak wymogu repo/projektu końcowego

Jeśli w informacjach dla uczestników nie ma ani słowa o:

• konieczności oddania działającego MVP lub przynajmniej prototypu,
• specyfikacji technicznej (link do repo, branch, instrukcja uruchomienia),
• formacie prezentacji projektu,

to istnieje ryzyko, że organizator nastawia się bardziej na frekwencję i PR niż na realne rozwiązania. W takiej sytuacji nikt nie będzie cię „pchał” w stronę posprzątania kodu i zrobienia porządnego dema – a bez tego projekt będzie trudniejszy do pokazania w portfolio.

3. Temat całkowicie oderwany od realnych case’ów

Hackathon z hasłem „dowolna aplikacja w 24h” wygląda kusząco, ale ma jedną wadę: trudno potem w CV wytłumaczyć, dlaczego akurat taki, a nie inny projekt zrobiłeś. Lepsze są eventy z konkretnymi wyzwaniami:

• predykcja obciążenia sieci,
• aplikacja do obsługi zgłoszeń serwisowych,
• system rekomendacji ofert,
• dashboard do analityki danych transakcyjnych.

Łatwiej wtedy pokazać, że mierzyłeś się z problemem, z jakim faktycznie spotykają się firmy IT. Na rozmowie technicznej taka historia brzmi znacznie poważniej niż „zrobiliśmy apkę do losowego śmiesznego mema, bo był czas 24h”.

4. Czego unikać w ogłoszeniach

Kilka mocnych czerwonych flag, po których warto się zatrzymać:

• brak listy mentorów/jury z imienia i nazwiska, tylko „eksperci firmy X”,
• brak jakichkolwiek informacji o poprzednich edycjach, mimo że to rzekomo kolejny rok,
• jedyne podkreślone elementy to nagrody i atrakcje typu koncert, impreza integracyjna,
• niejasny lub brakujący regulamin, dostępny dopiero „po rejestracji”,
• brak wzmianki o tym, w jakim języku/stacku będzie się pracować i jak wygląda oddanie projektu.

Mini-checklista: czy ten hackathon ma sens dla mojego CV?

Krótki test „tak/nie”. Jeśli większość odpowiedzi to „tak”, wydarzenie ma potencjał wzmocnić twoje CV i portfolio projektowe. Jeśli dominują „nie” – traktuj je raczej jako przygodę, a nie inwestycję w karierę.

• Czy kojarzę co najmniej jedną firmę lub organizację wśród partnerów wydarzenia? (TAK/NIE)
• Czy regulamin pozwala mi po hackathonie legalnie pokazać kod lub publiczne demo projektu? (TAK/NIE)
• Czy tematyka/branża hackathonu pasuje do ścieżki, którą chcę mieć w CV (frontend/backend/data/cyber/embedded)? (TAK/NIE)
• Czy na stronie są pokazane projekty lub przynajmniej nazwy zwycięzców z poprzednich edycji? (TAK/NIE)
• Czy w agendzie jest przewidziana prezentacja projektu przed jury (demo day) i możliwość zadania pytań mentorom? (TAK/NIE)
• Czy jestem w stanie w jednym zdaniu nazwać umiejętność lub obszar, który chcę tam wzmocnić (np. „API w Node.js”, „modele klasyfikacji w Pythonie”, „UI w React”)? (TAK/NIE)
• Czy w razie rezygnacji (np. kolizja z sesją, innym projektem) nie mam poczucia, że tracę coś kluczowego – czyli to dodatek do mojej ścieżki, a nie desperacka próba ratowania CV? (TAK/NIE)

Jeżeli odpowiadasz „tak” głównie przy pytaniach o pizzę, nagrody i free gadżety, a „nie” przy kwestiach repo, mentorów i dopasowania do ścieżki – to sygnał, żeby jeszcze raz przefiltrować ogłoszenia. Hackathon, który realnie dokłada cegiełkę do twojego profilu zawodowego, zwykle da się rozpoznać po konkretnych, technicznych obietnicach: wymaganym MVP, prezentacji przed jury, jasno opisanych kryteriach oceny.

Dobrym nawykiem jest traktowanie rejestracji jak mini-decyzji projektowej. Zanim klikniesz „zapisz się”, odpowiedz sobie na trzy pytania: czego konkretnie się tam nauczę, jaki artefakt wyciągnę do portfolio (repo, demo, case study) i do jakiej linii w CV to mi pasuje. Jeśli potrafisz to spiąć w jedną spójną narrację, istnieje duża szansa, że ten weekend zaprocentuje na rozmowie rekrutacyjnej.

Hackathony same w sobie nie budują kariery – robią to projekty, ludzie, których poznasz, i sposób, w jaki później opowiesz o tym w CV i na GitHubie. Wybierając wydarzenia świadomie, zamieniasz losowe „kodowanie po nocach” w przemyślane sprinty, które krok po kroku budują twoje portfolio i reputację w branży.

Dopasowanie do ścieżki kariery: filtrowanie tematów i ról

Ten sam hackathon może być złotem dla przyszłego data scientista, a kompletną stratą czasu dla osoby celującej w embedded. Kluczowe jest dopasowanie tematu i twojej roli do kierunku, który chcesz mieć w CV.

Mapowanie hackathonów do ścieżek (frontend, backend, data, cyber, embedded)

Zamiast patrzeć na hasło marketingowe, rozbij wydarzenie na technologie i typ problemu. Szybka matryca myślenia:

• Frontend / mobile – szukaj zadań z:
  • aplikacjami web/mobile dla użytkownika końcowego,
  • UI/UX na pierwszym planie (dashboardy, panele, aplikacje klienckie),
  • konkretnym stackiem w agendzie: React, Vue, Angular, Flutter, React Native.

  Dobry znak: osobna kategoria nagród za UX/UI, design systemy, dostępność (accessibility).

• Backend / cloud / devops – najlepsze będą:
  • wyzwania z integracją API, przetwarzaniem danych w tle,
  • zadania oparte o microservices, message queue, streaming,
  • wymóg deployu (np. na Azure, AWS, GCP, Heroku).

  Dobry znak: punktowane są elementy typu logowanie, monitoring, bezpieczeństwo, testy.

• Data science / ML / AI – filtruj po:
  • dostępie do realnego zbioru danych (np. transakcje, sensory, logi),
  • jasnych metrykach oceny modelu (accuracy, F1, RMSE – wprost w opisie),
  • stacku: Python, R, Jupyter, scikit-learn, PyTorch, TensorFlow.

  Czerwona flaga: „AI/ML hackathon” bez żadnej wzmianki o danych lub metrykach.

• Cybersecurity – szukaj raczej:
  • CTF (Capture The Flag) i security challenge’y niż klasycznych hackathonów produktowych,
  • zadań z testowaniem bezpieczeństwa, analizą logów, exploitami.

  Dobry znak: partnerem jest firma lub organizacja stricte security (SOC, CERT, vendor bezpieczeństwa).

• Embedded / IoT – dla tej ścieżki krytyczne jest:
  • fizyczny dostęp do sprzętu (dev boardy, sensory, roboty),
  • info o językach/systemach: C/C++, Rust, RTOS, Arduino, ESP32, Raspberry Pi,
  • zespół mentorów z hardware/firmware, a nie tylko web dev.

  Jeśli event „IoT” kończy się na „zróbcie appkę do sterowania światłem w telefonie”, portfolio embedded dużo na tym nie zyska.

Tip: w opisie hackathonu wyszukaj nazwy technologii, które chcesz mieć w „Skills” na LinkedIn. Im większy overlap, tym lepiej inwestujesz czas.

Świadomy wybór roli w zespole

Na wielu eventach trwa zbieranie składów na ostatnią chwilę. Jeżeli nie zdefiniujesz swojej roli, łatwo skończyć jako „człowiek od prezentacji” lub ogarniania slajdów. To zabija wartość techniczną w CV.

Przed startem określ twardo, co chcesz robić na tym hackathonie:

• Frontend – tworzysz UI, dopinasz komponenty, odpowiadasz za responsywność i UX.
• Backend – stawiasz API, modele danych, logikę biznesową, integracje.
• Data – czyścisz dane, tworzysz feature’y, trenujesz i ewaluujesz modele.
• DevOps – konfigurujesz CI/CD, deployment, monitoring, logowanie.
• Product/PM – pilnujesz zakresu, priorytetów, zadań, ale pilnuj też choć jednego twardego artefaktu (np. user stories, backlog, diagramy).

Uwaga: jeżeli celem jest wzmocnienie technicznego CV, rola 100% „PM/Prezentacja” na pierwszych hackathonach zwykle nie pomaga. Lepiej być mid-level frontem w zespole niż „product ownerem”, który nie ma czego wrzucić na GitHuba.

Scenariusz z życia: hackathon „AI”, który nie był AI

Typowy błąd: zapis na hackathon „AI for Good”, gdzie na miejscu okazuje się, że:

• nie ma żadnych zbiorów danych,
• organizator oczekuje makiet i pitch decków,
• słowo „AI” jest tylko w nazwie, żeby brzmiało modnie.

Jak tego uniknąć? Przed decyzją:

• sprawdź, czy w opisach wyzwań są konkretne dane lub link do „data package”,
• poszukaj w regulaminie lub FAQ słów: „dataset”, „metrics”, „model”, „notebook”,
• napisz krótkie pytanie do organizatora na maila/Discordzie: „Czy dostaniemy dane do modelowania, czy skupiamy się na koncepcji produktu?”.

Jeśli odpowiedź jest mętna, lepiej poszukać innego eventu i zainwestować weekend w projekt solo.

Projekt jako produkt końcowy: jak wyjść z hackathonu z czymś do pokazania

Nawet dobry hackathon nie obroni się sam, jeśli wyjdziesz bez żadnego artefaktu. Trzeba od początku myśleć o projekcie jak o małym produkcie, który będzie później analizowany przez rekrutera lub seniora technicznego.

Minimalne „MVP pod CV” – co musi powstać

Nawet jeśli nie zdobędziesz nagrody, projekt może robić robotę w portfolio. Warunek: minimum zestaw materiałów.

• Repozytorium kodu (GitHub/GitLab/Bitbucket):
  • czytelny README.md (opis, stack, instrukcja uruchomienia, screeny),
  • sensible struktura katalogów (np. frontend/, backend/, notebooks/),
  • kilka sensownych commitów z opisami, a nie „fix”, „update”, „final”.
• Demo:
  • hostowana wersja (np. Vercel, Netlify, Render, Railway, Hugging Face Spaces), lub
  • krótki screencast (nagranie ekranu, 2–5 minut) wrzucony jako „unlisted” na YouTube.
• Krótki opis problemu i rozwiązania:
  • max 3–4 akapity, najlepiej jako sekcja w README lub osobne CASE_STUDY.md,
  • co było celem, co zaimplementowaliście, czego zabrakło i co byś dodał w następnej iteracji.

Tip: zaplanuj w harmonogramie zespołu ostatnie 1–2 godziny wyłącznie na porządki w repo i README. Inaczej skończycie z kodem „tylko my wiemy, jak to odpalić”.

Plan sprintu hackathonowego: minimalna struktura

Nawet w 24–48 godzin da się narzucić prostą strukturę, która chroni przed totalnym chaosem. Przykładowy plan:

1. Pierwsze 2–3 godziny:
   • ustalenie problemu i metryki sukcesu (np. „działające logowanie i 1 kluczowy flow biznesowy”),
   • podział ról i technologii,
   • założenie repo, wstępna struktura, konfiguracja CI (jeśli ma sens).
2. Środek hackathonu:
   • implementacja najważniejszego scenariusza end-to-end,
   • regularne, krótkie synchro (stand-up co 2–3 godziny),
   • na bieżąco commitujesz kod, nie „na koniec dnia”.
3. Ostatnie 3–4 godziny:
   • stabilizacja i naprawa blokujących bugów,
   • uzupełnienie README, screenów, ewentualnie dockerfile’a,
   • przećwiczenie dema (kto klika, kto mówi, w jakiej kolejności).

Uwaga: jeśli w połowie hackathonu wiesz, że nie dowieziecie pełnego rozwiązania, przetnij zakres. Lepiej mieć jeden dopięty flow niż pięć zaczętych na 20% – dla rekrutera to ogromna różnica.

Jak opakować średnio udany projekt, żeby nadal działał na twoją korzyść

Często scenariusz wygląda tak: projekt działa „trochę”, jest masa niedoróbek, nagrody brak. To nadal można obrócić na plus, jeśli pokażesz:

• co działa – w README wypisz konkretnie: „Logowanie, lista zgłoszeń, filtr po statusie”.
• co jest świadomie odcięte – sekcja „Next steps” lub „Limitations”: „Brak autoryzacji ról”, „Brak testów jednostkowych”, „Brak paginacji”.
• czego się nauczyłeś – jeden akapit typu: „Pierwszy raz skonfigurowałem deployment na Vercel/Azure Functions/Docker Compose”.

Na rozmowie technicznej lepiej wypada ktoś, kto umie uczciwie opowiedzieć o kompromisach („zrezygnowaliśmy z X, żeby dowieźć Y”), niż osoba, która pokazuje „idealny” projekt bez żadnych trade-offów.

Micro-plan: jak „wycisnąć” projekt po hackathonie

Wielu uczestników kończy event, zamyka laptopa i nigdy więcej nie dotyka repo. Kilka prostych kroków po weekendzie potrafi zamienić przeciętny projekt w sensowny asset.

• W ciągu 48 godzin:
  • posprzątaj najgorsze „śmieci” w kodzie (TODO, zakomentowane bloki, tymczasowe logi),
  • uzupełnij README o sekcję „My role” – co dokładnie zrobiłeś ty, a nie cały zespół,
  • dodaj prosty backlog „Future work”, pokazujący, że myślisz produktowo.
• W ciągu tygodnia:
  • jeśli projekt ma potencjał – wyizoluj fragment, który możesz rozwinąć solo (np. jeden mikroserwis, model ML, komponent UI) i dopracuj go,
  • wrzuć zrzuty ekranu/demo do swojego portfolio (np. własna strona, Notion, GitHub Pages),
  • dodaj wpis na LinkedIn z krótkim opisem: problem, rozwiązanie, stack, twoja rola, link do repo/demo.

Tip: w repozytorium możesz dodać label „hackathon” w opisie i krótko napisać, że to projekt z wydarzenia X, rozwijany później we własnym zakresie. Dla rekrutera to sygnał, że nie traktujesz hackathonu jako jednorazowej akcji, tylko punkt startu.

Jak opisać projekt z hackathonu w CV i na LinkedIn

Najczęstszy błąd to sucha linijka „Udział w hackathonie X”. Mało kto rekrutujący ma czas, żeby się domyślać, co robiłeś. Zamiast tego:

• Nazwa projektu – nie tylko „Hackathon X”, ale „System rekomendacji ofert – Hackathon X (2025)”.
• 1–2 zdania opisu:
  • „Prototyp systemu rekomendacji ofert pracy oparty na podobieństwie CV–job description (Python, FastAPI, scikit-learn, PostgreSQL).”
• 2–3 bullet pointy z twoją rolą:
  • „Zaprojketowałem model danych i zaimplementowałem REST API w FastAPI (3 endpointy: rejestracja, logowanie, rekomendacje).”
  • „Przygotowałem pipeline treningowy dla modelu klasyfikacji tekstu (preprocessing, TF-IDF, Logistic Regression).”
  • „Skonfigurowałem deployment na Railway + automatyczne buildy z GitHuba.”
• Link do repo/demo – najlepiej skrócony i czytelny.

Taki wpis jasno pokazuje technologie, zakres odpowiedzialności i rezultat. Przy krótkim doświadczeniu komercyjnym potrafi mocno podnieść percepcję twojego profilu.

Co warto zapamiętać

• Sam udział w wielu hackathonach nic nie daje w CV – liczy się działające MVP, publiczne repozytorium, demo i jasny opis roli oraz użytego stacku, a nie sama linijka „uczestnik X hackathonów”.
• Zapisywanie się „w ciemno”, tylko dla nagród, pizzy czy hasła „największy hackathon”, zwykle kończy się losowym projektem, którego ani nie możesz pokazać, ani logicznie podpiąć pod swój profil kandydata.
• Hackathony trzeba dobierać pod przyszłą specjalizację (np. backend Java/.NET, a nie przypadkowe IoT/VR), bo rekruter czyta z projektów, kim chcesz być za 1–2 lata i jak spójna jest twoja ścieżka.
• Eventy stricte marketingowe, z niejasnym właścicielem kodu, zakazem publikacji repo lub NDA, często zabierają weekend, a w zamian nie zostawiają nic, co można legalnie pokazać w portfolio.
• Słaby, przypadkowy skład zespołu i brak ról (np. product ownera, lidera technicznego, osoby pilnującej repo i dema) skutkują chaotycznymi POC-ami zamiast jednego, spójnego projektu do CV.
• Jeśli na hackathonie zajmujesz się wyłącznie slajdami i pitchem, bez realnej pracy technicznej, to z perspektywy CV technicznego nie budujesz dowodu umiejętności – masz co najwyżej epizod prezentacyjny.
• Przed zapisem warto zrobić szybki audyt wydarzenia (organizator, partnerzy, tematy wyzwań, zasady własności kodu, możliwość publikacji), bo to ty decydujesz, jaki projekt po weekendzie trafi na GitHuba, a nie przypadkowy regulamin.