Jak rozwiązywać zadania rekrutacyjne?

Myślisz, że zapotrzebowanie na programistów jest teraz tak wielkie, że możesz rozwiązać zadanie rekrutacyjne w dowolny sposób a i tak każda robota jest twoja? NIE! Sposób rozwiązania (lub nawet nierozwiązania) zadania bardzo wiele o Tobie mówi. Czytaj dalej aby dowiedzieć się, na co zwracać szczególną uwagę. Bo – uwierz mi – nawet w naszej branży “zła sława” może mocno zaszkodzić przyszłej karierze.

Na początku tego roku szukaliśmy w Ultrico nowych ludzi do zespołu. Wychodzimy z założenia, że żaden “test wyboru” ani żadna rozmowa kwalifikacyjna nie pozwala na sprawdzenie kandydata tak dobrze, jak niebanalny problem do rozwiązania/zaimplementowania. Powinien być on choć trochę zbliżony do zadań, jakie na co dzień wykonuje się w firmie. Robert wymyślił więc interesujący task, poszło ogłoszenie kilkoma kanałami i otrzymaliśmy nawet sporo zgłoszeń. Efektem: powiększyliśmy zespół o solidne, ponadprzeciętne osoby (ale wazelina, nie? ;) ). Mission accomplished!

Ale…

Anegdotka

Zanim przejdziemy do rzeczy: krótka historyjka.

Za czasów uczelnianych studiowałem przez rok w Danii (fajne miasteczko Odense, program Sokrates-Erasmus). Kompletną nowością był dla mnie jeden przedmiot, na zaliczenie którego dobieraliśmy się w międzynarodowe zespoły i mieliśmy po prostu… napisać razem działający program. Plusem było znalezienie lokalnej firmy, która ten system u nas “zamówi” i go “zaakceptuje” oraz będzie chciała używać – jednak nie był to wymóg. W pierwszym semestrze nasz ośmioosobowy polsko-chińsko-rumuński zespół zdecydował się na napisanie portaliku internetowego dla studentów z wymiany wraz z forum dyskusyjnym. Nawet nieźle, jak na tamte czasy, się nam to udało. Ale to nie efekt naszej web-pracy spowodował opad szczęk komisji podczas zaliczenia. Bo egzamin wyglądał tak:

Prawie cały zespół zaprezentował rozwiązanie, poklikaliśmy po stronce, pokazaliśmy forum. Ale jedna osoba stała ciągle z boku. Najpierw demo, później pytania, wyjaśnienia i odpowiedzi, a złowrogi Rumun – ani słowa. Na koniec komisja pyta go: dlaczego nie bierzesz udziału w demo? Jaki był twój wkład w pracę zespołu? A odpowiedź zmiażdżyła wszystkich, łącznie z nami:

Ja napisałem niezależny komponent. Jest to program w C++, który po zainstalowaniu powoduje blokowanie “autorun” płyt CD po włożeniu ich do czytnika. To bardzo potrzebne narzędzie, ponieważ w ten sposób często instalują się wirusy. Napisałem to, ponieważ nie umiem programować www, ale umiem inne rzeczy.

Co Wy na to? Domyślacie się, jaki związek ma ta opowieść z tematem niniejszego posta?

Dostarcz oczekiwany rezultat

Ubiegając się o stanowisko w firmie niezadającej bzdurnych pytań w stylu “jak najbardziej efektywnie połączyć dwa stringi w .NET” – jesteś na dobrej drodze. Po otrzymaniu zadania zachowaj się tak, jak byś się zachował na co dzień podczas pracy, za którą ktoś Ci płaci. Sam fakt aplikowania oznacza, że prawdopodobnie chciałbyś, aby rekrutacja zakończyła się pozytywnie. Wykaż zatem, że potrafisz czytać. I zaimplementować to co trzeba.

