Nie ma dobrego zamiennika na lata doświadczenia. Devdebata cz.2

Czy w ofertach pracy rekruterzy powinni zamieszczać lata doświadczenia kandydata? To pytanie zadaliśmy czterem seniorom, którzy podzielili się swoimi spostrzeżeniami. Jeden z nich odpowiedział na nie tak: – Nie ma dobrego zamiennika na lata doświadczenia, trzeba z nim żyć, ale już w ogłoszeniu można zawrzeć więcej szczegółów na temat tego, nad czym konkretnie programista będzie pracował.

Zobaczcie, jak na inne pytania odpowiedzieli:

• Marcin Lasak. Senior frontend developer w Divante. Rok po otrzymaniu swojego pierwszego komputera zaczął bawić się technologiami webowymi i do tej pory uwielbia frontend. Ostatnio pisze w Angularze, mimo że kocha Reacta.
• Sławomir Grabowski. Inżynier oprogramowania w Quick Turn Studio. Zwolennik pracy z modern C++ w połączeniu z Test Driven Development, prowadzący krucjatę przeciwko singletonom i referencjom do std::share_ptr. W swoim startupie tworzy framework do tworzenia aplikacji UI dla urządzeń wbudowanych. Po godzinach tworzy turową grę strategiczną osadzoną w świecie fantasy.
• Rafał Jaworowski. Senior Full Stack Developer w Hitachi ABB PowerGrids. Wcześniej Senior Developer w Societe Generale, AON, a jeszcze wcześniej (Developer/Senior Developer/Architekt) w PKP Informatyka. Pasjonat słuchania innych ludzi i uczenia się od nich. Dobry kolega z zespołu i osoba, której nie zależy na nazwie stanowiska a na ludziach. Lubi rozmawiać o architekturze i stara się rozumieć potrzeby innych. Chętnie pomaga, „bo wół nie zapomniał jak cielęciem był”.
• Sylwek Brzęczkowski. Python Technical Lead w Trust Stamp, gdzie zajmuje się użyciem danych biometrycznych w usługach. Po pracy twórca kanału na YouTube “Sylwek Brzeczkowski” oraz współtwórca podcastu CYBERFAZA. We wszystkim co robi koncentruje się na odbiorcy, czy to klient, widz czy słuchacz. Wielki fan optymalizacji procesów, wyznawca twelve-factor i pragmatycznego myślenia. Ojciec dwóch chłopaków, hobbystycznie gitarzysta.

Zapraszamy też do zapoznania się z pierwszą częścią tej devdebaty.

4. Może są branże, projekty, w których określanie doświadczenia po stażu pracy sprawdza się?

Marcin Lasak, Senior frontend developer w Divante:

Nic nie przychodzi mi na myśl, jeśli chodzi o branżę IT. Może w przypadku innych zawodów jest to trochę lepszy wyznacznik, ale nie wydaje mi się, żeby istniał zawód, w którym 20 lat doświadczenia jednej osoby byłoby bardzo zbliżone do innych osób z identycznym stażem. Wszystko jest uwarunkowane tym jak się rozwijaliśmy przez te 20 lat. Czy spędziliśmy je na robieniu cały czas tego samego, czy na ciągłej nauce.

Sławomir Grabowski, Inżynier oprogramowania w Quick Turn Studio:

Wydaje mi się, że nie. I to nie tylko w IT. Kiedyś znajomy opowiadał mi historię, że prowadził rozmowę na radcę prawnego z osobą z kilkuletnim doświadczeniem zawodowym, która nie potrafiła nawet napisać wezwania do zapłaty. Moim zdaniem im większego eksperta potrzebujemy, tym dokładniej należy zweryfikować jego umiejętności.

Rafał Jaworowski, Senior Full Stack Developer Hitachi ABB PowerGrids:

Oczywiście jeśli bierzemy pod uwagę wiedzę domenową. Frameworka może nauczyć się każdy, ale wiedza domenowa to już grubsza sprawa – banki, instytucje finansowe, NASA albo lotnicza.

Sylwek Brzęczkowski, Technical Lead w Trust Stamp:

Sprawdza we wszystkich, w których pracowałem, tj. Python około webowe i około computer vision, o ile kandydat jest szczery, no i jeśli nie traktuje się tej informacji jako ostateczny wyznacznik doświadczenia.

Podczas rozmowy z kandydatem, można wyczuć czy ten człowiek z daną technologią przepracował ten czas, czy tylko o niej czytał w książkach. Nie zgodzę się z tym, że “lata doświadczenia kompletnie nie mają znaczenia”. Oczywiście, że mają, ale może nie takie duże, jak jest to zakładane w pytaniu.

5. Skoro nie lata pracy, to co? W jaki sposób rekruterzy powinni szukać doświadczonych programistów?

