Jako programista z dość długim stażem uczestniczę też w rekrutacjach. Moim zadaniem jest sprawdzenie wiedzy kandydatów pod kątem technologii. Ostatnio nasz klient kochany wymyślił, że będzie prowadzony live coding, jako element rozmowy końcowej. Sam proces jest kilkuetapowy, więc nie do końca wiem, co tam będzie się działo, no ale… nasz klient nasz pan.

Muszę się jakoś przygotować i stwierdziłem, że to dobry moment, żeby trochę wam opowiedzieć, po co robi sie live coding i jak zrobić go dobrze. Będzie też o narzędziach i alternatywach. I właśnie od alternatyw zaczniemy.

Zadanie domowe, remote task, show me your repo

Na początek trochę o alternatywach. Częstą praktyką jest dawanie kandydatowi zadania domowego, na którego wykonanie ma określony czas. Obiektywnie, nie są to duże zadania. Coś, co można zmieścić w dwa, góra trzy wieczory. Jednocześnie są na tyle rozbudowane, że możemy sprawdzić wiedzę kandydata na temat różnych narzędzi. W przeciwieństwie do live codingu możemy tutaj oczekiwać, że rozwiązanie będzie przemyślane, będzie zawierać testy i jakąś podstawową dokumentację. W takim zadaniu możemy też znacznie swobodniej narzucić ograniczenia dotyczące technologii. Przy tym podejściu musimy też założyć, że ktoś kod musi sprawdzić i nie powinien tego robić po godzinach pracy. Zatem metoda ta jest dość dobra z punktu widzenia potrzeb, ale może okazać się dość kosztowna. Kiedyś jeszcze wrócę do tematu zadań domowych.

Odmianą zadania domowego jest wysłanie kandydatowi testu na platformie w rodzaju DevSkillera. Łatwe, proste i przyjemne. Niezbyt drogie i całkiem wydajne. Jest to podejście „light”, ponieważ automatyzacja pozwala na „przerobienie” znacznie większej liczby kandydatów w krótszym czasie. Z drugiej strony nie każdy lubi tego typu testy. Nie każdy też jest dobry w takich testach. Ryzyko polega na potencjalnym odrzuceniu kogoś sensownego. Zyskiem są niskie koszty.

Zawsze można też pójść inną drogą. Jeżeli kandydat podał link do swojego repozytorium, to można przejrzeć jego ostatnie projekty i spróbować wyciągnąć wnioski. Pytanie, czy widząc takie repo, możemy coś powiedzieć o kandydacie:

image

No nie dużo. W dodatku taka metoda nadal jest dość kosztowna, bo ktoś do tego repo zajrzeć musi.

Live Coding – Idea

Pierwsze pytanie, które musimy sobie zadać, zanim wdrożymy LC do naszego procesu, brzmi – co chcę osiągnąć? Odpowiedź na to pytanie, która najczęściej pada, brzmi:

Chcemy sprawdzić umiejętności kandydata.

No tak ich nie sprawdzicie. Przynajmniej nie będzie to sprawdzenie dokładne. Do tego służą wymienione wyżej zadania domowe. To może inaczej:

Chcemy zobaczyć styl pracy kandydata.

To już lepiej. Przy czym dużo zależy od sposobu, w jaki realizujesz LC. O tym za chwilę.

Chyba najsensowniejszą odpowiedzią jest ta, która nastawia się na sprawdzenie sposobu myślenia kandydata i weryfikację jego umiejętności na pograniczu umiejętności technicznych i miękkich. LC służy do weryfikowania umiejętności miękkich w kontekście technicznym. Tego, czy delikwent, który jest wygadany, potrafi też rozmawiać o technologii, uzasadniać swoje decyzje i nie gubi się, gdy padnie jakieś bezsensowne pytanie. Mówimy tu przede wszystkim o umiejętnościach komunikacyjnych, decyzyjności, czy asertywności. Możemy też sprawdzić, jak delikwent radzi sobie pod wpływem stresu i czy potrafi planować na poziomie drobnych zadań.