Proces rekrutacji sprawdza nie tylko umiejętności techniczne, ale również zdolność komunikacji. Czyli: zrozumienie cudzych oczekiwań oraz określenie swoich założeń i ewentualnych wątpliwości. Ma to szczególne znaczenie w przypadku pracy zdalnej, tak jak u nas, ale przecież nie tylko. Jak zachowasz się, nie mając 100% informacji koniecznych do wykonania zadania? Taki trick stosuję czasem prowadząc szkolenia: daję wybrakowane instrukcje i obserwuję co się dzieje. Mało kto prosi o więcej danych. My, programiści, mamy w zwyczaju w takim przypadku podejmować decyzje na własną rękę. I często są to decyzje ukryte w kodzie, niezakomunikowane, a niejednokrotnie: błędne. Załóż, że w zadaniu może celowo brakować pewnych informacji. Dopytuj, proś o szczegóły oraz kontekst, informuj o własnych założeniach i decyzjach. Dociekliwość nie oznacza, że jesteś głupi. Oznacza, że dogłębnie analizujesz problem. A to bardzo dobra, pożądana i nieczęsto spotykana cecha.

Mając wszystkie informacje wymagane do rozwiązania zadania – zrób to, o co zostałeś poproszony. Najprawdopodobniej będzie to napisanie kodu typu “logika”, realizującego pewne wymagania “biznesowe”. Na tym się skup. To koduj. Chcesz się pochwalić znajomością nowych/modnych trendów? Pewnie, zastosuj CQRS. Użyj bazy NoSQL. Dlaczego nie? Ale koniecznie odpowiedz jednocześnie na pytanie: dlaczego tak? Nie wrzucaj wszystkiego, co znajdziesz w najnowszym Technology Radar od ThoughtWorks. Pokażesz jedynie, że umiesz korzystać z Gugla. A to już tak sobie wygląda.

I istotna porada: jeżeli nie masz czasu na realizację zadania w 100%, to zrób tyle ile jesteś w stanie. A potem napisz co zrobiłeś a co zostało do zrobienia. Plus: jakie kroki podjąłbyś dalej, gdybyś miał na to czas. Dostarczenie kompletnego rozwiązania nie zawsze jest konieczne do kontynuowania rekrutacji. Nasze zadanie rekrutacyjne zajmowało niektórym osobom nawet 30 godzin. Nie każdy jest w stanie tyle wygospodarować – ja bym nie był. Ale to nie oznacza, że jesteś skreślony. Ponownie: komunikacja problemu (“nie jestem w stanie zrobić wszystkiego”) to bardzo ważna umiejętność. Jest jednak jedno “ale” (i to niestety nie indian pale): wysyłając jedynie część rozwiązania koniecznie zadbaj o to, żeby była to właściwa część. Zrób to, co najważniejsze, o co głównie chodzi w zadaniu. Niech “częściowe rozwiązanie” nie będzie kawałkiem generycznego kodu przerzuconym z innego projektu.

Nie dostarczaj zbędnych artefaktów

Napisałem wcześniej, aby dokumentować swoje decyzje. Na przykład “dlaczego w tym zadaniu zastosowałbym akurat RabbitMQ?”. Ale nie jest to jednoznaczne z copy/paste strony Rabbita chwalącej dlaczego są super! Podobnie z CQRS czy innymi ciekawostkami. Nie przeklejaj diagramów czy dokumentacji. Napisz dlaczego jakieś rozwiązanie sprawdzi się w kontekście tego konkretnego zadania! Jeżeli to co zamierzasz napisać można zastosować w odpowiedzi na każde dowolne zadanie rekrutacyjne – odpuść to sobie. Pamiętaj: ktoś (może nawet więcej niż jedna osoba) to później musi przeczytać.

