Jak nie sprawdzać wiedzy technicznej: platformy online

Platformy quizzowe dla programistów (Codility czy inne). Hit czy kit? Teoretycznie obiecują szybkie sprawdzenie wiedzy i weryfikację, czy kandydat jest dobry. Teoretycznie. Bo teoria często rozmija się z praktyką. Poczytajcie szokującą relację ze zdawania testów na platformach on-line.

Zadania zamknięte gone wrong

Kiedy pytania zamknięte są do dupy? Wtedy, kiedy pytanie jest źle sformułowane i nie wiadomo co wybrać (pomimo posiadania wystarczającej wiedzy). Kiedy pasuje kilka odpowiedzi naraz. Szczególnie jeśli to zadanie, które bada rzeczy subiektywne. Np. który CSS bardziej pasuje? (pytanie raczej z webdesignu, projektowania graficznego stron, niż sprawdzające wiedzę techniczną). Wybrałem odpowiedź, która wydała mi się najbardziej rozsądna, i używała stonowanych kolorów. 

I figa, okazuje się, że wg nich źle wybrałem, bo "prawidłową" odpowiedzią było wybranie CSSa w bardzo jaskrawo-oczojebnych kolorach.

Aha.

To dużo tłumaczy. Zakładam, że jeśli to była prawidłowa odpowiedź, to w pracy też takie kolory byłyby preferowane w projektach, które miałbym develepować. Jak najbardziej oczojebne.

Czy może twórcy quizzu kierowali się inną logiką? Dlaczego tamta odpowiedź była jedyną prawdziwą wg autorów, mimo, że wg mnie to moja była lepszą z dwóch poprawnych?

Ale tu też wychodzi słabość testów a/b/c/d, bo nie pozwalają na uargumentowanie decyzji. W rozmowie z żywym programistą zawsze można uargumentować "wybrałbym tak, bo...", albo pytający może doprecyzować "nie pytam pod kątem X, ale pytam pod kątem Y". A tutaj masz tylko automat.

Twórcy quizzów, douczcie się!

Inne pytanie, coś o stylowaniu divów. Wszystko fajnie, tylko zadanie zakładało, żeby stylować divy w CSS po id oraz zakładać ścisłą hierarchię DOM (czyli wymagało to użycia `>`).

Ok, da się zrobić. Znaczka # czy > też umiem użyć.

Problem taki, że to raczej zła praktyka, o czym wie każdy, kto zajmuje się CSSem trochę dłużej.

Czyli znowu - już na wejściu firma pokazuje mi, że będę w pracy zajmował się pisaniem słabej jakości CSSa. WTF.

Devs'killer

Miałem robić zadania na platformie Devs'killer. Takie środowisko, które zapewnia edytorek online do rozwiązywania zadań. Nie polecam.

Edytorek był niezbyt wygodny i powodował opóźnienia - coś, co normalnie bym zrobił w 10 minut, tj. napisał kilka prostych funkcji, zrobiłem w 30 minut (co ciekawe czas przewidywany na to zadanie wynosił chyba z 50 minut? Czyli inni jeszcze gorzej sobie radzili z tym edytorkiem. Bo chyba nie z zadaniem, bo tam nic nie było trudnego. Co najwyżej sprawdzić funkcję na MDN musiałem z raz czy dwa, ale to może mniej niż minutę mi zajęło. Gorszy był build, który trwał dość długo, a musiałem budować, żeby odpalać kolejne przypadki testowe i usuwać błędy. Jakiekolwiek. Zawsze się zrobi literówka itp. To kolejny build)

Więc trochę czasu straciłem.

Ale nic to. Będzie ciekawiej.

Kolejne zadanie polegało na znalezieniu buga w istniejącym projekcie. Wszystko fajnie, gdyby nie to, że edytorek był bardzo toporny i mnie spowalniał. Plus w pewnym momencie zaczął się wysypywać i build rzucał błędami typu "PhantomJS crashed". Po kiego tam z Phantoma korzystali w tym projekcie, to ja nie wiem, bo w tym zadaniu nie było nic związanego z DOM.

Zresztą... może to mój błąd, ale wyszedłem z założenia, że mamy 2019 rok, więc mogę chyba oczekiwać, że platforma testująca, która oferuje edytor online, zrobi to dobrze? Otóż nie! Na dodatek zwykłe console.log nie działało w tym edytorku, step debuggera też nie było... Ale była możliwość ściągnięcia projektu. Więc próbowałem się ratować i ściągnąłem, otwarłem w VSCode, i jeszcze musiałem po drodze zrobić npm install i czekać aż się zainstaluje. Po czym dalej miałem problem z tym, że build był długi, a komunikaty niejasne.