Live Coding – Rodzaje

LC można zrealizować na kilka sposobów. Do pewnego stopnia zależą one od użytych narzędzi, ale tylko w skrajnych przypadkach narzędzia, lub ich brak, wymusza na nas konkretny wybór. Poniżej mój subiektywny podział. Uwzględniłem sposób, w jaki kandydat pisze i jakiego rodzaju kod.

Whiteboard

Znienawidzone przez wszystkich kodowanie przy tablicy. W realiach rozmowy prowadzonej w formie telekonferencji będzie to po prostu notatnik lub współdzielony edytor (o narzędziach później). Propagatorem tej metody był przez lata Google. Googlowska metoda koncentrowała się na rozpisaniu w pseudokodzie i rysunkach rozwiązania problemów algorytmicznych. Jak wspomniałem wcześniej, celem LC nie jest zweryfikowanie umiejętności technicznych, ale umiejętności na pograniczu technicznym i miękkim. Dodatkową wadą podejścia nastawionego na weryfikację techniczną jest przyzwyczajenie u niektórych kandydatów do nieludzkiej praktyki kodowania na papierze, z którą spotkali się w czasie studiów.

Sama metoda nie jest zła. Może okazać się przydatna, gdy szukamy kogoś, kto będzie intensywnie współpracował z osobami nietechnicznymi. Umiejętność przetłumaczenia „z informatycznego” na „biznesowe” i vice versa jest bardzo ważna. Najłatwiej robi się to za pomocą pseudokodu, diagramów i rysunków. W przypadku „typowych programistów” to raczej źródło frustracji i potencjalnego zniechęcenia do naszej firmy.

Co-op

W tej kategorii umieściłem dwa rozwiązania. Pierwsze to sytuacja, gdzie mamy ograniczone środki i mówi osobie prowadzącej rozmowę, co ma pisać. W takiej sytuacji komunikacja jest ekstremalnie ważna, a samo rozwiązanie jest sprawą drugorzędną. Osobiście nie polecam. Jest to rozwiązanie, gdy kandydat nie ma dostępu do komputera, a rozmowę prowadzimy przez telefon.

Drugie rozwiązanie polega zastosowaniu praktyk XP, a szczególnie programowania w parach. Jedna z osób przepytujących siada z kandydatem do programowania. Piszecie rozwiązanie jakiegoś problemu w stylu FizzBuzz, który pozwala na podział zadań na kodowanie i pisanie testów. Taka forma LC wymaga jednak dobrego przygotowania od strony narzędziowej. Idealnie, jeżeli możecie spotkać się przy jednej klawiaturze. W zdalnej odmianie należy zadbać odpowiednie narzędzia. Tutaj prosty edytor raczej nie wystarczy. Warto też poinformować kandydata, że taka forma LC będzie miała miejsce. Wbrew pozorom pair programming nie jest powszechną praktyką. Niby każdy trochę bardziej doświadczony programista coś tam słyszał, ale osób, które miały okazję spróbować, jest niewiele, a pracujących w tej metodologii na co dzień jest naprawdę mało.

Self

Czyli najbardziej klasyczne podejście, gdzie kandydat samodzielnie pisze rozwiązanie w konkretnym języku programowania. Tutaj mamy tak naprawdę dwa wymagania. Pierwsze to myślenie na głos. Kandydat powinien opowiadać, co i dlaczego robi. Drugie to odpowiednie przygotowanie się rekruterów. Nie ma nic gorszego niż konieczność pisania od zupełnego zera. Wtedy cały wysiłek jest skierowany na tłumaczenie rozwiązania. Jeżeli jednak mamy jakiś predefiniowany szablon, to możemy też zobaczyć, jak kandydat rozumie kod zastany. To jest nawet ważniejsze, bo nie zawsze robimy greenfield.