Marcin Lasak, Senior frontend developer w Divante:

Nie wydaje mi się, żeby coś takiego istniało. W przypadku branży, która nie jest powszechnie uregulowana stopniami naukowymi, certyfikacją, czy oficjalnymi uprawnieniami wydaje mi się, że ten problem będzie zawsze istniał. A sprawdzenie tego, że kandydat posiada wystarczające doświadczenie na dane stanowisko będzie możliwe tylko i wyłącznie w czasie dobrego procesu rekrutacji.

Warto skupić się w takim przypadku na optymalizacji tego procesu, żeby był on jednocześnie krótki, ale dokładnie weryfikujący doświadczenie kandydata. Niech taka rekrutacja jak najszybciej weryfikuje wymagania i nie marnuje czasu kandydatów i osób zaangażowanych w rekrutację.

Sławomir Grabowski, Inżynier oprogramowania w Quick Turn Studio:

Pytanie trochę nieprecyzyjne, bo jak ktoś ma być doświadczony to ma mieć doświadczenie. Domyślam się, że chodzi tutaj o kogoś wykwalifikowanego. Dodatkowo pytanie czy tu chodzi o coś, co ma być tylko na podmianę do ogłoszenia czy nałożenia filtra na CV. Jeśli to pierwsze to nie ma co wstawiać czegoś na miejsce wymaganych lat doświadczeń tylko pozostawić jedną linijkę w ogłoszeniu mniej.

Jeśli to drugie to moim zdaniem nie ma co nakładać wyrafinowanego filtra na CV, bo programistów brakuje, więc jeśli chcemy mieć kogoś wykwalifikowanego, na wysokim poziomie to bym odrzucał na początku tylko tych kandydatów, którzy nie mają żadnego doświadczenia.

Natomiast dalsza weryfikacja wymaga stworzenia pożądanego profilu do danego projektu, a to wymaga współpracy rekruterów z osobami, które w tym projekcie są. To jest bardzo złożone zagadnienie, o którym mógłbym mówić kilkadziesiąt minut, zapisać kilka stron, a to tylko na bazie doświadczeń z rozmów kwalifikacyjnych, gdzie kandydat już przyszedł na rozmowę.

W ogromnym skrócie należy:

• stworzyć zestaw umiejętności, który rzeczywiście jest potrzebny i ich poziom,
• określić zalety i wady pracy w projekcie,
• określić charakter, osobowość wymaganą do danej roli i projektu, bo np. nie ma co zatrudniać ambitnego eksperta do zadań może nie tyle co łatwych, co żmudnych i niepozwalających na wdrażanie własnych rozwiązań i pomysłów,
• na technicznej części rozmowy robić jak najwięcej zadań odzwierciedlających pracę w projekcie, a nie przepytywać na prawo i lewo ze standardu języka, do którego można sobie podczas pracy zajrzeć w google.

Dlaczego tak? Byłem w kilku projektach, w których najefektywniejsi nie byli tzw. seniorzy, którzy starali się architektoniczne ogarnąć wszystko według wzorców projektowych, tylko młodzi, którzy trzaskali bugi na odziedziczonym kodzie klienta, którzy nie przejmowali się syfem w jakim im przyszło pracować. Dlatego należy przed zadaniem sobie pytania „kogo szukamy” należy zadać sobie pytania „do czego tego kogoś szukamy”.

Rafał Jaworowski, Senior Full Stack Developer Hitachi ABB PowerGrids:

Potrzeba zadawać inteligentne pytania pasujące do wymagań stanowiska i wykonywanej pracy. Pytaniami zweryfikuje się doświadczenie. Chyba, że ten, kto pyta nie jest techniczny albo jest juniorem.

Sylwek Brzęczkowski, Technical Lead w Trust Stamp:

Nie ma dobrego zamiennika na lata doświadczenia, trzeba z nim żyć, ale już w ogłoszeniu można zawrzeć więcej szczegółów na temat tego, nad czym konkretnie programista będzie pracował. Jeśli idziemy o krok dalej w rekrutacji to zgadzam się tutaj z wypowiedzią Sławomira.

6. Porozmawiajmy o tytułach. Waszym zdaniem określenia junior, regular i senior są dla każdej firmy inne?

Marcin Lasak, Senior frontend developer w Divante:

Oczywiście. Niektóre firmy patrzą tylko i wyłącznie na lata pracy, inne tylko na umiejętności, a w jeszcze innych jest to mix doświadczenia z umiejętnościami. Zdarza się, że jest zdefiniowana bardzo precyzyjna lista umiejętności, które trzeba posiadać, żeby móc dostać awans, ale w takim wypadku może być problem na patrzenie na ogólna postawę pracownika. Czy faktycznie jest samodzielny, czy sam potrafi “zamknąć temat”? Może się wtedy zdarzyć, że ktoś kto spełnił wszystkie wymagania dostał awans, ale jego ogólna postawa w pracy nie prezentuje tego poziomu stanowiska.

