Konkurencja wśród osób rozpoczynających karierę w IT jest coraz większa, a kluczem do sukcesu jest wyróżnienie się z masy podobnych do siebie kandydatów. A nic nie wyróżnia nas tak skutecznie jak dobrze zrealizowane projekty. Tylko co to oznacza? Jak powinno wyglądać portfolio młodszego programisty? Czy pisać w CV o projektach zrealizowanych w ramach kursów, tutoriali i bootcampów? I czy warto chwalić się wszystkim, co zrobiliśmy czy może jednak o pewnych rzeczach nie warto wspominać?
Dobre projekty kluczem do sukcesu w IT
Wielokrotnie powtarzałem, że najważniejszym elementem CV programisty jest doświadczenie – kod, który napisaliśmy i projekty, które zrealizowaliśmy. A jeżeli nie mamy ukończonych studiów informatyczych – które nie są niezbędne, by zostać programistą – to tym bardziej to doświadczenie musimy podkreślić.
Ale w jaki sposób to zrobić? Jakie projekty będą właściwe do zilustrowania naszego doświadczenia?
O jakich projektach nie warto wspominać?
Zaczniemy od projektów, o których w CV nie warto wspominać. I nie dlatego, że są to nieważne projekty, których zrobienie było stratą czasu, bo żaden projekt nie jest nieważny. Nigdy nie powinniśmy mówić, że realizacja jakiegoś projektu była stratą czasu, bo zawsze czegoś się uczymy. Parę lat temu, w jednej z firm, pracowałem nad naprawdę fatalnym projektem – utrzymywaliśmy bardzo stary kod, nie dosyć, że napisany fatalnie, to jeszcze napisany z użyciem technologii, które dawno już zdążyły wyjść z użycia. Można powiedzieć, że niczego mnie ten projekt nie nauczył, ale czy to faktycznie prawda? Nie zawsze będziemy pracować nad projektem od zera, czasem będziemy musieli zająć się jakimś starym kodem, napisanym w jakichś nudnych techologiach przez niezbyt kompetentnych programistów. I właśnie pracy z takim kodem wtedy się nauczyłem.
Każdy projekt jest ważny, ale niekoniecznie dla innych
Dlatego uważam, że każdy projekt czegoś uczy. Każdy jest ważny. Dla nas. Ale niekoniecznie jest to tak samo ważne dla innych, zwłaszcza dla osób, które będą rekrutować nas do pracy. Wyobraźmy sobie, że aplikujemy do pracy na kierowcę zawodowego albo kuriera, w każdym razie gdzieś, gdzie non stop będziemy jeździć samochodem, a prawo jazdy zrobiliśmy dopiero kilka miesięcy temu. Wcześniej przez wiele lat radziliśmy sobie bez samochodu, także dla nas zrobienie prawka to ogromna rzecz, coś co całkowicie zmieniło nasze życie, coś z czego jesteśmy mega dumni. Ale raczej nie jest to coś, czym będziemy się chwalić i przedstawiać jako nasz sukces aplikując do pracy jako kierowca.
Pewne rzeczy, z których my możemy być mega dumni, rzeczy, dzięki którym mega dużo się nauczyliśmy, dla innych mogą być po prostu oczywiste. Wiadomo, że jak aplikujesz na kierowcę, musisz mieć prawo jazdy. To rzecz oczywista i powszechna – to umiejętność, którą posiada każdy kandydat.
Czyli nie chwalimy sie oczywistościami i tym, co jest powszechne, tym co nas nie wyróżnia spośród innych.
Projekty z tutoriali
A pierwszymi tego typu projektami są projekty, które wzięliśmy z tutoriali. Wiadomo, to kusi – robimy jakiś obszerny kurs na Udemy albo korzystając z jakiegoś innego serwisu, w trakcie tego kursu budujemy projekt, a skoro już go zbudowaliśmy, myślimy sobie – super, wrzucę go na GitHuba i będzie do portfolio. Będę miał się czym pochwalić. Ale zadajmy sobie pytanie – jaki był Twój faktyczny udział w stworzeniu tego projektu? Czy zaprojektowałeś rozwiązanie? Czy wybrałeś techologie do jego realizacji? Jak rozwiązałeś problemy, które pojawiły się po drodze? A może po prostu przepisałeś ten projekt linia po linii wraz z prowadzącym? To nie jest nic złego, to jest doskonały sposób na naukę i zawsze będę to powtarzał, ale jednocześnie mam spore wątpliwości, czy o takim projekcie powinieneś wspominać w CV. Jeżeli identycznym projektem może pochwalić się dowolna osoba, która wykupi dostęp do tego samego kursu, to gdzie jest tutaj ten element, którym możesz się wyróżnić?
Projekty zbyt proste i zbyt oczywiste
Nie ma też sensu umieszczać w CV prostych programów, na których uczysz się podstaw programowania. Aplikacje typu konwerter jednostek czy kalkulator są spoko i są to aplikacje, podczas których na pewno dużo się nauczysz, ale są to aplikacje, których studenci na studiach informatyczych robią dziesiątki, a może nawet setki. Każdy przedmiot, praktycznie każde zadanie na studiach informatycznych wiążą się z zaprogramowaniem czegoś. Raz piszesz jakiś prosty program w C, innym razem piszesz coś w Javie, przy kolejnym zaliczeniu wykorzystujesz Pythona do przeprocesowania jakichś danych, a przy jeszcze innej okazji robisz wyliczenia w Matlabie. Przez całe studia jest tego tak dużo, że nie tylko nie starczyłoby miejsca w CV na wypisanie wszystkigo, ale też te rzeczy są tak oczywiste, że nawet nie przychodzi ci do głowy, żeby o tym wspominać aplikując o pracę.
Lepszy prosty projekt niż żaden? Nic z tych rzeczy!
Można czasem usłyszeć głosy, że lepiej umieszczać proste projekty niż żadne – z jednej strony brzmi to logicznie i sensownie, ale prawda jest taka, że tego typu projekty nie stanowią w Twoim portfolio żadnej wartości. I teraz możesz faktycznie posłuchać tych osób, które klepią Cię po plecach i mówią “ekstra robota, stary, lepiej dać takie projekty niż żadne”, tylko, że to raczej nie przybliży Cię do celu pod tytułem “pierwsza praca w IT”. Możesz też posłuchać mnie, a ja wychodzę z założenia, że lepiej podchodzić do tematu realistycznie i lepiej jest powiedzieć “wiesz co, super, że zrobiłeś te projekty, to dobry początek, masz juz jakieś podstawy, ale musisz jeszcze sporo popracować”. Powtórzę to raz jeszcze – nie ma sensu pisać i opowiadać o prostych, niewyróżniających się niczym projektach, bo to po prostu strata czasu. Rekruterów nie interesuje to jakie kursy na Udemy kupiłeś, rekruterów interesuje to co potrafisz i to w jaki sposób potrafisz rozwiązywać problemy. I kluczem do wszystkiego jesteś tutaj Ty.
Chodzi o Twoje umiejętności, Twoje doświadczenie, Twoje sposoby rozwiązywania problemów, Twoje podejście do szukania rozwiązań.
Projekty muszą być związane z Tobą
Projekty, o których napiszesz, muszą (a przynajmniej powinny) być mocno związane z Tobą. Nie projekty z kursów, nie projekty stworzone podczas bootcampu, tylko projekty, za które sam byłeś odpowiedzialny, projekty, do których dobrałeś odpowiednie narzędzia i do których sam zaprojektowałeś odpowiednie rozwiązania. Mówiąc sam mam tutaj na myśli Ciebie jako pojedynczą osobę, ale też Ciebie jako członka zespołu projektowego.
I od razu dam przykłady projektów, o których pisałem w swoim CV, gdy aplikowałem o swoją pierwszą pracę, a nawet nie tyle pracę, co o darmowe, trzymiesięczne praktyki. Były to dwa duże projekty ze studiów i jeden projekt, nad którym pracowałem sam w wolnym czasie.
Projektami ze studiów były szachy z wykorzystaniem sztucznej inteligencji i komunikator internetowy. Projektem, nad którym pracowałem sam był CMS czyli system zarządzania treścią, dla magazynu muzycznego, który współtworzyłem.
Projekt nr 1 – szachy z AI
Szachy realizowałem w ramach zajęć ze sztucznej inteligencji. Nad projektem pracowaliśmy w parach, a wymaganie było jedno – stworzyć program szachowy, przeciwko któremu będziemu mogli zagrać. Nie mieliśmy narzuconego języka, w którym mamy to zrobić ani żadnego rozwiązania. Wszystko zależało od nas. Zdecydowaliśmy się na algorytm minimax, który w trakcie semestru – to bardzo prosty algorytm, który sprawdza wszystkie możliwe ruchy przeciwnika w danym monencie, następnie dla każdego z tych ruchów sprawdza wszystkie możliwe nasze ruchy i znowu, dla każdego z tych ruchów sprawdza wszystkie możliwe ruchy przeciwnika, i tak dalej, i tak dalej, aż do momentu gdy sprawdzi wszystkie możliwe kombinacje w grze. Tylko, że szachy to gra z trochę zbyt dużą ilością kombinacji, żeby sprawdzić wszystkie. Bez problemu możemy to zrobić w przypadku gry w Kółko i krzyżyk i dzięki temu, zawsze podejmować najlepszą możliwą decyzję, ale w szachach to niemożliwe – liczba wszystkich możliwych przebiegów gry w szachy to 10^120.
Żeby zilustrować jak duża jest to liczba, wystarczy powiedzieć, że jest to liczba większa niż liczba wszystkich atomów w całym obserwowalnym wszechświecie. Ale nie oznacza to, że z algorytmu minmax nie możemy w ogóle skorzystać. Robimy to tak, że zaczynając partię sprawdzamy wszystkie możliwe ruchy, potem dla tych wszystkich możliwych ruchów sprawdzamy znowu wszystkie i robimy tak kilka razy, do momentu, kiedy komputer wciąż ma wystarczająco dużo pamięci, żeby wykonać obliczenia. W tym momencie mamy jakąś sytuację na planszy i znając zasady gry w szachy mozemy ocenić na ile jest to dobra sytuacja. Tę ocenę wyrażaliśmy w punktach, tak aby było możliwe porównanie tej sytuacji z innymi możliwymi sytuacjami. W naszym przypadku udało nam się dojść do szóstego poziomu wgłąb, przy kolejnym poziomie program rzucał już błędem o braku pamięci. Także przy tym projekcie było kilka kluczowych kwestii, którymi musieliśmy się zająć:
- dobre zrozumienie algorytmu minmax
- wybór języka do zaimplementowania rozwiązania wymagającego dobrego wykorzystania dostępnej pamięci → zdecydowaliśmy się więc na język C, który przy tak intensywnych obliczeniach mógł nam dać sporą przewagę
- dobre zrozumienie zasad gry w szachy i subiektywna ocena sytuacji na planszy w dowolnym momencie gry → musieliśmy sami opracować system tej oceny
- implementacja → też nie była to sprawa trywialna, musieliśmy zadbać nie tylko o te punkty, o których przed chwilą wspomniałem, ale także – a może przede wszystkim – o to, żeby każdy ruch miał sens, żeby każdy ruch był zgodny z zasadami gry w szachy
Także jak widzimy – pomimo, że był to projekt na studiach – nie był to projekt banalny, do czego jeszcze za chwilę wrócę, ale teraz porozmawiajmy o kolejnym projekcie.
Projekt nr 2 – komunikator internetowy
Tym projektem był komunikator internetowy i przyznam tutaj szczerze, że nie pamiętam, w ramach jakiego przedmiotu go realizowaliśmy, ale pamiętam, że robiliśmy to w 4-osobowym zespole i to do nas należało zaproponowanie samego tematu projektu, następnie zaprojektowanie architektury, zaplanowanie pracy i sama implementacja. Nasz wykładowca pełnił jedynie rolę koordynatora. Tak więc za nasz projekt byliśmy odpowiedzialni praktycznie w 100%. Pamiętam, że w odróżnieniu od programu szachowego w tym przypadku od strony algorytmicznej nie było jakichś specjalnych wyzwań, ale za to dużym wyzwaniem było opracowanie właściwej architektury i wypracowanie dobrych rozwiązań. Także musieliśmy zrobić porządny research, doszkolić się od strony teoretycznej i rozważyć różne możliwe opcje. Pamiętam, że finalnie zdecydowaliśmy się na skorzystanie z protokołu XMPP, próbowaliśmy też zaimplementować opcję streamingu muzyki i filmów – chcieliśmy umożliwić wybranie pliku MP3 lub pliku wideo i wysłanie tego pliku do drugiej osoby, ale nie w całości, tylko właśnie wykorzystując streaming. Kojarzę, że to wszystko nie było takie proste, że spędziliśmy wiele godzin na próbowaniu różnych rozwiązań i pewnie nie pamiętałbym jaki był dokładnie efekt końcowy, ale znalazłem raport dotyczący tego projektu, także spójrzmy szybko na wnioski.
Problem formulation: From the supervisor an open project was given in which the group should brainstorm and choose a network based problem with a cutting edge, and then work to solve it. Solution: It was decided to work with an Instant Messenger capable of streaming an MP3 music file and a video file, as well as provide reliable text transfer. Results: The MP3 file was unable to be streamed properly, thought an MJPEG video file was possible to stream and play. Reliable text transfer wasn’t possible to make either. Conclusion: The Instant Messenger does not live up to all the demands and requires further work in terms of getting the music streaming to work as well as providing a reliable text transfer.
Czyli nie wszystko się udało, nie każdy problem udało nam się rozwiązać. Dzisiaj wiele z tych problemów prawdopodobnie w ogóle by się nie pojawiło, ale musimy pamiętać, że jest to projekt, który realizowałem kilkanaście lat temu, kiedy narzędzia, którymi dysponowaliśmy były trochę niż obecnie.
Projekt nr 3 – system zarządzania treścią w serwisie muzycznym
Trzeci projekt – stworzony z użyciem PHP i MySQL system zarządzania treścią dla magazynu muzycznego, który współtworzyłem. Umożliwiał kompleksowe zarządzanie artykułami i komentarzami na stronie. Nie był to jakiś wyjątkowo skomplikowany od strony technicznej projekt, ale na pewno był to projekt wymagający z kilku powodów – po pierwsze musiałem zintegrować cały ten tworzony przeze mnie silnik z już istniejącym layoutem strony, po drugie był to pierwszy tak rozbudowany projekt, nad którym pracowałem i to właśnie na nim uczyłem się PHP i SQL, a po trzecie pracowałem nad nim całkowicie sam, zdany jedynie na rewelacyjną książkę PHP Receptury, bo nie było wtedy jeszcze Stack Overflow, gdzie mógłbym poszukać odpowiedzi w przypadku pojawienia się problemów. To wszystko sprawiało, że warto było napisać o tym projekcie w CV. Ten projekt pokazywał też, że poza tym co zrobiłem na studiach, interesowałem się też programowaniem na własną rękę, jeszcze na długo przed napisaniem pierwszego programu na studiach.
Jakie cechy powinny mieć projekty w CV?
I tutaj dochodzimy do podsumowania, jakie projekty powinniśmy umieścić w portfolio i co te projekty powinny ilustrować. I właśnie ta pasja do programowania jest jednym z najważniejszych elementów, które powinniśmy podkreślić – nie chodzi tylko o to, że idziemy na studia i robimy to, co ktoś nam każe zrobić. Albo idziemy na bootcamp i robimy tylko to, co zostało zapisane w programie. To samo z kursami online i tutorialami – nie chodzi tylko o wykonanie krok po kroku czegoś, co napisał ktoś inny. W tym wszystkim chodzi o pokazanie siebie – tego, co nas interesuje, tego, czego postanowiliśmy się nauczyć, o opowiedzenie o problemach, które napotkaliśmy po drodze i o tym, w jaki sposób te problemy rozwiązaliśmy. To co interesuje rekrutera to nasze doświadczenie, nasze spojrzenie na wyzwania, z którymi się zmierzyliśmy, nasza argumentacja dotycząca rozwiązań, na które się zdecydowaliśmy.
Projekty, o których chce się rozmawiać
A same projekty powinny być właśnie takimi projektami, o których chce się rozmawiać. Powinny więc być takie, żeby w ogóle było o czym rozmawiać. Jeżeli stworzymy REST API do pobierania i edycji użytkowników w bazie danych to ok, to na pewno kolejny krok w naszym rozwoju programisty, ale na pewno nie jest to coś, o czym moglibyśmy jakoś wyjątkowo długo pogadać. Oczywiście rekruter może zadać kilka pytań na temat znajomości REST API, na temat dobrych praktyk przy tworzeniu takiego API, ale jeżeli chodzi o sam projekt, to jest to tak elementarna rzecz, że po prostu nie da się o niej długo dyskutować. Tak więc każdy projekt, którym chcemy się pochwalić, powinien być w jakiś sposób charakterystyczny i niebanalny. Na przykładzie trzech moich projektów:
- program szachowy był sporym wyzwaniem od strony algorytmicznej, możemy też przy jego okazji sporo porozmawiać o wybranym języku programowania, może pojawić się pytanie czy na pewno musiało to być napisane w C, czy zaobserwowalibyśmy dużą różnicę wydajności, gdybyśmy stworzyli podobny program w Javie czy Pythonie, możemy również podyskutować na temat możliwych usprawnień, czyli na przykład odrzucaniu przez algorytm najbardziej bezsensownych ruchów, żeby ne marnować mocy obliczeniowej na scenariusze, których i tak żaden rozsądny gracz nie wybierze, tego pola do dyskusji jest naprawdę dużo
- messenger nie był wyzwaniem algorytmicznym, ale był wyzwaniem jeżeli chodzi o opracowanie odpowiedniej architektury, wybranie odpowiednich narzędzi, zaplanowanie pracy, ponieważ byliśmy czterema studentami pochodzącymi z czterech różnych krajów, poznaliśmy się dopiero na tych zajęciach, a musieliśmy razem wyjść z propozycją projektu, a następnie ten projekt zrealizować, tak jak wspominałem nie wszystko w projekcie się udało, natrafiliśmy na problemy, których nie udało nam się przeskoczyć, więc tutaj też mamy dużo możliwości rozmowy
- system zarządzania treścią teoretycznie nie był niczym skomplikowanym, ale tworzyłem go w czasach, gdy nie było takiego dostępu do materiałów edukacyjnych jak teraz, nie było Stack Overflow, sam internet był namiastką tego, co mamy teraz, także de facto jedynym miejscem, do którego mogłem zajrzeć w poszukiwaniu rozwiązania, była jedna książka – wspomniane PHP Receptury, a sam projekt był moim pierwszym projektem realizowanym w PHP i MySQL, moje wcześniejsze doświadczenie w programowaniu było naprawdę ubogie. Także pomimo pozornej prostoty projektu był to świetny temat do dyskusji – od razu nasuwały się takie pytania jak to dlaczego zdecydowałem się na wybór właśnie PHP i MySQL, w jaki sposób starałem się rozwiązywać trudne problemy i czy zdarzyły mi się takie problemy, przy których naprawdę na długo utknąłem i jak sobie wtedy poradziłem. To są wszystko kwestie bardzo ważne w pracy programisty i każdy rekruter chce wiedzieć, z jak dużymi problemami do tej pory miałeś do czynienia i jak na nie zareagowałeś.
Projekty powinny być też zróżnicowane – od 10 podobnych projektów napisanych w tych samych technologiach, dużo lepiej będzie wyglądać 5 projektów, ale każdy stworzony przy pomocy zupełnie innego stacka technologicznego.
Pytanie jeszcze co z tymi wspomnianymi na początku projektami z tutoriali i kursów – czy faktycznie żadnego z nich nie wpisywać? Jeżeli przepiszesz wszystko linia po linii, to nie ma absolutnie najmniejszego sensu, ale wygląda to zupełnie inaczej jeżeli tego typu projekty posłużą Ci jako inspiracja – możesz stworzyć coś nowego, coś swojego, z wykorzystaniem tej wiedzy, możesz też te projekty rozwinąć, dodać nowe funkcjonalności albo zmienić używane technologie. Czyli w tutorialu tworzysz projekt full stackowy, a potem zmieniasz backend – przykładowo z Node.js na Springa albo odwrotnie. Jest już w tym Twoja inwencja, Twoja decyzja o zmianie używanej technologii i już jest okazja do dyskusji – dlaczego się na na to zdecydowałeś, jakie są zalety jednej i drugiej technologii, jakie problemy napotkałeś w jednym i drugim przypadku, i tak dalej i tak dalej.
Gdzie szukać inspiracji do tworzenia ciekawych projektów?
A jeżeli chcesz mieć pierwsze inspiracje do tworzenia fajnych projektów, polecam dwie rzeczy – mojego ebooka Roadmapa programisty, w którym nie tylko opowiedziałem czego, kiedy i dlaczego się uczyć, żeby zostać programistą, ale też zebrałem pomysły na ponad dwadzieścia projektów oraz film Własny projekt czyli jak skutecznie uczyć się programowania? który znajdziecie tutaj.
