A więc chcesz zatrudnić programistę?! Ciekawe. Na tę okazję zamienię się w jasnowidza i przedstawię ci ogłoszenie, które w tym celu opublikujesz:
Do ugruntowanej na rynku firmy / dynamicznie rozwijającego się startapu poszukuje się programistów PHP / Ruby / Javascript / Scala / FORTRAN / HTML (sic!) tudzież tostera.
Wymagania:
- Umiejętność programowania w wersji 4.15.51
- Doskonała znajomość zupełnie niezwiązanej technologii mile widziana
- Znajomość tych oto trzech absolutnie wykluczających się narzędzi
- Jeszcze nie do końca wiemy co będziesz robił, więc na wszelki wypadek dobrze, żebyś umiał jeszcze posługiwać się photoshopem i niszczarką
- Nie mamy pojęcia jak szybko się uczysz i nie zdajemy sobie sprawy z tego, że różne środowiska inaczej wpływają na rozwój pracownika, więc dorzucamy wymóg 17 miesięcy doświadczenia na podobnie brzmiącym stanowisku (lub nie)
- Znajomość języka angielskiego umożliwiająca czytanie dokumentacji technicznej (seriously, jakiś człowiek kiedyś wymyślił to zdanie na kacu i wszyscy je przepisują)
Oferujemy:
- Pracę w młodym i dynamicznym zespole (hint: jeśli jesteś stary to cię nie przyjmiemy)
- Atrakcyjne wynagrodzenie, a przynajmniej więcej niż w biedronce
- Udział w innowacyjnych projektach — wiesz, wordpressy, joomle, cięcie mailingów i inna małpia robota
I o ile niezmiernie korci mnie teraz, żeby zrobić przekrojową parodię z publikowanych ogłoszeń o pracę — nie zrobię tego. Postaram się pisać merytoryczne.
Poniżej kilka wskazówek co umieścić w ogłoszeniu o pracę — a co pominąć — aby lepiej zrealizować swój cel, którym powinno być zachęcenie odpowiednich osób do kontaktu, a jednocześnie zniechęcenie ludzi, którzy do profilu nie pasują. Dla kontekstu — ja sam częściej zasiadałem na rekrutacjach po stronie pracodawcy, więc postaram się, żeby nie było to narzekanie rozpuszczonego pracownika, który chciałby więcej i lepiej, ale nie rozumie drugiej strony.
Napisz co robicie
Rozróżnijmy kilka podstawowych typów pracy oferowanej programistom, a potem pozwólmy sobie dostosować ich charakterystykę do naszych potrzeb:
Agencje reklamowe
Praca w agencji ma swoje charakterystyczne cechy które przyciągają lub odpychają konkretne typy programistów. Pomijając szczególne przypadki, taka praca zwykle (z punktu widzenia pracownika):
- Narzuca ścisłe deadline’y, na których polegać będzie cały łańcuszek osób, od klienta klienta, przez pośredników, po accountów, PM-ów i teamliderów w twojej firmie. I raczej ciężko będzie pracownikowi na nie wpłynąć, więc zaopatrz się w kocyk i poduszkę, bo czekają cię nocki w fabryce.
- Proces decyzyjny jest rozmyty i niejasny. Obrany kierunek nie zawsze jest logiczny i najbardziej efektywny — ale znów, zbyt dużo osób by przekonywać.
- Otaczający cię ludzie są jacyś tacy inni. Nie potrafią zrozumieć twoich tłumaczeń, że emacsem przez sendmail i cały czas proszą o estymację czasu projektów, które nie mają nawet jeszcze specyfikacji poza: „zróbcie mi fajną stronę”. To są tak zwani zwykli ludzie, którzy nie mieszkają w piwnicy i nie potrafią rozmawiać z komputerami. Interesują ich trochę inne rzeczy niż ciebie, więc może czekać cię ciężka przeprawa.
- Nikogo nie obchodzi technologia. Pamiętasz to spotkanie, na którym chciałeś przeznaczyć tydzień czasu na testy jednostkowe i dziwnie na ciebie patrzyli? Programowanie w agencji polega wyłącznie na tworzeniu długu technologicznego, którego nikt nigdy nie zamierza spłacać.
- Oczywiście jeśli nie jesteś alfą i omegą programowania będzie ci tu dobrze. Nikt nie będzie wymagał lepszego kodu, bardziej optymalnych funkcji — liczy się efekt, więc swobodnie prześlizgniesz się pod radarem.
- Wymagane są od ciebie za to dużo szersze umiejętności — lepsza komunikacja, teamwork, lepsze raportowanie i estymowanie czasu. Ale nie tylko miękkie skille — ciężej będzie się specjalizować, bo zwykle zadania będą od ciebie wymagać poznania nowego frameworka, czasami zupełnie nowego środowiska (cięcie mailingów anyone?), przeskoczenia z backendu do frontendu (i odwrotnie, hehe), itd.
Ogólnie praca agencyjna to walka o przetrwanie, w nieidealnym świecie, w którym brakuje zasobów. Uczy wielu rzeczy, rozwija charakter i nie pozwala siedzieć wygodnie na kanapie. Niektórzy się w tym odnajdują, inni od tego uciekają jak najdalej.
Zgodzę się, że oceniam niesprawiedliwie te większe i fajniejsze agencje. Tam prawdopodobnie działa to nieco lepiej, ale ogólny wydźwięk jest podobny.
Wszystko inne co nie jest agencją reklamową
Mógłbym się rozpisywać na ten temat, ale generalnie jest odwrotnie niż w agencjach.
- Terminy potrafią być luźniejsze i nawet od czasu do czasu ktoś pyta osoby faktycznie wykonujące tę pracę o zdanie.
- Jest szansa na analizę wymagań (technicznych) i specyfikację czy dokładny projekt zanim zacznie się kodować
- Ludzie pracujący nad produktem często mają background techniczny, wiec w najgorszym scenariuszu przynajmniej rozumieją trudne słowa, które do nich mówisz: repozytorium, backlog, sprint, refactoring, commitowanie, github, rwd (ok, nie trafiłem, to jest bardziej zwrot marketingowy), etc :)
Raz na jakiś czas będzie też szansa pochylić się nad jakością tworzonego kodu. Ktoś kiedyś podejmie odważną decyzję, żeby wyrzucić jakiś legacy kod i przepisać od nowa. Rzeczy o których programiści „agencyjni” słyszeli i nawet czasami śnią nocami, ale nigdy nie mieli okazji zobaczyć w praktyce.
Ten idealny programistyczny świat przesłania jedna podstawowa wada (z mojego punktu widzenia przynajmniej, YMMV): nuda. Załóż swoją flanelową koszulę i marsz do pracy. Nie przeżyjesz dzisiaj przygody. Nie, jutro też nie. Nie, refactor kodu to nie przygoda.
Software house (bonus)
Oczywiście istnieje pewna szara strefa. Software house’y są dobrym tego przykładem. Pracują dla zewnętrznych klientów, ale ich wartością jest dobra technologia, w tym dobry i czysty kod. Jest to więc niejako połączenie dwóch światów. Nie chcę powiedzieć, że to złoty środek, bo każdy ceni sobie inne wartości.
Podsumowując typy pracy
Napisz jasno o jakiego typu firmę chodzi. Osoba o silnym skillu programistycznym, dbająca o swój rozwój, raczej nie będzie zainteresowana pracą w agencji, gdzie jej umiejętności nie będą dobrze wykorzystywane. I odwrotnie — jeśli ktoś ma w sobie więcej sprytu i determinacji do siedzenia po nocach, nie ma sensu wrzucać go do otoczenia, które będzie oceniać go na podstawie znajomości kolejnego frameworka czy nowinki technologicznej.
Jedno proste zdanie przekaże wystarczająco dużo informacji, aby dokonać podstawowego odsiewu osób, które nie nadają się do tej pracy. Jeśli stanowisko jest niestandardowe — określ jego podstawowe cechy. Czy praca dotyczy jednego produktu (think: startup), czy wielu. Jeśli wielu, to jak duże są? Tygodniowe fuszki, czy duże systemy realizowane miesiącami? Realizowane na potrzeby wewnętrzne, czy dla klientów?
Zarobki
Zrzućmy ten temat z serca. Jestem silnym zwolennikiem publikowania widełek wynagrodzeń. To znów odsiewa masę niedopasowanych kandydatów. Nawet jeśli czyjeś wymagania są nieco wyższe, niż publikowane widełki to i tak przyjdzie na rozmowę negocjować. Oczywiście kosztem przewagi negocjacyjnej pracodawcy podczas rozmowy o zarobkach, ale jeśli planujesz wykiwać swojego nowego pracownika jeszcze zanim podpiszesz z nim umowę, to nie mam zamiaru pomagać ci w rekrutacji.
Budowanie dłuższej relacji z pracownikiem i tak będzie wymagało ujawnienia poziomu zarobków w firmie. Niedopłacany pracownik zorientuje się w swojej sytuacji i poprosi o wyrównanie. Można więc oszczędzić sobie tych podchodów i postawić na większą transparentność i zaufanie.
Warto też nie ściemniać: 2-8k netto to nie widełki. To niezdecydowanie albo obejście procedur. Albo szukamy juniora bez doświadczenia, albo kogoś kto coś potrafi i wniesie konkretną wartość do firmy. Lepiej podzielić to na dwa ogłoszenia, z których każde lepiej trafi do swoich odbiorców.
Niskie widełki warto nadrobić otoczką. „Miłą” atmosferą, możliwością rozwoju (fajnie, żeby to nie był tylko slogan i faktycznie jakiś mentoring młodych miał miejsce), luźniejszym podejściem do terminów, etc. Z kolei wysokie widełki przyciągają talent.
Chciałbym zasugerować podawanie kwot brutto, które są bardziej naturalne dla pracodawcy i bardziej miarodajne w kontekście różnych form zatrudnienia, ale mogą być zupełnie niezrozumiałe dla kandydatów. Lepiej więc napisać o kwocie netto, ale sprecyzować o jaki typ umowy chodzi. Osoba prowadząca działalność nie powinna mieć problemów z przeszacowaniem kwoty UoP/UoD na fakturę, ale w drugą stronę to nie działa — ktoś, kto nigdy nie interesował się tematem nie będzie w stanie przeliczyć ile faktycznie zostanie mu na rękę — będzie się tylko cieszył, że kwoty są jakieś takie wysokie.
Umiejętności i technologia
Zaczyna nam się pojawiać sporo rzeczy, których nie ma w tradycyjnych ogłoszeniach, a trzeba je gdzieś zmieścić. Na szczęście mamy rozdmuchaną sekcję wymagań, która nie przekazuje za wiele informacji. Zobaczmy dlaczego:
Główny język programowania
Ja jestem w stanie opierać się na tym, co dzieje się w kwestii PHP. Możliwe, że inne języki mają inną specyfikę, ale popatrzmy na to z tej strony: czy wymienienie wersji PHP-a jest istotne? Ok, zaznaczenie, że pracujemy w PHP 5.5/5.6 (czyli aktualnym) może przyciągnąć dobrych kandydatów (świadczy o braku długu technologicznego), ale czy musi być wymagane? Raczej nie ma różnic pomiędzy PHP 5.3 a 5.6, których programista nie będzie w stanie przyswoić pierwszego dnia wprowadzenia.
Nie mówiąc już o ogłoszeniach, które wymagają znajomości PHP5, tak jakby ktoś przewidywał lawiny kandydatów, którzy zatrzymali się w latach 90-tych na PHP4. Świetnie. Zaznaczcie jeszcze, że znajomość COBOL niewymagana, ale mile widziana. I kart dziurkowanych.
Wystarczy wymienić nazwę języka (o ile nie ma naprawdę rozłącznych wersji, jak np. python 2 & 3). I tak kandydat nie będzie znał go w stu procentach, i tak będzie musiał się go douczać na co dzień.
Pomocniczy (dopełniający) język programowania
„Programista PHP ze znajomością Javy”. „Szukamy osoby ze znajomością Pythona, Javascript mile widziany”. „RoR developer wanted, .NET experience welcome” — czy to nie brzmi słodko?
W przypadku PHP + JS (mile widziane) akurat dla mnie to jest jasny sygnał: mamy team backendowców, ale szukamy frajera, który będzie klepał jQuery za każdego. Not fun.
Więc takie rozdrabnianie się bardziej odstrasza albo pokazuje niezdecydowanie pracodawcy. Chyba, że faktycznie potrzebny jest rock star — wtedy warto napisać to wprost — programista będzie odpowiedzialny zarówno za backend, jak i frontend, jak i cięcie do HTML-a, projektowanie funkcjonalności tam czy owam, no i będzie musiał naklikać też skrypty monitorujące w bashu… Aha, zapomniałem, właściwie to szukamy CTO więc tak naprawdę chodzi tylko o zarządzanie ludźmi, którzy będą to potrafić. ;) Make up your mind!
Frameworki i narzędzia
Są dwie opcje: albo pracujecie w jednym frameworku i oczekujecie programisty, który nie będzie musiał przekraczać dodatkowej bariery wejścia, albo oczekujecie ogólnej znajomości konceptów MVC. Jeśli ogłoszenie mówi o znajomości „jednego z popularnych frameworków” to nie wiem co o tym myśleć — bo przecież to nie znaczy, że w pracy będę mógł potem używać dowolnego z nich. A jeśli nawet mam taką dowolność, to czemu w ogóle musiałbym korzystać z „jednego ze znanych”? Czy nie wystarczyłoby, że równie efektywny będę bez fraweworka albo na własnej architekturze?
„Znajomość obiektówki” to również znak bezmyślnego przepisywania ogłoszeń. Czy naprawdę ktoś oczekuje programistów, którzy nie znają OOP? A nawet jeśli nie znają, to nie wkują dwóch zdań z Wikipedii na ten temat i czterech wzorców projektowych na krzyż (i będą liczyć na to, że jakoś z tym przejdą przez rozmowę rekrutacyjną)?
Istnieją bardziej kompromitujące zestawienia, jak np. wymienianie wszystkich wersji HTML-a, XHTML-a i dodanie XML-a na dokładkę. Musiałbym się naprawdę postarać, żeby umieć jedno, a nie drugie. Warto też pominąć technologie i narzędzia, które są… Proste. I można się ich nauczyć w tydzień, jak np. systemy kontroli wersji. Znów — warto zaznaczyć, że mindset w firmie jest taki, że raczej git niż SVN, ale żeby umiejętność klikania guzika „commit” w IDE wpisywać do ogłoszenia o pracę — marnowanie miejsca.
Zastanów się, co naprawdę jest istotne w tej pracy. Tak samo jak pisząc CV lepiej skupić się na mocnych stronach zamiast lać wodę (ukończony kurs MS Word w liceum), w ogłoszeniu lepiej też wymienić tylko te atrybuty, które są kluczowe. Reszta albo będzie naturalnie wynikała z opisu stanowiska, albo będzie do wyuczenia w pierwszym tygodniu pracy. Dla mnie lepszym podejściem jest wymienienie tych wszystkich buzzwordów i technologii w ramach opisu produktu / stanowiska pracy, niż w formie wymagań od kandydata.
Atmosfera pracy
Oczywiście „przyjazna”, ale tak naprawdę to jest miejsce, w którym można się pochwalić czym firma się wyróżnia. Opowiedz o turnieju FIFA na xboxa, który organizujecie. Wymień dodatkowe benefity poza pensją. Wspomnij o wyjazdach integracyjnych (i obowiązkowo zamieść głupi filmik pokazujący pracowników). Zabłyśnij konkretami i wyróżnij się wśród konkurencji. No, chyba że nie masz czym, wtedy najpierw nad tym popracuj.
Oczywiście to nadal może być za mało, żeby się wyróżnić. Postaraj się bardziej zaangażować kandydata pokazując mu w jaki sposób odbywa się praca. Czy używacie metodologii do prowadzenia projektów, czy każdy ma wolną rękę. Kim są ludzie, z którymi przyjdzie programiście pracować. Pochwal się ich wkładem w open source. Napisz o rozliczaniu z efektu, a nie godzin spędzonych przy biurku. Zachęć pracą zdalną, jeśli to wchodzi w grę. No ale przede wszystkim sam staraj się zbudować ciekawą kulturę pracy i zaproś do niej kandydatów.
Rynek pracy programistów jest zatłoczony i ciężki dla pracodawcy. Ja nie mogę przestać się dziwić, że pomimo to nadal publikowane są tak miałkie ogłoszenia, które nie wyróżniają się niczym na tle konkurencji. Zaznacz swoje wartości. Wybierz z tłumu kandydatów, którzy myślą podobnie do ciebie i dążą w podobny sposób do wspólnego celu.
Staraj się też dobrze wyrazić kogo szukasz. High performera, rock stara, który zrobi raz na miesiąc rzecz niemożliwą, a potem pojedzie na Kanary się regenerować, czy żołnierza, coding monkey o stałej, przewidywalnej wydajności?
TL;DR;
Ogłoszenia kierowane do programistów muszą się wyróżniać. Przemyśl każdy kawałek sztampowej oferty i zastanów się co naprawdę wnosi, czy jest potrzebny i jak można go obrócić w coś ciekawszego. Nie bój się pisać o szczegółach dotyczących pracy, firmy i stanowiska. Nie kompromituj się wstawiając nierealne lub głupie wymagania technologiczne. Finalnie: włóż w to trochę serca.