Podobnie jest w przypadku awansów na podstawie lat doświadczenia. Czasem osoba z trzyletnim stażem pracy bardziej zasługuje na awans, niż pracownik z ośmioletnim doświadczeniem, który nie ma predyspozycji na stanowisko seniora. Potrzebna jest rozsądna weryfikacja przez przełożonych na wielu poziomach. Przez to zawsze będzie różnica w postrzeganiu tych stopni pomiędzy każdą firmą, a często nawet w obrębie jednej firmy drabinka awansów w różnych działach może wyglądać zupełnie inaczej.

Sławomir Grabowski, Inżynier oprogramowania w Quick Turn Studio:

Określenia są te same, bo to są tylko nazwy: junior, regular (albo mid), senior, expert, elder master of development, ale nic nie wnoszą i są zazwyczaj bezużyteczne, a czasami nawet przeszkadzają. W korporacjach służą jedynie do określania widełek płac jakimi dysponują menedżerowie. Do niczego więcej.

Mogę mieć tzw. seniora z dziesięcioletnim doświadczeniem zawodowym, ale jeśli nie zna danej technologii wymaganej do stworzenia produktu to wezmę dwuletniego „juniora”, który pisał w danej technologii te dwa lata i jeszcze może po godzinach w czasie studiów, więc po co te określenia?

Obrazuje to nie tylko, że w jednej firmie mogę być seniorem a w innej nie załapię się nawet na regulara, ale nawet w ramach różnych projektów w tej samej organizacji. Oczywiście jak ktoś ogarnia trzy języki programowania to z łatwością nauczy się kolejnego, więc nie ma co go skreślać, że technologii nie zna, ale to, że łatwo się adaptuje do nowych technologii nie opisuje przedrostek „senior” w elektronicznym systemie ewidencji pracowników tylko renoma osoby w danej firmie. Nigdy nie spotkałem się z sytuacją, gdzie menedżer wyszukując kandydatów do projektu użył w systemie filtra senior. Zazwyczaj leci ogłoszenie w wewnętrznej komunikacji „Cześć kto zna technologię X? Mamy projekt na tapecie”.

Rafał Jaworowski, Senior Full Stack Developer Hitachi ABB PowerGrids:

Tak, możesz mieć rok doświadczenia i na papierze stanowisko seniora. Jak również możesz być świetnym programistą z ośmioletnim stażem na papierze jako regular programista z umiejętnościami seniora. Prędzej czy później rynek zweryfikuje, gdzie jesteś naprawdę.

Sylwek Brzęczkowski, Technical Lead w Trust Stamp:

Tak są. Tak samo jak lata pracy, są to poziomy niezwykle nieprecyzyjne i podatne na szeroką interpretację, ale to zawsze jakaś informacja na temat tego, co kandydat myśli o sobie samym i jakiej płacy oczekuje. Wszystko wyjdzie na rozmowie.

7. Co w ofertach pracy przykuwa Waszą uwagę, a co sprawia, że nie aplikujecie na dane stanowisko?

Marcin Lasak, Senior frontend developer w Divante:

To już chyba indywidualna kwestia u każdego. Jakie wartości są dla niej/niego istotne. Kiedyś głównie zwracałem uwagę na to, żeby pracować w nowych technologiach. Nadal wybrałbym projekt na nowocześniejszym stacku, jeśli byłyby dwa identyczne projekty/zespoły, ale teraz ma dla mnie większe znaczenie odpowiedni balans wielu czynników w projekcie/firmie. Musi to być praca bez ciągłej presji czasowej (ciągłych nadgodzin, “pożarów” w projektach), z dobrym zespołem, utrzymując odpowiednią jakość projektu, rozwiązując ciekawe problemy i z dobrym, bezpośrednim kontaktem z klientem/użytkownikami. Takie oferty przykuwają uwagę, a jeśli widzę, że jakiś z tych aspektów jest mocno zaniedbany i taka ogólnie jest kultura w całej firmie to raczej unikam takich propozycji.

Sławomir Grabowski, Inżynier oprogramowania w Quick Turn Studio:

Pierwsze na co zwracam uwagę to widełki płacowe. Jeśli znacznie odbiegają od moich wymagań no to nie aplikuję. Jeśli nieznacznie to aplikuję z pytaniem czy da się coś w tej sprawie zrobić. Jeśli tej informacji brak to szukam czegoś innego w ogłoszeniu co mnie zainteresuje. Drugie to firma, dla której docelowo miałbym pracować (bo ogłoszenie może wystawiać firma outsourcingowa). Jeśli opinia o tej firmie jest negatywna wśród znajomych nie aplikuję. Trzecie to branża.

