We wpisie o procesie rekrutacji programisty wspomniałem o zadaniach rekrutacyjnych, które część firm stosuje jeszcze przed zaproszeniem kandydata na rozmowę. Spotkałem się z dwoma typami takich zadań:
- automatycznie oceniane zadania algorytmiczne
- projekty sprawdzane przez programistów w firmie
Omówię w tym wpisie jak ogólnie mogą wyglądać te dwa typy zadań i przedstawię kilka rad bazujących na moim doświadczeniu.
🚗💨
Jeśli się spieszysz to tutaj znajdziesz podsumowanie tego wpisu.
Automatycznie oceniane zadania algorytmiczne
Celem tych zadań jest głównie przefiltrowanie kandydatów przy niewielkim nakładzie czasu. Automatyzacja pozwala błyskawicznie odrzucić osoby, które nie spełniają wstępnych wymagań bez angażowania programistów z firmy. Dlatego są zazwyczaj pierwszym lub drugim etapem rekrutacji.
Zadania tego typu to krótkie problemy algorytmiczne do rozwiązania przy zadanych ograniczeniach. Jeżeli firma chce sprawdzić Twoją znajomość konkretnego języka, to tylko on będzie dostępny, ale często możesz wybrać technologię. Najpopularniejszymi znanymi mi platformami z takimi zaaniami jest Codility i HackerRank.
Charakterystycznymi cechami takich zadań są ograniczenie czasowe i automatyczna ocena. Rozwiązanie problemu zazwyczaj mieści się w ramach jednej funkcji, która ma zdefiniowane dane wejściowe. Platforma sama sprawdza poprawność rozwiązania dla prostszych i bardziej skomplikowanych przypadków, może także ocenić pamięciową i czasową złożoność obliczeniową.
Projekty sprawdzane przez programistów w firmie
Tego typu zadania mogą pojawić się na różnych etapach rekrutacji. Wymagania w nich są bardziej złożone, niż przy zadaniach algorytmicznych. Są to już małe projekty, składające się z kilku elementów. Kandydat ma zazwyczaj więcej czasu na wykonanie takiego zadania. Dostawałem zadania do zrobienia w tydzień, ale też zdarzył się projekt biblioteki, na który miałem dwie godziny od otrzymania opisu.
Z takimi zadaniami spotykałem się o wiele rzadziej jako kandydat. Jako rekruter zobaczyłem ile energii i czasu wymaga przygotowanie ich, a potem sprawdzenie rozwiązania każdej osoby. Spodziewam się więc, że pracochłonność jest jednym z powodów, dlaczego wiele firm pozostaje tylko przy zadaniach z platform.
Zaletą robienia małych projektów w ramach rekrutacji jest możliwość pokazania czegoś więcej niż tylko algorytmiki. Rekruterzy mogą zobaczyć jak podchodzisz zarówno do wymagań biznesowych, jak i do architektury aplikacji. Czysty kod ma tutaj o wiele większe znaczenie, niż przy implementowaniu quicksorta.
Zdarzyło mi się, że pierwszym etapem było zadanie na Codility, a kolejnym był mały projekt. Zostałem więc zaproszony na rozmowę dopiero po wstępnym sprawdzeniu mojej algorytmiki i podejścia do tworzenia projektów od zera.
Praktyczne rady
Część tych rad odnosi się tylko do zadań z platform rekrutacyjnych, ale pozostałe polecam stosować w każdym przypadku. U mnie bardzo dobrze się sprawdziły.
Poznaj platformę
Znane mi platformy mają zadania treningowe. Przerobienie ich pozwoli Ci oswoić się z interfejsem i poznać ograniczenia, jak dostępne wersje języka i bibliotek. Unikniesz dzięki temu stresu i frustracji z pisania z wykorzystaniem nowości w języku tylko po to, by przy próbie uruchomienia przekonać się, że na platformie jest wersja sprzed trzech lat.
Poznasz też typ zadań, jakie najczęściej się tam pojawiają i dowiesz się, co jest brane pod uwagę przy automatycznej ocenie. Pamiętaj jednak, żeby zachować czujność, bo Twoje zadanie rekrutacyjne najprawdopodobniej będzie bardziej złożone od tych treningowych. Możesz też mieć mniej czasu na rozwiązanie go.
Pisz we własnym edytorze
Platformy rekrutacyjne mają zazwyczaj wbudowany w stronę edytor. Pisanie w znanym Ci środowisku może jednak dać Ci więcej spokoju. Masz wtedy możliwość przygotowania sobie wcześniej szablonu testów do wypełnienia w trakcie rozwiązywania zadania, by móc błyskawicznie sprawdzać poprawność algorytmu. Możesz pisać kod lokalnie i co jakiś czas wklejać go w okno edytora online.
Przy pracy na własnym edytorze weź pod uwagę poznane wcześniej ograniczenia platformy. Zdarzyło mi się nie przestawić wersji języka dozwolonej w edytorze na starszą i korzystać z najnowszych możliwości. Próba uruchomienia tego na platformie była dla mnie stresująca i musiałem szybko zastępować nowinki alternatywami dostępnymi w starszej wersji języka.
Posiadając kopię kodu na swoim komputerze możesz przyjrzeć się mu na spokojnie po wysłaniu rozwiązania. Jeżeli Cię odrzucą bez podania uzasadnienia, to możesz z pomocą kogoś bardziej doświadczonego przeanalizować, co dokładnie mogło być nie tak. Znajdując fragmenty do poprawy i ucząc się, jak je zmienić dajesz sobie możliwość osiągnięcia lepszego wyniku w przyszłości.
Pisz testy
Dobrze napisane testy automatyczne pomogą Ci z większym spokojem rozwijać swoje rozwiązanie. Przy każdej zmianie w kodzie dostaniesz jednoznaczną informację, czy zepsuło się coś, co wcześniej działało. Testy będą też dla Ciebie listą aktualnie obsłużonych przypadków i inspiracją do sprawdzenia kolejnych.
W opisie zadań algorytmicznych zazwyczaj jest przedstawionych kilka przykładów z danymi wejściowymi i oczekiwanymi wynikami. Platformy rekrutacyjne często automatycznie uruchamiają testy dla tych danych, ale są to zazwyczaj bardzo proste przypadki. Dlatego zastanów się nad różnymi skrajnymi możliwościami i przygotuj własne testy dla nich.
Przy zadaniach, które są projektami ocenianymi przez programistów testy będą Twoim dodatkowym atutem. Jasno pokażą jakie przypadki bierzesz pod uwagę pisząc kod i pozwolą Ci się wyróżnić. Bo kto normalny pisze testy na rekrutacji, jeśli nie jest to wymagane? Mi się zdarzyło i zrobiłem na rekruterach wrażenie.
Korzystaj z gita
Pisanie lokalnie daje Ci możliwość korzystania z gita. Może się wydawać, że nie ma czasu na wrzucanie kodu do repozytorium, ale może to dodatkowo zwiększyć Twój spokój. Jeżeli zepsujesz coś w kodzie, to docenisz możliwość błyskawicznego powrotu do poprzedniej wersji.
Po wysłaniu rozwiązania możesz przejrzeć nie tylko ostateczną wersję, ale też historię zmian. Możesz zauważyć tam niepotrzebne kroki, które Cię spowolniły i nauczyć się unikać ich w przyszłości.
Dzięki korzystaniu z gita możesz też w razie problemów z platformą przesłać kod inną drogą. Możesz przesłać link do repozytorium z rozwiązaniem albo stworzyć paczkę do wysłania przy użyciu git bundle. Pokażesz przy okazji, jak pracujesz z systemem kontroli wersji, co może być dodatkowym atutem.
Walcz do końca
Jeżeli po wysłaniu rozwiązania dotrze do Ciebie, że w Twoim kodzie jest błąd, to działaj. Natychmiast. Skontaktuj się z osobą, która wysłała Ci zadanie. Napisz, że wiesz, że kod ma wadę i masz poprawne rozwiązanie. I w tym momencie opłacalne okaże się pisanie kodu lokalnie i korzystanie z gita.
Niepokoi Cię, jak rekruter zareaguje na taką wiadomość? Spójrz na to z drugiej strony – co masz do stracenia? Jeśli przez ten błąd Twoje zadanie zostanie nisko ocenione, to najpewniej nie przejdziesz do kolejnego etapu. Dając znać, że widzisz po czasie swój błąd, możesz sprawić, że ktoś przyjrzy się Twojemu rozwiązaniu. I to bez względu na ewentualną niską automatyczną ocenę. Pokażesz się przy okazji jako ktoś, kto jest w stanie przyznać się do błędu i walczy do końca. Sam to zastosowałem i zadziałało.
Zadania rekrutacyjne a rzeczywistość pracy
Z moich doświadczeń podobieństwo pomiędzy zadaniem rekrutacyjnym a zadaniami w pracy oscyluje gdzieś pomiędzy „niewielkie” a „żadne”. Mogą być firmy, w których rozwiązuje się podobne problemy jak te na rekrutacji, ale jeszcze takiej nie poznałem.
Możesz dopytać przed podejściem do zadania, czy reprezentuje ono jakoś to, co czeka Cię w pracy. Podejrzewam jednak, że w niewielu miejscach oczekuje się stworzenia idealnego, wydajnego rozwiązania w 30 minut. W przypadku algorytmów zakładam, że większość zespołów najpierw szuka gotowych rozwiązań, a potem dopiero tworzy własne. Twoja praca ma generować przychód dla firmy, a nie po prostu kolejne linijki kodu do utrzymania.
Jeżeli zdarzyło Ci się kiedyś zadanie, które odzwierciedlało późniejszą pracę, to daj proszę znać w komentarzu. Mam nadzieję, że nasza branża zacznie się kierować bardziej w tym kierunku i chętnie zobaczę oznaki zmieniającego się trendu.
Podsumowanie
Najczęstszą formą zadań rekrutacyjnych są automatycznie oceniane problemy algorytmiczne i małe projekty oceniane przez programistów. Te pierwsze pozwalają przefiltrować kandydatów przy nikłym zaangażowaniu programistów. Drugie z kolei mogą być bardzo czasochłonne dla pracowników, więc nie są stosowane tak często.
Żeby zwiększyć poczucie spokoju podczas rozwiązywania zadań rekrutacyjnych, polecam Ci:
- pisać kod lokalnie w znanym Ci edytorze
- pisać testy
- korzystać z gita
- walczyć do końca
Pisząc kod lokalnie i korzystając z gita możesz bardzo łatwo wrócić do działającej wersji, jeśli coś się zepsuje. Pisząc testy tworzysz sobie siatkę bezpieczeństwa i przy okazji wyróżniasz się na tle innych kandydatów. Te wszystkie elementy razem pozwolą Ci walczyć do końca i wysłać rekruterom poprawioną wersję swojego rozwiązania już po czasie.
Problemy poruszane w zadaniach rekrutacyjnych niewiele mają wspólnego z rzeczywistością pracy w danej firmie. Jest to po prostu pewien standardowy już sposób na odsiewanie kandydatów. Skomplikowana algorytmicznie rekrutacja może prowadzić do pracy nad utrzymaniem starego projektu.
Jeżeli jednak znasz firmę, gdzie zadania na rekrutacji i w pracy są powiązane, to napisz to proszę w komentarzu.
Rekrutacje przeprowadzane w Polsce to totalna porażka. Wszelkie zadania programistyczne, programowanie na żywo, pytania jak na stanowisko juniorskie to jest całkowity brak szacunku dla kandydata. Oczywiście mówię tu o poziomach od mid w górę. Najlepsze są wspomniane „Mini projekty”. Firma prosi cię o napisanie małego serwisu do wymiany walut. Nie odzywa się do ciebie, a po jakimś czasie widzisz swoje rozwiązanie na platformie tworzonej przez tę firmę.
Sam weryfikuję sporą ilość kandydatów. Na rozmowie technicznej pytania związane z samym kodem zadaję tylko w przypadku gdy dany projekt wykorzystuje nietypowe technologie. Najlepiej sprawdzają się pytania sytuacyjne – Jest specyfikacja A która jest zależna od B, jakie zaproponował byś rozwiązanie. Jeśli jest spory „legacy code” to daję przykłady kodu i proszę o propozycję refaktorki. Rozmowa przeważnie trwa ~20min. Nigdy mnie nie zawiodła, a jako lead czerpie z tego ogromne korzyści, bo mogę skupić się na rzeczach ważnych, konsultację z członkami zespołu to profesjonalne wspólne brainstormy, a rozwiązania które dostarczamy dzięki tak budowanemu zespołowi są wręcz przyjemne w utrzymaniu.
Jestem zdania że kod zawsze idzie doszlifować, ale umiejętność analizy i logicznego myślenia odwala 90% roboty w najbardziej skomplikowanych przypadkach.
Są oczywiście rzeczy o które pytam już na wstępie – KISS, SOLID, WET/DRY. Wydaje mi się, że to taki fundament.
Wszelkim mini projektom, platformom do kodzenia na żywo, mówię grzecznie „Nie, dziękuję”. Potrzebujecie profesjonalisty to szukajcie profesjonalisty.
Podoba mi się Twoje podejście – też uważam, że logiczne myślenie i analiza są bardzo ważne i im warto poświęcić więcej czasu na rekrutacji. Mam nadzieję, że coraz więcej osób z takim podejściem będzie decydować o wyglądzie procesu rekrutacyjnego.
Ile rozmów rekrutacyjnych średnio prowadzisz, kiedy potrzebujesz jednego człowieka do zespołu?
Kwestia pojawienia się Twojego „projektu rekrutacyjnego” gdzieś w firmie jako używane rozwiązanie to ciekawy temat. Słyszałem podobne podejrzenia kilka razy wobec różnych firm, ale sam nie mam potwierdzenia, czy któraś firma to zrobiła. Czy podany przez Ciebie przykład to znana Ci sytuacja, czy ogólne stwierdzenie?
Fajnie, że poruszyłeś temat szacunku do kandydata. Jest kilka firm, które wywarły na mnie bardzo pozytywne wrażenie podczas rekrutacji dzięki odpowiednim pytaniom. Kiedy rekrutowałem się na seniora, to w tych firmach nie zadawali mi „juniorskich” pytań, tylko poświęcaliśmy czas na architekturę albo, tak jak wspomniałeś, na temat pracy z legacy code.
Co do zadań rekrutacyjnych i programowania na żywo na rekrutacjach w Polsce, to z tego co widzę to jest to ogólnoświatowy „standard”. Sam pierwsze zadanie na Codility rozwiązywałem dla firmy z Belfastu, a na rozmowie w innej firmie w Dublinie pisałem kod na tablicy, kiedy rekruter siedział sobie na kanapie. W newsletterze w tym tygodniu polecą linki związane m.in. z tym tematem.
Uczestniczyłem w wielu rekrutacjach. Chyba najgorsze sytuacje są wtedy kiedy firma szanuje tylko swój czas a nie kandydata. A przecież po drugiej stronie to też obciążenie i czas także jest ważny. Ile razy zdarzyło mi się przejść rekrutację, rozmowy telefoniczne, dojeżdżanie do siedziby firmy nawet dwu-trzy krotne na różne etapy, żeby na końcu usłyszeć że dobrze wypadłem ale nie mogą tyle mi zaoferować. No to po co był ten proces? Wydaje mi się że niektóre firmy liczą że jak poświęcisz tyle czasu to łatwiej będzie Ci przystać na gorsze warunki.
Druga sprawa to projekty. Czasami zadania są obszerne i jeśli chcemy oddać fajny czysty przetestowany kod to musimy poświęcić 3-6 dni czasu po pracy żeby wysłać zadanie rekrutacyjne. Kiedyś głupi robiłem to, teraz tylko od razu skreślam taką firmę.
Wszędzie słyszę tylko o tym jak potrzeba programistów, jak brakuje ich na rynku i dostaję tuziny propozycji na linkedinie, ale jak przychodzi do rekrutacji trzeba przechodzić durne procesy i poświęcać 1-3 miesiące, no i dodatkowo się przygotować do rozmów. Bo możesz być super w swojej pracy ale nie pamiętać formułek teorii o które spytają na rozmowie. To samo się tyczy zadań algorytmicznych ile osób potem w pracy robi coś algorytmicznego? Większość to klepanie podobnych stronek/systemów, ale zrobili łapankę na programistę do do przeprowadzenia rozmowy, wygooglowali pytania rekrutacyjne i bez zastanowienia pytają o to.
Kwestia poruszania tematu pieniędzy dopiero po kilku etapach jest fascynującym zjawiskiem. Sam kiedyś zacząłem na oferty na LinkedIn odpowiadać od razu z informacją o minimalnym wynagrodzeniu, jakie biorę pod uwagę. Sporo rozmów na tym się zaczęło kończyć, więc zaoszczędziłem trochę czasu i sobie i rekruterom.
Jak by wyglądał idealny Twoim zdaniem proces rekrutacyjny?