Ogólnie lipa straszna. Jak zobaczycie, że wam każą robić testy na Devs'killerze, to lepiej odmówić robienia, zaoszczędzicie sobie czasu na użeranie się z środowiskiem.

Ramy czasowe zaburzają test

No i ramy czasowe. Nie, to się nie sprawdza. Zarówno w testach programistycznych, jak i na maturze. Jak masz ograniczoną liczbę minut, to wystarczy popełnić lekką pomyłkę, np. zagrzebać się w jednym trudnym pytaniu (zamiast zrobić łatwe przez ten czas) i z 1,5 godziny robi się tylko 45 minut na resztę zadań. Tego typu testy przestają badać wiedzę czy skille merytoryczne (np. w programowaniu), a zaczynają badać szybkość pisania i umiejętność zdawania egzaminów.

Rozumiem, że egzaminy maturalne są zjebane, bo organizowane przez państwo - ale czemu musimy przenosić błędy państwowej edukacji do branży IT?

Czy naprawdę programowanie to ma być sport i wyścigi "kto pierwszy, ten lepszy"? Czyli: kto szybciej naparza w klawiaturę, ten przejdzie do kolejnego rekrutacji? WTF

Computer says no

Ale dobra. Są testy. Z jakimś limitem czasowym. Co się dzieje dalej?

Jak dla mnie każdy tego typu test powinien być potem sprawdzany przez programistę. I czasem tak jest (w niektórych firmach dają zadanie, a potem jest rozmowa o zadaniu). Czasami jednak tego brakuje.

Rozumiem, że niektóre firmy nie są ściśle firmami IT.  Rekrutowałem się do firmy, która zajmuje się głównie sprzedażą detaliczną książek, czasopism czy kubków albo długopisów - ma taką sieć sklepików stacjonarnych w całym kraju - takie jakby księgarenko-kawiarenko-kiosko-sklepiki-z-upominkami-i-kij-wie-co-jeszcze, gdzie i tak niczego nie ma zwykle, jak się czegoś szuka. No i miałem im pomagać wchodzić w internet i robić platformę do sprzedaży biletów.

Nie wiem, czy to dlatego, że firma nie jest IT, czy z innych powodów, ale odczułem, że po zrobieniu testu nikt techniczny go nie sprawdził. I że dział HR zobaczył, że zadanie ma mało punktów i "do widzenia", mimo, że powody złej punktacji mogą być różne (np. mi wyszło tylko 50 ileś procent JSa, nie znam się na kodzeniu w JS, czy po prostu test był zjebany, skoro tak mało mi wyszło? XD Żeby nie było - jak mi wychodzi 100% w tego typu testach, to też uważam, że test jest zjebany, bo przecież nie wiem wszystkiego. No ale bez przesady, coś tam kodzić umiem w JS, powinno więcej wyjść)

Niestety, zawalili i teraz pewnie zatrudnią kogoś gorszego xD i będą mieć słabą stronę. 

Cow, deal with it!

A co z Codility? Cóż.

Bardzo częsty problem, choć niezwiązany może bezpośrednio z Codility jako platformą, tylko z osobami, które wymyślają zadania - to, że opisy zadań są często mgliste, niejasne, trzeba się zastanawiać, o co tam chodzi.

Ktoś może powiedzieć, że to dobrze, bo w prawdziwej pracy programisty opisy tasków również  bywają niejasne.

No pewnie! Jednak w prawdziwej pracy zawsze można zapytać autora taska, "o co tam do cholery chodzi????". Żeby doprecyzował. A tutaj trzeba się domyślać i wczytywać w ścianę tekstu czasem (mogliby jakieś rysunki przynajmniej dawać).

Ale główny problem z Codility od strony czysto technicznej polega na tym, że nie widać pełnych wyników. Masz mały zbiór danych testowych i nawet jak zrobisz coś, co będzie działać w 100% dobrze na tym małym zbiorze, to jak wyślesz odpowiedź, to może się okazać, że tylko w 30% przypadków działa.

