Jak rozwiązywać zadania rekrutacyjne?

18

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?“.


Jeśli spodobał Ci się ten post to jak najbardziej podziel się nim ze znajomymi (guziki do “szerowania” znajdziesz poniżej) ;). Dołącz do mnie na Facebooku czy Twitterze. Zachęcam również do subskrypcji newslettera, dzięki któremu żadna nowa treść Ci nie umknie!

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

18 Comments

  1. Pingback: dotnetomaniak.pl

  2. Zabrakło więcej anegdotek z życia wziętych plus wyjaśnienia co dalej stało się ze “złowrogim Rumunem” ;)

    • @Łukasz,
      Szklanka jest w połowie pusta? ;)
      Anegdotek z procesu rekrutacji nie zamieszczałem, nie jestem Ayende który się w tym lubuje. Dawałem “ogólne”, powtarzalne przykłady, i z feedbacku jaki dziś dostałem po publikacji posta wiem że jest to zjawisko nagminne.
      A Złowrogi Rumun Bogdan dostał papier ukończenia szkoły i wrócił do Rumunii pewnie, żeby pisać kolejne zajebiste toole w C++, nie interesowałem się zbytnio :).

  3. Świetnie, że napisałeś ten post!

    Sam od dłuższego czasu z uporem staram się stosować takie podejście do rekrutacji i to co piszesz pokrywa się w stanowczej większości z moimi doświadczeniami. To chyba jedyny sposób aby bez zbędnego stresu jeszcze przed “okresem próbnym” w miarę sprawdzić z kim ma się do czynienia. Niestety, tak jak piszesz, kandydaci *nie zadają pytań*. Mimo, że parę osób już w ten sposób zatrudniliśmy, czekam na pierwszą osobę, która zada jakiekolwiek pytanie (sic! a można by je mnożyć, nawet myślę, że przy odpowiednich pytaniach/dyskusji można by podarować kandydatowi kodowanie zadania :)

    Czasami ta metoda jest niezwykle skuteczna… w oszczędzaniu czasu – mieliśmy przypadek, że kandydat po otrzymaniu zadania przestaje się odzywać :). Druga sprawa to walor edukacyjny, w ramach oceny powstaje code review i taki feedback trafia do kandydata. Dzięki temu jest a) punkt zaczepienia do tego, co można poprawić (albo do dyskusji z reviewerem!) b) względna jasność czemu rekrutacja skończyła się tak a nie inaczej.

    • @Janek,
      No niezły przykład :). “Masz tu coś do roboty i rób, jeśli coś jest niejasne to sam zrób jakieś założenie, będzie dobrze”.
      Task to w skrócie “napisz odpowiednik google calendar”, ale były podane dodatkowe warunki w jakich ma działać system oraz na co szczególnie zwracać uwagę. Dla mnie najciekawszym elementem, i tego od razu szukałem w rozwiązaniach, było jak kandydat podchodzi do rozwiązania problemu powtarzalnego w nieskończoność zdarzenia gdzie jedna jego instancja jest przesunięta o jeden dzień.

  4. Rany, ja żyję w jakiejś innej rzeczywistości. Mam za sobą jakieś kilkanaście rozmów i jeśli ktoś stosował chociaż test pisemny z zadaniami otwartymi, to już jest bogiem. Całkiem często zdarzał się wywiad z prostymi pytaniami, z których najczęściej powtarzanym było “co to jest interfejs?”. Był też pan, który stwierdził, że po takiej dobrej uczelni jestem, więc już mnie nie będzie sprawdzać. Raz mi sugerowano, że będzie jakieś zadanie napisania kodu w domu, ale chyba mój brak sprzeciwu wystarczył i się wycofali.

    @Janek
    Mnie się udało kiedyś opuścić firmę po kilku miesiącach, nie wiedząc, do czego właściwie miała służyć tworzona aplikacja (bo tam też “nie ukrywali, że mają dużo pracy” – tak dużo, że nie mieli czasu mi przekazać takich zbędnych informacji).

    A poza tym szacun dla Rumuna-hipstera.

    • @Mała,
      Ano to prawda, ssanie na ludzi jest tak duże że często rekrutacja to tylko “dzień dobry, ile chcesz na rękę? witamy!”. Ale wtedy można się domyślać na jakim poziomie jest zespół z którym przyjdzie pracować.
      A moje ulubione pytanie, miałem na większości rozmów: “jak najbardziej wydajnie połączyć bardzo wiele stringów?”. Ciekawe czy naprawdę tego StringBuildera tak na co dzień w każdym projekcie używają że to jest najważniejsza kwestia :) .

  5. Jedyne, co chciałbym dodać, to mój mały ‘trick’ podczas rozmów rekrutacyjnych… :). To jest coś obok tego koncentrowania się na rozwiązaniu problemu, które tutaj jest zaprezentowane i jest, oczywiście, podstawą do szanowania się nawzajem, łacznie z oceną, jak ktoś podchodzi do rozwiązania – jakiegokolwiek.
    Generalnie jeden z lepszych programistów opracował pewną klasę w C#, która zawiera kilka (dokładnie 7) błędów. Są to jednak błędy, które kompilator potrafi wychwycić podczas kompilacji i nie mają charakteru ukrytych błędów w samej logice – ale, jak by powiedział Yoda – ‘one bardzo trudne są’…
    I… nie zamierzam nawet koncentrować się na znalezieniu błędów przez aspirujących na dane stanowisko. Prawdę powiedziawszy znalazło się ze 2-3 osoby, które wskazały pewne błędy, jednak kończyło się to zwykle na 2 ‘na pewno’ i z jednym ‘jeszcze tutaj może być jakiś problem’.
    To, co mnie interesuje, to jak przyjmują oni moje wyjaśnienie tych błędów. Ja je omawiam, po kolei. Konkretnie, albo mamy ‘potakiwacza’ albo rzeczywiście ktoś to rozumie i dopowie coś w tym temacie, jakoś sensownie zareaguje. Spróbujcie – z łatwością zaobserwujecie, kto potrafi nawiązać w jakikolwiek szczególe do tematu, a kto po prostu powtarza po tobie i powie chyba każda głupotę, jaką mu ‘sprzedacie’. To mi jednak pomaga – widzę kogoś, kto poważnie programuje i kogoś, kto tylko symuluje swoje umiejętności…
    I ostatnie… niestety jest gorzej z tym czasem… Jeśli ktoś przejdzie jakoś przez to sitko rekrutacyjne a nie rokuje na stanowisko, to prędzej czy później (zwykle okres 1-2 tygodnia obecnie mi wystarcza – kiedyś broniłem się przed rozstaniem z ‘programistami’ i kilka miesięcy inwestując w nich swój czas) przyjdzie moment rozstania i tylko właśnie tego czasu szkoda. A niesmak, pomimo wielu wewnętrznych tłumaczeń sobie, że tak musi być, pozostaje. Gorzka lekcja, jeśli źle odrobiona.

    • @Rafał,
      Dzięki za komentarz, bardzo ciekawe podejście. Masz rację, nic nie sprawdza kandydata tak jak dyskusja na sensowny, a nie wyimaginowany, problem. Mi zawsze się podoba gdy ktoś wyraża swoje zdanie sprzeczne z rozmówcą, nawet jeśli finalnie okazuje się ono błędne. “Think for yourself, question authority” :).

  6. Pingback: 10 najlepszych postów - "the best of Procent" | Maciej Aniserowicz

  7. Karol Marks on

    Kazdy medal ma dwie strony. Wy chcecie dobrego developera i dajecie mu nietrywialny projekt.
    I on ma w swoim czasie zapierniczac nad nim po to aby dostac sie do Waszej firmy .
    Tyle ze to ze zostanie on zatrudniony to jest wartosc tez dla was. Przez to ze za darmo poswieca swoj czas sprawia wy macie wieksza pewnosc ze sie nada. Jest to bardzo jednostronne i naprawde nie wiem czy jest sie czym chwalic.

    • KAROL MARKS,
      Fajnie by było przeczytać jakąś propozycję alternatywnego podejścia. Zatrudniać każdego kto przyśle CV? Czy płacić za przystąpienie do rekrutacji? Czy chodzi Ci po prostu o to że rekrutacja powinna być prosta i zajmować max godzinę? Żadne z tych rozwiązań nie jest do zaakceptowania bo każde skutkowałoby zatrudnieniem niewłaściwych osób. Co byłoby bardzo niekorzystne i dla firmy i dla programistów. Chyba że jest jeszcze jakieś magiczne rozwiązanie?

  8. Programistka on

    Ja mam zupełnie inne doświadczenie ….
    Otóż idę sobie na romowę do teoretycznie szanującej się firmy, chłopaki w średnim wieku myśle, sobie, profesjonaliści.
    Siadam dostaję zadanie programistyczne, każdy ruch klawiatury widać na podczepionym do kompa telewizorze 50″ chcę rozpocząć development i co?
    I dostaję hasło, że w sumie to fajnie jakbym użyła przy tym wszystkim resharpera albo jakiś fajnych narzędzi :o
    Czyli nie zawsze chodzi o to co faktycznie trzeba zrobic a jednak o fajerwerki ;)

  9. Pingback: 23 - O programistach z Olą Pszczołą i Pawłem Michalakiem | DevTalk