Niechętnie aplikuję do banków i firm produkujących stacje bazowe ze względu na sposób prowadzenia projektów, który mi osobiście nie odpowiada. Czwarte to model biznesowy projektu. Jeśli wiem, że to jest body leasing to spodziewam się, że nie będę miał wpływu na wybór narzędzi i będę musiał często liczyć się z łamaniem podstawowych praktyk programowania, ale nie zawsze mnie to zniechęca do aplikowania, jest to po prostu minus. Kolejna rzecz to zwracam uwagę na niektóre technologie. Jeśli ktoś używa SVN, to zazwyczaj nie aplikuję, bo prawdopodobnie firma jest betonem i ma opór do zmian by wprowadzić Git. A skoro zmiany w tym obszarze nie potrafią dokonać to w innych obszarach może być tylko gorzej. To moje osobiste.

Natomiast takie, które również dla mnie, jak i grona moich kolegów i koleżanek są ważne to na przykład jak ogłoszenie jest napisane.

Co może zachęcić?

1. To czy wymieniono same konkrety takie jak technologia wraz z jej wersją/standardem, konkretne narzędzia, na jakich systemach można pracować. Zazwyczaj to zachęca, bo wypytywanie rekrutera, który zazwyczaj nie ma pojęcia, że C++ to słabe określenie i istnieje coś takiego jak C++98, który kolosalnie różni się od C++11 i nowszych, nie udzieli mi szybko tej informacji. Natomiast gdy jest to napisane jeden problem mniej.
2. Zamienienie nagłówka na „Wymagania” na „Idealny kandydat ma/potrafi”. Lepiej się czujemy, gdy mamy świadomość, że nie we wszystkim musimy być „perfect”.
3. Jeśli w nagłówku „Mile widziane” / „Plusem będzie” znajdę obszar wiedzy, którym będę mógł się pochwalić.
4. Wspomnienie o elastycznych godzinach pracy i zakresie tzw. „core hours” jest moim zdaniem niemalże obowiązkowe.
5. Mile widziane jest jeśli w ogłoszeniu znajduje się opis projektu tj. ile osób w nim pracuje, na jakim jest etapie, co jest produktem.
6. Dobrym pomysłem jest danie rubryki lub pomysłu jak można lepiej się pochwalić swoimi umiejętnościami, np. „podaj swój profil GitHub”.

A co może zniechęcić?

1. Mnóstwo tekstu, lanie wody, kolorowanie szarej rzeczywistości przymiotnikami i epitetami typu „nowoczesny”, „technologia przyszłości”, „innowacyjny projekt” itd.
2. Najgorsze są bzdury typu: “zaletą projektu jest międzynarodowość”, gdzie każdy kto pracował w takim projekcie wie, że różnice w strefach czasowych są najczęściej żadnym problemem wobec różnic międzykulturowych. Wtedy od razu mamy podejrzenia, że chyba projekt nie ma żadnych zalet, więc coś trzeba było napisać „a może się nabiorą”.

Rafał Jaworowski, Senior Full Stack Developer Hitachi ABB PowerGrids:

Brak pracy zdalnej, jquery, kiepska stawka i stare technologie. Bardzo nie lubię też Pythona, ale akurat biorę oferty z nim tylko takie, gdy ktoś chce się go pozbyć z projektu. Nie każdy bohater nosi pelerynę.

Sylwek Brzęczkowski, Technical Lead w Trust Stamp:

Już dawno nigdzie nie aplikowałem. Rynek rekrutacji mógł się trochę zmienić, ale myślę, że mogę coś jednak powiedzieć. Elementy, które przykuwają moją uwagę to z zachowaniem kolejności:

1. Czy jest to praca zdalna?
2. Odpowiednio wysoka płaca (a “widełki płacowe” to kolejna patologia, o której warto porozmawiać),
3. Lista technologii, które znam,
4. Branża (domena), która jest ciekawa (np. kosmos, medycyna, biometryka, branża filmowa), żebym mógł się czegoś o niej nauczyć,
5. Krótka notka o firmie, kiedy powstała, czym się zajmuje, jak zaczynała, jak jest teraz. Lubię małe firmy, bo mam wpływ na jej kształt i kierunek rozwoju.

Elementy, które mogą mnie zniechęcić, jeśli już powyższe wymagania są spełnione, bez zachowania kolejności:

1. Wymagana dostępność w strefie czasowej, która wymagała by ode mnie obecności na rozmowach bardzo późno wieczorem,
2. Konieczne częste delegacje (częściej niż 4 razy w roku),
3. Obecność w stacku technologii, z którą nie chciałbym pracować np. inna niż GIT kontrola wersji.

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z