Live Coding – Narzędzia

Zanim przejdziemy do zadań, warto rzucić okiem na narzędzia. Tutaj dużo zależy od twoich preferencji, możliwości kandydata do współpracy i nastawienia organizacji. Nie wskażę konkretnych rozwiązań, ale warto rzucić okiem na te sensowne opcje.

Pierwsza z nich to współdzielone edytory online. Ich niewątpliwą zaletą jest niski koszt wejścia dla użytkowników. Ot, generujesz link, wysyłasz kandydatowi i działacie. Problemy są dwa. Po pierwsze te bardziej rozbudowane rozwiązania wymagają opłat i rejestracji. Nie każdy chce rejestrować się w każdym „fancy tool-u” przy okazji rozmowy. Nie ma obecnie rozwiązania dominującego. To może utrudniać pracę. Z drugiej strony rozwiązania, które pozwalają na jednorazową akcję, zazwyczaj są ubogie pod względem narzędzi. Ot proste zabawki na poziomie współdzielonego jshella.

Druga to namówienie kandydata na udostępnienie ekranu i ulubionego IDE. W takim układzie kandydat ma pełną swobodę pracy ze znanym sobie narzędziem. Wadą jest brak możliwości ingerencji w kod ze strony osób rekrutujących. W krytycznej sytuacji może okazać się, że mamy rozwiązanie jak w pierwszym przypadku co-op. Tylko tym razem to my musimy tłumaczyć, co chcemy uzyskać.

Trzecia opcja to sesja code-with-me w IntelliJ. Startujemy sesję, wysyłamy link i kandydat ma możliwość używania naszego IDE. Praktycznie idealne rozwiązanie, które jednak ma jedną małą wadę. Jeszcze mało osób z niego korzysta i może okazać się, że kandydat będzie miał z tym problem. Ja mam zamiar intensywnie to testować właśnie w przypadku rozmów. Zobaczymy, co z tego wyniknie.

Live Coding – Problematy

Nici z narzędzi i metod, jeżeli zadanie, które postawimy przed kandydatem, będzie „z dupy”. Poniżej subiektywny wybór zadań wraz z uzasadnieniem.

FizzBuzz

I jego odmiany. Zadanie to nastawione jest na sprawdzenie rozumienia TDD. Świetnie nadaje się jako temat programowania w parach. Jest proste, intuicyjne i mamy całą game możliwych rozwiązań. Jeżeli chcemy podkręcić poziom trudności, to wystarczy poprosić o wersję bez użycia if/else.

Fibonacci

Ciąg Fibonacciego realizowany przez rekursję jest dobrym pomysłem na sprawdzenie biegłości w programowaniu jako takim. Java nie potrafi w rekursję, więc użycie trampoliny będzie ogromnym plusem.

Usuwanie duplikatów z listy

Zadanie dla sfrustrowanych rekruterów. Zawsze może być źle. Użycie Stream API, kombinacja z Set, czy pętla. Zadanie to dobrze obrazuje, jak kandydat zna język i jak myśli. Można też sprawdzić jego umiejętności w zakresie TDD.

Implementacja kolejki

Niby proste, ale nie do końca. Szczególnie, że kolejka musi być elastyczna pod względem algorytmu kolejkowania. Zadanie dobrze weryfikuje znajomość wzorców projektowych i ich wykorzystania w praktyce.

Dziel i zwyciężaj

Zadania z tej kategorii pozwalają na sprawdzenie, czy kandydat ogarnia ForkJoinPool i podstawowe metody pracy z dużymi zbiorami danych.

Najważniejsza zasada

Jeżeli decydujesz się włączenie LC do swojego procesu rekrutacyjnego, to musisz być gotowy na nieoczywiste lecz poprawne rozwiązania zadań. Jeżeli kandydat uzyskał w miarę sensowny wynik, to schowaj swoje pomysły i zaakceptuj, że „zdał”.