Rekruter

W czerwcu oraz na pocz. lipca miałem okazję uczestniczyć podczas rozmów kwalifikacyjnych na stanowisko młodszego programisty .NET (junior developer). Było to dla mnie spojrzenie na proces rekrutacji z tej nieco innej strony.  Jako, że od mojej opinii o kandydacie również nieco zależało, więc postaram się opisać moje wrażenia z tego procesu po "tej drugiej stronie".

Najpierw umieściliśmy ogłoszenie na kilku przeznaczonych do tego stronach oraz ulotki na kilku Warszawskich uczelniach. Po jakimś czasie, gdy pojawiła się grupa na fb o wdzięcznej nazwie netDevelopersPolandJobMarket to umieściłem tam nasze ogłoszenie z "widełkami płacowymi" oraz nieco większą ilością szczegółów nt. tego stanowiska (stos. technologia, zakres obowiązków itp. itd.).

A jak wyglądała sama rozmowa?
a) krótka, 5-20 min. rozmowa, podczas której my (Ja oraz dyrektor IT) opowiadaliśmy o firmie, naszym dziale IT, tym czym ewentualnie zajmował by się kandydat. Zadawaliśmy też kilka pytań nt. CV, które podesłał nam kandydat.
b) 30 min. codding test na laptopie w mojej obecności
c) "pytania z kartki", czyli mniej lub bardziej szczegółowe "pytania otwarte" nt. C#, .NET, MS SQL itp. itd.
d) ewentualna dalsza rozmowa z szefem IT

Zadania praktyczne były 4. Dwa z SQL oraz dwa z C#. Zadania były o zróżnicowanym stopniu trudności. Wydawało mi się, ze te z C# są trudniejsze, ale tylko do momentu, gdy jeden z kandydatów przyznał się, ze jedno z zadań mieli w SGGW na egaminie ;-)
To co mnie osobiście mocno zaskoczyło to... bardzo słaba znajomość T-SQL wśród kandydatów, którzy byli przepytywani. Dwie os., które "kumały cza-czę" zrobiły oba zadania w ok. 5-6 min. (mniej więcej ok 2-3 min. na zadanie). Niestety ponad połowa kandydatów nie zrobiła zadań z SQL w ogóle.

Z pytaniami "otwartymi" zazwyczaj było całkiem nieźle. Była to też okazja do "bardziej wnikliwego" porozmawiania z kandydatami (tymi co przeszli codding test). Podczas tej rozmowy, oprócz samych odp. na pytania, celem było też zwykłe poznanie kandydata. Tego, czy się interesuje technologią i w czym czuje się mocny, ale też, czy można z nim normalnie porozmawiać i czy da się z nim wytrzymać 8h*5 dni w tyg.

Jak ktoś przeszedł wszystkie etapy w miarę ok (codding test, pytania otwarte, sposób bycia) to zostawał na rozmowę z dyrektorem IT.

Wnioski:
a) 30 min. siedzenia i patrzenia jak ktoś koduje, to jednak zdecydowanie zbyt dużo zmarnowanego mojego czasu. Dobrze było by ten proces jakoś zautomatyzować, ale pozostając przy zadaniach praktycznych. Może jakieś codility, ale któreś z tych podst. poziomów trudności (ponieważ te wyższe zazwyczaj niewiele mają wspólnego z praktyką zastaną później w realnym życiu).
b) najlepszy możliwy kandydat, jaki nam się pojawił, przyszedł na rozmowe po umieszczeniu ogłoszenia o pracę na grupie fb (ogłsozenie z zakresem obowiązków, stos. technologią oraz widełkami płacowymi).

Nie testuj na serwerze testowym!!!

Ten oto wpis, to nic innego jak konkluzja z ost. kilku dni w pracy. I broń boże, nie wykonuj na tych danych, żadnych aktualizacji "notowań, kursu walut" ani innych "co nocnych" jobów. Taka niestety nasuwa się konkluzja z ost. kilku dni.

A co to dokładnie oznacza?
Ano nic innego, ze Piotrek nie umie rozmawiać z ludźmi. Przejmując x syst. informatycznych po swoich poprzednikach, nie zawsze potrafił się dopytać, czy wersje testowe (aplikacji oraz bazy danych) służą do tego, aby programiści mogli na nich cokolwiek testować i broń boże puścili na tym, jakiś update. Szczególnie taki, który działa co noc na prod. i kilka dni temu się wysypał, a ja własnie zrobiłem na niego fixa. O to to nie. Aplikację powinno się przetestować lokalnie, a później, po stwierdzeniu że "u mnie działa" wgrywać od razu na produkcję :/

Jakiś czas temu, podjąłem się zadania przejęcia całej infrastruktury programistycznej w pewnej firmie po tym, gdy odszedł z niej ost. programista i przez kilka tyg. żadne ze stanowisk programistycznych nie było obsadzone. Dużo ich nie było, tj. 2, ale w zasadzie przejmowałem 12 mniej lub bardziej rozbudowanych syst,. informatycznych (największa baza 16 GB danych), a w praktyce żyjący własnym życiem mechanizm naczyń połączonych. Oczywiście, większość aplikacji miała swoich opiekunów biznesowych. O ile miałem parę spotkań z moim poprzednikiem, jednak w praktyce najczęściej koncentrowały się one wokół spraw bieżących, lub przyszłego, nowego syst. który trzeba dopiero napisać.

O ile, z ludźmi z IT rozmawiałem i... np. Adam mnie uprzedził, ze w jego syst. aplikacje "test" oraz "test2" nie są dla mnie dostępne (i stworzył mi inne środ. testowe) o tyle ludzi "biznesowych", którzy zazwyczaj obrażają się o to, ze mówię techniczne słowa, których nie rozumieją, o takie zmiany za bardzo nie podejrzewałem. I masz tu babo placek.

Wysypał się job robiący aktualizację. Znalazłem błąd, poprawiłem go i sru na test. Na teście przeszło to na prod. Fix zrobiony, sprawa rozwiązana i super. A tu niestety nie ma tak dobrze. Opiekun biznesowy, który nie umie pisać skryptów (bo po co mu to), ani tym bardziej zrobić backupu bazy... miał tam jakieś swoje dane, który nocny import mu nadgrał.

Oj Piotrek, Piotrek, I co żeś ty uczynił?
I co ważniejsze? Co też masz teraz zrobić? Porobić własne instancje testowe wszystkich działających usług, skryptów, aplikacji, baz danych? Co noc backupować bazy testowe? A może jednak rozwiązaniem jest, aby dziennie spędzać więcej czasu  na tel. rozmawiając z opiekunami biznesowymi, niż na faktycznym kodowaniu tych systemów?

Normalnie murarz, tynkarz, akrobata...