fbpx
devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
10 minut

Jak rozwiązywać zadania rekrutacyjne?


08.09.2015

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

Nie przegap kolejnych postów!

Dołącz do ponad 9000 programistów w devstyle newsletter!

Tym samym wyrażasz zgodę na otrzymanie informacji marketingowych z devstyle.pl (doh...). Powered by ConvertKit
Notify of
trackback

Jak rozwiązywać zadania rekrutacyjne?

Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl

pawelek
pawelek

No rekrutacja u Was w firmie była naprawdę przyjemnością. Ostatnio mam porównanie Waszej rekrutacji z kilkoma korpo – u Was ogarnięte to było super. Dzięki z poswięcony czas :)

Co do powyższego zgadzam się i zdecydowanie i dodałbym:
http://www.joelonsoftware.com/articles/fog0000000043.html

Łukasz

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

Marcin Daczkowski

Ś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… Read more »

Janek
Janek

Przykład z życia wzięty(niewszyscy pracodawcy lubią pytania)
http://www.gumtree.pl/a-programisci-informatyka-i-internet/w%C5%82ochy/szukamy-programiste-ke-php-do-tworzenia-serwisow-online-dla-biznesu/1001414319440910780863909
“poszukujemy elastycznego programisty, który nie będzie zadawał zbędnych pytań: po co, na co, dlaczego, tylko wykonywał powierzone mu zadania i moduły.”

Na czym polegał task Roberta?

mała
mała

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… Read more »

Rafał

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… Read more »

trackback

[…] Jak rozwiązywać zadania rekrutacyjne? […]

Karol Marks
Karol Marks

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.

Programistka
Programistka

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 ;)

Moja książka

Facebook

Zobacz również