Czyli musisz napisać perfekcyjny kod za pierwszym razem. Być jak Linus Torvalds. Jak ci się nie uda, to wypieprzaj, twoje rozwiązanie jest nieoptymalne. Chuj z tym, że jak byś dostał info "twoje zadanie się wypieprza w tym i tym momencie", to byś to zoptymalizował (wiem co mówię, bo robiłem zadania przykładowe na Codility i najpierw miałem mało punktów, a za którąś próbą miałem 100%).

Nie wiem co mam sądzić, ale jeśli firma korzysta z Codility, to daje mi przekaz "w codziennej pracy będziesz miał godzinę na zrobienie taska, a jak nie zrobisz idealnie za pierwszym razem, to cię zwolnimy".

To albo po prostu firmy są clueless i nie wiedzą jak rekrutować programistów i wybierają platformy testowe tylko dlatego, że inne firmy tak robią i żeby zaoszczędzić na czasie wymaganym do przeprowadzenia porządnej rozmowy technicznej.

Nie wiem co gorsze...  Gówniane zadania rekrutacyjne odzwierciedlają gównianą rzeczywistość pracy? Czy: jesteśmy niezorganizowaną firmą ze słabo działającym procesem rekrutacyjnym, a zadania są kompletnie przypadkowe, bo nie umiemy zrobić lepszych?

Co można zrobić lepiej?

Jakie pozytywne wnioski można wyciągnąć?

Feedback podczas edycji

Jak robisz środowisko testowe dla programistów, to zapewnij szybki feedback (kilkusekundowy build, żeby sprawdzić czy testy przechodzą nie jest szybkim feedbackiem. Ułamek sekundy - tak. Kilka sekund - za długo. Nie mówiąc już o sytuacjach, kiedy trwa on jeszcze dłużej albo w ogóle się nie buduje). Programista powinien mieć możliwość logowania (console.log) oraz debugowania danego rozwiązania w środowisku online.

Do feedbacku również należy dostęp do pełnych wyników testu (na całym zbiorze danych, a nie jak w Codility, na jego próbce). W sytuacji, kiedy obliczenie pełnych wyników zajmuje dłuższy czas (chyba to jest powodem, dla którego w Codility nie ma do nich podglądu od razu), powinny być one włączane na życzenie. Nie powinno się ukrywać takich rzeczy przed kandydatem.

Możliwość poćwiczenia przed zrobieniem testu na poważnie

Środowisko testowe powinno również udostępniać przykładowe testy dla osób, które chcą "poćwiczyć" rozwiązywanie testów i zapoznać się z platformą.

Jedz swoją karmę dla psów

Czyli dog-fooding - jeśli twoja firma rekrutuje programistów za pomocą takiego typu narzędzia, to do cholery, wypróbuj je! Weź drugą osobę z zespołu i niech przygotuje ci zadania, a ty sobie przejdź taki test i zobacz, czy naprawdę to środowisko jest takie wygodne i ile punktów zdobyłeś. I czy starczyło ci czasu, czy może nie. I zastanów się, czy wyniki testu odzwierciedlają twoje rzeczywiste umiejętności, czy może gówno znaczą tak naprawdę.

Wtedy zrozumiesz, jak to jest być kandydatem i tracić czas na tego typu rzeczy jak użeranie się z platformą testującą i niejasnym opisem zadania.

Wizualność

Powinna być możliwość dodania rysunków do zadań, może nawet jakiś prosty edytor diagramów? To ułatwiło by autorom pytań stworzenie wymagań do zadania w taki sposób, żeby był to zrozumiałe (czytanie ściany tekstu w zadaniach nie jest zrozumiałe).

Rób dobrze

Jeśli robisz coś, to rób to dobrze. Jeśli zapewniasz edytor on-line, to zrób go dobrze (są gotowe komponenty/biblioteki, można użyć zamiast robić od zera).

Jeśli wymyślasz zadania zamknięte z jedną odpowiedzią prawidłową, to zadbaj o to, żeby faktycznie była tylko jedna odpowiedź prawidłowa itp.

Po zrobieniu testu przez kandydata zadbać o to, żeby test był przejrzany przez programistę. Jeśli wyniki testu są oglądane tylko przez dział HR czy inne osoby, które na programowaniu się nie znają, to nie jest za fajnie. To źle świadczy o firmie, bo nie po to ja poświęcam swój czas (ponad 1,5 godziny) na zrobienie testu, żeby potem nikt tego nawet nie przejrzał.

No i tyle póki co.