CV Python Developera: jak opisać stack i projekty pod ofertę

„Python Developer” to nie jest jedno stanowisko. Pod tym samym hasłem kryją się dwie zupełnie różne role: backend web, gdzie stawiasz API w Django albo FastAPI i pilnujesz, żeby baza nie padła pod ruchem, i data/ML, gdzie czyścisz dane w pandas, liczysz w NumPy i budujesz pipeline'y, które przetwarzają gigabajty. Ten sam język, inny świat. Rekruter, który czyta ofertę backendową, szuka czego innego niż ten, który rekrutuje do zespołu danych.

Problem w tym, że większość CV Pythonowca pokazuje obie ścieżki naraz. Django stoi obok TensorFlow, FastAPI obok scikit-learn, a pod spodem ściana bibliotek, z której nie widać, czy ty budujesz serwisy produkcyjne, czy trenujesz modele. Rekruter pod ofertę backendową czyta to i nie wie, czy trafił na backendowca, który raz dotknął ML, czy na data scientistę, który raz postawił endpoint. W sześć sekund nie rozszyfruje, więc odkłada.

Poniżej masz, co wyeksponować nad fold pod konkretną ofertę Python, jak rozłożyć stack zależnie od ścieżki i jak opisać projekt przez efekt: czas zapytania, RPS, rozmiar przetwarzanych danych. Bez zmyślania, bez przepisywania historii, tylko z przesuniętym akcentem.

Co wyeksponować nad fold: Python, framework, baza i biblioteki

„Nad fold” to ta część CV, którą rekruter widzi bez przewijania. Pod ofertę Python ma tam być widać trzy rzeczy: wersję Pythona, framework albo bibliotekę z oferty i sposób pracy z danymi. To rdzeń roli, reszta jest wsparciem.

Ułóż umiejętności w kolejności istotności dla oferty, nie alfabetycznie:

• Rdzeń: Python (z wersją, np. 3.11 albo 3.12), framework z oferty (Django, FastAPI albo Flask), SQL (PostgreSQL, MySQL, ta z ogłoszenia na pierwszym miejscu).
• Realne wsparcie: ORM (Django ORM, SQLAlchemy), Celery i kolejki (Redis, RabbitMQ), Docker, testy (pytest), na ścieżce data: pandas, NumPy, narzędzia do pipeline'ów.
• Reszta: chmura, CI, monitoring, narzędzia poboczne, niżej i mniejszą wagą.

Jeśli oferta wymienia konkretną technologię, której realnie używasz, na przykład FastAPI albo Celery, ma być widoczna od razu, nie zakopana między dwudziestą a trzydziestą pozycją. Rekruter skanuje pod kątem zgodności z ogłoszeniem, nie kompletności twojej kariery. Wersja Pythona też ma znaczenie: „Python 2.7” i „Python 3.12” to dla rekrutera sygnał, w jakim kodzie się poruszasz.

Backend web czy data/ML: ten sam Python, inny akcent

To jest decyzja, która ustawia całe CV. Zanim zaczniesz przepisywać opisy, przeczytaj ofertę i ustal, której ścieżki dotyczy. Sygnały backendowe to Django albo FastAPI, REST API, SQL, kolejki, Celery, mikroserwisy, skalowalność. Sygnały data/ML to pandas, NumPy, ETL, pipeline'y, modele, scikit-learn, duże zbiory danych, Spark albo Airflow. Jedna oferta szuka kogoś, kto utrzyma serwis pod ruchem, druga kogoś, kto przetworzy terabajty i nie zarżnie pamięci.

Pod ofertę backendową eksponuj framework webowy, projektowanie API, pracę z bazą i wydajność zapytań. Celery i kolejki pokaż jako narzędzie do zadań asynchronicznych pod ruchem produkcyjnym. Pandas i NumPy zejdź na dalszy plan albo wytnij, jeśli nie były częścią tej roli. Pod ofertę data/ML odwróć kolejność: na pierwszy plan wchodzi przetwarzanie danych, rozmiar zbiorów, czas wykonania pipeline'u, a framework webowy ląduje niżej jako kontekst, w którym serwowałeś wynik.

To ten sam Python i często ten sam projekt, tylko inny pierwszy plan. Jeden projekt zwykle daje materiał na kilka odcieni roli: backend produktowy, integracyjny, data engineering. Pokazujesz to bez przepisywania historii, przesuwając akcent na to, czego chce ogłoszenie. Mechanikę rozkładamy w jeden projekt, cztery role. Jeśli mocniej ciągnie cię w stronę modeli, akcenty pod tę ścieżkę rozkładamy w CV AI / ML Engineera.

Jak opisać projekt efektem, nie zadaniem

To jest miejsce, gdzie większość CV Pythonowca się wykłada. Ludzie wypisują, co robili („pisałem endpointy w FastAPI”, „przetwarzałem dane w pandas”), a to są obowiązki, nie dokonania. Nie widać ani skali, ani tego, czy po twojej robocie cokolwiek działało szybciej. Pokaż punkt wyjścia, zmianę i efekt, mierzony tym, co się w danej roli liczy: czas zapytania, RPS, rozmiar danych, czas wykonania pipeline'u.

Słaby zapis, który czyta się jak zakres obowiązków:

Pisałem endpointy w FastAPI i przetwarzałem dane wejściowe przed zapisem do bazy.

Ten sam fakt, ustawiony pod ofertę backendową:

Zaprojektowałem REST API w FastAPI obsługujące 900 RPS przy p99 poniżej 90 ms. Wyniesienie ciężkiego przetwarzania do zadań Celery na Redisie i dodanie indeksów skróciło czas najwolniejszego zapytania z 1,2 s do 70 ms na bazie z 30 mln rekordów.

