Prowadzimy software house, a więc jasne jest, że od czasu do czasu zdarza nam się przepytywać osoby, które są potencjalnymi kandydatami do pracy. Każdy, kto kiedykolwiek aplikował do jakiegoś zakładu, starał się o praktyki lub generalnie chciał się "pokazać", wie, co w takich sytuacjach się wysyła - jest to CV, czyli (jeśli ktoś chce pokazać, że jest erudytą) curriculum vitae, po polsku nazywany życiorysem zawodowym. Zawiera on personalia, wykształcenie, ale przede wszystkim doświadczenie danej osoby, łącznie z certyfikatami i przebytymi szkoleniami. Nie do zignorowania są też sekcje z umiejętnościami, kompetencjami, a także zainteresowaniami. Oczywiście, CV jest bardzo ważne i nawet, jeśli jesteście dopiero na wstępie swojej drogi zawodowej w IT, to powinno być wypełnione, schludne, na bieżąco aktualizowane, a jednocześnie odpowiadać stanowi rzeczywistemu. Jednak mimo to, ten dokument zwykle nie jest wystarczający, aby zainteresować sobą firmę produkującą oprogramowanie. O co jeszcze warto zadbać? O portfolio.

Zanim przejdziemy dalej, że absolutnie nie jest to tekst odkrywający tajniki rekrutacji. Jeśli szukacie materiałów na ten temat, to znajdziecie je na stronach i blogach specjalistów, takich jak Just Join IT czy SOLID.Jobs, a my nie aspirujemy, aby się z nimi równać. Zamiast tego chcieliśmy przedstawić to, w jaki sposób software house może patrzeć na przesłane portfolio kandydata i tym samym, jak kandydat może pomóc sobie (lub zaszkodzić) prezentując swoje prace. Nadmienię również, że to nasze subiektywne spojrzenie na tę kwestię.

Zacznijmy od najważniejszej rzeczy - warto utrzymywać portfolio. Nawet, jeśli jest ono skromne, to sama jego obecność jest sygnałem dla firmy, że pretendent nie próżnuje i oprócz wypisania kompetencji oraz uczestniczenia na studiach rzeczywiście może pokazać owoce swojej pracy. Przy czym tutaj należy uważać na kilka rzeczy. Oczywiście, portfolio składające się z prostego kalkulatora liczącego podstawowe operacje arytmetyczne w konsoli nie wzbudzi specjalnej ekscytacji u osób rekrutujących, nawet jeśli aplikacja będzie opisana w niesamowity sposób. Dlatego pozycje, które są pokazywane w tej sekcji, powinny być ciekawe, większe lub - najlepiej - mające sens, a nawet potencjał biznesowy. I nie oznacza to, że nie opłaca się wpisywać do prezentowanych projektów niczego poniżej poziomu Nozbe czy innych komercyjnych aplikacji - bardziej chodzi o to, aby były one "sensowne". Przykładowo, jeśli dana osoba chwali się oprogramowaniem do powtarzania słówek z angielskiego za pomocą elektronicznych fiszek, to nie jest istotne, że istnieje już masa takich programów na rynku ani że ta konkretna nie wprowadza niczego innowacyjnego. Jeśli natomiast rekrutujący widzi lub może przeczytać, że aplikacja powstała na potrzeby danej osoby (jedna z lepszych rad: "twórz coś, co Tobie samemu się przyda"), jest zmierzeniem się z nieznaną wcześniej technologią i - co zaraz podkreślę - jest skończona, to jak najbardziej jest to sygnał, że takie oprogramowanie było tworzone na poważnie i z "sercem".

I właśnie - oprogramowanie powinno być skończone lub przynajmniej w fazie, w której można je opublikować. Wielu programistów po godzinach pracuje nad swoimi prywatnymi projektami, ucząc się nowej technologii lub tworząc narzędzia, które sami będą wykorzystywali. To są idealne pozycje do portfolio, gdyż pokazują, że dana osoba ma nie tylko zapał, ale też determinację do tego, aby finalizować swoje projekty lub przynajmniej skonstruować MVP. Łatwo jest zacząć pisać oprogramowanie, wpaść na genialny pomysł i projektować go w nieskończoność - jak to ktoś kiedyś powiedział, pomysły są tanie (choć to raczej kwestia dotycząca startupów i ich spieniężenia). Natomiast przejście tej drogi przez trudności, które piętrzą się po drodze, poradzenie sobie z nimi i wreszcie stworzenie czegoś, co ktoś może nawet przeklikać już takie proste nie jest. Ale właśnie dlatego to tak cenne doświadczenie. Dużo lepsze są 2 ukończone lub "produkcyjnie" dostępne aplikacje niż 40 w fazie ciągłego rozwoju.

Przy okazji - to oznaka, że tak, nie warto ograniczyć się do programowania tylko na studiach informatycznych. Bardzo cenne jest pokazanie, że człowiek nie ogranicza się tylko do tego, ale rzeczywiście pracuje nad sobą w domu, poznając technologie inne niż omawiane w akademickich ławach. Nie chcę tutaj mówić, że lepiej być pasjonatem niż tylko rzemieślnikiem, gdyż byłoby to obraźliwe i nieprawdziwe (choć "za moich czasów..."), natomiast umówmy się - aby czegoś się nauczyć, trzeba wyjść poza strefę komfortu. Nie zawsze całkowicie, ale chociażby o jeden mały krok. Na studiach był React? Może warto poznać podejście z Reduxem. Pojawił się projekt aplikacji do zapisywania wyników meczu w Pythonie? Może warto rozbudować go o mechanizm uwierzytelniania. Nie trzeba od razu zmieniać całego stosu technologicznego, choć i czasem warto to zrobić, szczególnie na początku "kariery".