Zanim napiszesz linijkę kodu, zastanów się, czy jest ona bezpośrednio powiązana z tym co faktycznie masz zaprezentować. Ja wiem, że być może w aktualnej pracy nie masz możliwości zaprogramowania czegoś fajnego, a jak już zacząłeś rozwiązywać ciekawe zadanie, to ciężko powiedzieć sobie “stop”. Ale znowu, pamiętaj: ktoś (może nawet więcej niż jedna osoba) to później musi przeczytać. To nie jest projekt “do zabawy” (o nich pisałem w poście “O pet projects“). Dlatego nie dłub własnej infrastruktury. Nie pisz swojego load balancera – chyba że zadaniem było napisanie load balancera. Nie pisz swojej biblioteki do komunikacji po kolejkach – chyba że zadaniem było napisanie biblioteki do komunikacji po kolejkach.

W skrócie: Nie pisz “programu w C++, który po zainstalowaniu powoduje blokowanie autorun”.

Dobrze jeśli zauważasz potrzebę takich rozwiązań. Podkreśl to, definiując odpowiedni interfejs. Ale nie dokładaj do niego kilkusetlinijkowej implementacji! Ewentualnie słownie zwróć uwagę, że “w tym miejscu przydałby się taki i taki rodzaj cache”. Ale, na Boga Swaroga i Sierotkę Marysię, nie każ osobom po drugiej stronie wnikać w szczegóły Twojej własnej implementacji tego cache. Jeżeli zaintrygujesz swoim podejściem to zostaniesz poproszony o uzupełnienie rozwiązania przykładową implementacją.

Pomyśl jak Ty w codziennej pracy postrzegałbyś programistę, który zamyka buga X i w komentarzu wpisuje “co prawda nadal nie działa, ale za to zrobiłem masę innych fajnych rzeczy”. Byłoby to cool? Ano chyba nie do końca, co nie? Raczej można by to zinterpretować jako “nie umiem tego co chcesz, ale umiem milion czegoś innego”.

Podsumowanie

Czytaj ze zrozumieniem. Lista oczekiwanych rezultatów zadania nie wzięła się znikąd. Zrób to, o co zostałeś poproszony. Nie dopowiadaj sam sobie “co jeszcze fajnie byłoby tutaj wykombinować” – to nie jest hobbystyczny projekt open source.

Pamiętaj o czasie.

Po pierwsze – o czasie swoim. Nie marnuj go, implementując to czego implementować nie musisz. Zadanie zawiera prawdopodobnie dokładne instrukcje na temat tego, co powinno znaleźć się w rozwiązaniu. Tego od Ciebie oczekują. Na tym się skup.

Po drugie – pamiętaj o czasie osób oceniających Twoje rozwiązanie. Szanuj ten czas. Czytanie tekstu zajmuje komuś życie – więc niech cały dostarczony tekst będzie wartościowy, bez generycznych wstawek skopiowanych z netu. Czytanie kodu również zajmuje komuś życie, nawet więcej niż tekstu – więc niech i kod będzie zwięzły, skupiony na tym, co istotne. Naprawdę, przebijanie się przez kilka definicji CQRS z rzędu może człowieka… zmęczyć.

Prawdą jest, że trudno znaleźć ludzi na rynku pracy. Zapotrzebowanie na programistów wielokrotnie przekracza naszą liczebność. Ale to nie jest wymówka. Nie można z tego powodu wszystkiego sobie olewać i zachowywać się jak primadonna. Bądź tym, którego firma CHCE, a nie MUSI zatrudnić! Nie stawaj się przykładem “arystokraty”.

A może Ty masz coś do dodania? Bez krępacji, wszyscy chętnie poznamy Twoje zdanie ;).

Powodzenia w rekrutacjach!

Zainteresowanych tematem rekrutacji zapraszam też na odcinek podcasta DevTalk: “O karierze programisty z Pawłem Zdziechem“.

A jeśli właśnie rozpoczynasz swoją przygodę w IT to pomocny może okazać się mój tekst sprzed lat: “Jak szukać pracy jako początkujący programista?“.