Druga wersja opisuje dokładnie to samo, co robiłeś, ale pokazuje skalę (900 RPS, 30 mln rekordów), zmianę (Celery, indeksy) i wpływ (czas zapytania z 1,2 s do 70 ms). Na ścieżce data ta sama mechanika, inne metryki: „pipeline ETL w pandas przetwarzający 50 GB dziennie, skrócony z 4 godzin do 35 minut po wektoryzacji w NumPy i przejściu na przetwarzanie wsadowe”. Widać rozmiar danych, zmianę i czas wykonania, a nie ogólnik „optymalizowałem przetwarzanie”.

Mocne akcenty pod Pythona i ich konkrety: czas zapytania (z X do Y ms po optymalizacji), przepustowość (RPS, liczba rekordów na sekundę w pipeline), rozmiar danych (GB przetworzone, liczba wierszy, partycje), czas wykonania (skrócony pipeline albo task w Celery), niezawodność (liczba błędów po refaktorze, pokrycie testami w pytest).

Słowa kluczowe z ofert Python

Oferty pythonowe powtarzają konkretny zestaw zwrotów i różnią się zależnie od ścieżki. Backend: python (z wersją), django albo fastapi, flask, rest api, sql, postgresql, django orm albo sqlalchemy, celery, redis, docker, pytest, ci/cd, mikroserwisy. Data/ML: pandas, numpy, etl, airflow, spark, scikit-learn, jupyter, sql, przetwarzanie dużych zbiorów. To są twoje słowa kluczowe. Wyciągnij must-have z konkretnej oferty i sprawdź, które masz pokryte realnym przykładem z projektu, a których lepiej nie wpisywać, bo zweryfikują je na pierwszej rozmowie technicznej w pięć minut. Jak czytać ogłoszenie pod tym kątem, rozkładamy w jak wyciągnąć słowa kluczowe z oferty IT.

Uważaj na pułapkę: wpisanie do skills całego ekosystemu Pythona, bo „kiedyś dotknąłeś”. Rekruter pod backend nie szuka najdłuższej listy, tylko zgodności z must-have i dowodu w projektach. Co zostawić, a co wyciąć pod konkretne ogłoszenie, rozkładamy w jak dopasować CV do oferty IT.

Częste błędy

• Backend i data w jednym worku. Django obok TensorFlow i pandas obok mikroserwisów to sygnał, że CV nie jest pod żadną z tych ról. Wybierz ścieżkę z oferty i ustaw stack pod nią, resztę zejdź niżej albo wytnij.
• Brak skali i metryk. „Optymalizowałem zapytania” albo „przetwarzałem dane” bez liczb jest puste. Zbiór na tysiąc wierszy to inna liga niż 50 GB dziennie. Dopisz rozmiar danych, RPS, czas zapytania albo czas wykonania pipeline'u przed i po.
• Lista bibliotek zamiast użycia. Sam wpis „Celery, pandas, NumPy” nic nie mówi. Pokaż, gdzie ich użyłeś i co to dało: ile zadań na minutę obsługiwała kolejka, o ile skróciłeś pipeline po wektoryzacji.

Jak złożyć CV Python pod ofertę w ZłóżCV

Pod ofertę Python ZłóżCV czyta z ogłoszenia, czy to backend web, czy data/ML, bierze z twojej bazy projekty pasujące do tej ścieżki, układa stack pod wymagania oferty i przepisuje opisy tak, żeby było widać skalę, efekt i decyzje, a nie samą listę bibliotek. Wklejasz link do oferty, dostajesz dopasowane CV w PDF. Złóż CV pod ofertę Python, dwa pierwsze za darmo, bez karty.

Najczęstsze pytania

Robię i backend, i trochę data. Którą ścieżkę pokazać? Tę z oferty, na którą aplikujesz. Jeśli ogłoszenie to Django i REST, na pierwszy plan idzie backend, a data zostaje jako kontekst albo znika. Jeśli to pipeline'y i pandas, odwracasz kolejność. Nie wysyłaj jednego CV, które pokazuje obie naraz, bo nie trafi w żadną. Pod różne oferty układasz różne akcenty z tego samego doświadczenia.

Wpisywać wersję Pythona i frameworka? Tak. „Python 3.12” i „Django 5” to sygnał, że pracujesz na aktualnym stacku, a nie utrzymujesz wyłącznie legacy na Pythonie 2. Jeśli pracowałeś na starszych wersjach, nie kłam, ale pokaż też, gdzie dotknąłeś nowszych, choćby przy migracji albo w projekcie pobocznym.

Oferta wymaga FastAPI, a ja robiłem w Django, co wtedy? Pokaż Django jako dowód, że budujesz API w Pythonie, i nazwij wprost, że FastAPI jest na twojej liście do szybkiego wejścia. Frameworki webowe w Pythonie dzielą tę samą logikę: routing, walidacja, ORM, zadania asynchroniczne. Jeśli FastAPI jest twardym must-have, a ty go nie dotykałeś, opisz pokrewne kompetencje uczciwie, zamiast dopisywać framework, którego nie znasz.

Jak pokazać wydajność, gdy nie mierzyłem dokładnych liczb? Podaj rzędy wielkości, które pamiętasz, zamiast zmyślać precyzję. „Baza rzędu kilku milionów rekordów”, „pipeline na dziesiątki GB dziennie”, „zapytanie z kilku sekund do poniżej sekundy” jest wiarygodne i konkretniejsze niż „poprawiłem wydajność”. Lepszy uczciwy rząd wielkości niż ładnie brzmiąca liczba, której nie obronisz na rozmowie.