Należy też wziąć pod uwagę technologie - potencjalny pracodawca, rekrutujący np. w segmencie aplikacji mobilnych, niekoniecznie będzie zainteresowany botem giełdowym na Slacku czy aplikacją desktopową, w której kandydat spróbował swoich sił w C# i .NET Core. Jasne, że z takich pozycji, jeśli są dobrze opisane, też można czegoś dowiedzieć się o kandydacie, ocenić konstrukcje w kodzie, zobaczyć tok myślenia dotyczący technikaliów, ale także analizę wymagań - dlatego to nie jest tak, że należy takie rarytasy wyrzucać je z portfolio. Natomiast co rekrutującemu po dziesięciu aplikacjach w C#, jeśli nie widzi czegoś, co potwierdzałoby doświadczenie (lub próbę jego zdobycia) w Kotlinie/Swifcie/Ionicu/Flutterze, który jest podstawą stanowiska, o jakie toczy się gra? Oczywiście, to tylko przykład, ale warto przejrzeć, na które projekty położyć nacisk i zdecydować nie tylko o tym, z czego jesteśmy dumni jako "prywatni" programiści, ale też co rzeczywiście może przekonać firmę do nas.

Warto też zwrócić uwagę na to, co pojawia się w portfolio wielu młodych osób - wspomniane wcześniej projekty stworzone na potrzeby zajęć na uczelni. Bardzo często widzimy takie aplikacje i wcale się temu nie dziwimy - niektóre są tak duże i włożono w nie tyle serca, że spokojnie można się nimi pochwalić, zwłaszcza, że zwykle "leżą" już gotowe na Githubie (do tego jeszcze dojdziemy). Natomiast do tego też trzeba podchodzić rozsądnie. Po pierwsze, nie wszystko, co zostało stworzone w ramach zajęć na uniwersytetach jest warte pokazania, bo dobrze wiemy, jak wygląda tworzenie niektórych projektów zaliczeniowych - sami byliśmy studentami. Można ich wypisać dziesiątki, ale zwykle najwyżej kilka ma sens. Po drugie, warto uczciwie zaznaczyć, że dana aplikacja została stworzona na potrzeby zaliczenia przedmiotu, chyba że jest to projekt programisty, który przy okazji przysłużył się do zdobycia oceny, a tak naprawdę był tworzony lub rozwijany w zakresie znacznie wykraczającym poza ramy przedmiotu. Po trzecie, należy wziąć pod uwagę to, że czasami projekty powstają w grupach, niekiedy istnieją jakieś dodatkowe obostrzenia z ramienia uczelni i nie zawsze można się czymś pochwalić pod kątem prawnym lub moralnym. Co nie zmienia faktu, że studenci tej drogi nie muszą odrzucać, a jedynie ją przemyśleć.

Wspomniałem już o tym mimochodem, ale tak - osoby weryfikujące kandydata przeglądają kod. Może być to dość istotne na wielu płaszczyznach. Całkiem rozbudowane oprogramowanie, ale wyglądające w źródłach jak koszmar głównego programisty daje pole do przemyślenia. Podobnie różnice pomiędzy projektami, szczególnie czasowe, które pozwalają przekonać się, czy dany kandydat potrafi się uczyć na błędach lub włączać do swoich technik kolejne elementy. Nie zapominajmy, że profesjonalne oprogramowanie ma nie tylko działać, ale być też stosunkowo łatwe we wdrożeniu się do niego oraz modyfikacji, a zatem umiejętność pisania czytelnego kodu jest bardzo istotna. Choć, oczywiście, można ją sobie wyrobić w trakcie i do tego najlepiej nadają się praktyki lub praca.

Wreszcie, ważny jest sposób prezentacji. Zdecydowana większość programów w portfolio posiada link do Githuba i to jak najbardziej prawidłowe podejście, szczególnie, jeśli istnieje tam odpowiedni plik typu README rozszerzający opis. Natomiast jeszcze milej widziane są aplikacje znajdujące się na serwerze i osiągalne z poziomu przeglądarki. Nie zawsze jest to możliwe, ale pokazanie oprogramowania w tej formie świadczy nie tylko o zaawansowaniu projektu, ale jeszcze o czymś - że kandydat potrafi coś wdrożyć i tym samym zetknął się z wieloma tematami, które programiści mają na co dzień w pracy, mimo że nie są administratorami systemów czy specjalistami w tej dziedzinie. Niestety (albo stety?), takie umiejętności się przydają i klienci ich oczekują.

Oczywiście, nie są to wszystkie wytyczne dotyczące umieszczania portfolio w aplikacji wysyłanej do software house'u - to bardziej nasz punkt widzenia na tę sekcję wynikający z praktyki i tego, jak sami oceniamy takie osoby (pomijając inne pytania oraz poproszenie o zrobienie zadania rekrutacyjnego). Nie oznacza to, że nie możecie zachwycić potencjalnych pracodawców innymi wpisami w CV, jednak nie oszukujmy się - napisanie, że swoją znajomość JavaScriptu oceniacie na 10/10 nie jest wymierne, za to bardzo, ale to bardzo subiektywne i może się okazać, że Wasza "dziesiątka" jest "dwójką" u danej firmy. Dlatego to portfolio pokazuje, co rzeczywiście umiecie i z czego jesteście dumni. A samo przygotowywanie projektów, aby móc je pokazać, pozwala się rozwinąć i zmusza do poznawania nowych rzeczy.

Pozdrawiam i dziękuję - Jakub Rojek.

PS. Tak zupełnie na boku - pozdrawiam wszystkich, którzy aplikując na stanowisko programisty piszą w umiejętnościach "zaawansowana obsługa komputera".