DevTalk Trio Q&A: Gry rekrutacyjne

Co myślicie o grach rekrutacyjnych?
To kolejne pytanie z cyklu DevTalk TRIO!

Sławek: Będąc liderem zespołu, prowadziłem swego czasu dużo rekrutacji. To należało do moich obowiązków przez ponad rok. 100 osób przeszło, 50 zostało. Obecnie rekrutuję ludzi w szkole programowania. To nie są durne pytania pod warunkiem, że nie myśli się jak ośmioletni chłopczyk. Dlaczego ktoś zadaje pytanie, na które nie masz szansy odpowiedzieć, bo nie znasz tematu? Po co? Żeby zobaczyć, jak reagujesz na nieznane sytuacje.

Maciej: OK, to ma sens, ale tylko wtedy, jeśli takie faktycznie są oczekiwania w pracy. Bardzo często od programisty nie wymaga się podobnych umiejętności. Oczekuje się natomiast, że dostanie specyfikację i przemieli ją na kod. Moim zdaniem nie ma sensu wówczas zadawać programiście takiego pytania. W przypadku stanowisk wyższych, czy bardziej kreatywnych, wszystkie chwyty są dozwolone. Chodzi przede wszystkim o to, by na rekrutacji sprawdzać wiedzę, której się faktycznie oczekuje, a nie podążać ślepo za modą.

Sławek: Ja się nie spotkałem z zespołem składającym się wyłącznie z ludzi, których zadaniem jest przetwarzanie specyfikacji w kod.

Maciej: Nie twierdzę, że to dotyczy całego zespołu. Po prostu rekrutacja nie powinna wyglądać tak samo dla każdego człowieka.

Sławek: Poczytajcie sobie o modelu Belbina. Zakłada on, że jest siedem czy osiem różnych ról w zespole, m.in. implementer, dowódca, wizjoner, krytyk. Wobec takich informacji świadomy HR, którego jest obecnie coraz więcej, zaczyna kompletować zespół. Role, jakich od niego oczekuje, zależą od klasy problemu. Oczywiście są takie projekty, które są bardzo dobrze wyspecyfikowane i nie wymagają myślenia. Ale wtedy pytanie rekrutacyjne również jest potrzebne, ponieważ sprawdzi reakcję zawodnika. Jeśli nie interesują go takie gry, jest odpowiednim implementerem.

Maciej: Raz podczas rekrutacji użyłem tekstu, który podpatrzyłem swego czasu na Twitterze. Rozmawiali ze mną właściciel firmy i programista pracownik. Programista zadał mi właśnie tego typu pytanie. Wiedziałem, że stanowisko, na które wówczas aplikowałem, nie wymaga rozwiązywania absurdalnych zagadek, zatem jako odpowiedź przytoczyłem zdanie, które przeczytałem: „Kto pierwszy podczas zadawania podobnych pytań powie fuck it, wyjdzie i trzaśnie drzwiami, ten dostaje robotę”. Programistę zatkało, ponieważ był przekonany, że tak się nie odpowiada, natomiast szef firmy się roześmiał.

Sławek: Właśnie. I szef tutaj był świadomy, wiedział, że może potrzebuje żołnierza, który wobec klienta będzie potrafił zachować się asertywnie, a nawet nieco agresywnie. To jest bardzo cenny nabytek w zespole. Nie bez powodu te różne typologie są tworzone, nie bez powodu ludzi dobiera się według pewnej klasy problemów – naprawdę warto o tym poczytać. Programiści często nieświadomie zakładają, że pewne psychologiczne pierdoły to wymysły tworzone nie wiadomo po co. Jednak jest powód, dla którego się za nie płaci.

Maciej: Rada ode mnie jest taka, żeby po prostu być sobą, nie udawać kogoś innego. Odpowiedź, jakiej udzieliłem, wyniknęła z naturalnej reakcji i pokazała mój charakter. Efekty mogły być różne: albo okazałoby się, że nie potrzebują takiego pracownika w firmie, albo wręcz przeciwnie.

Sławek: Zapamiętaj, aby podczas rekrutacji wyjść z inicjatywą: „Kogo potrzebujecie? Ja mogę wiele rzeczy robić, zachowywać się w różny sposób, mam różne skille. Jak mógłbym wam najbardziej pomóc?”. To są bardzo dobre pytania i najlepsza reakcja, jakiej można od Ciebie oczekiwać. Widać wtedy, że jesteś bardziej świadomy, masz szeroki wachlarz możliwości, możesz się dopasować.

Andrzej: Czasem zdarza się, że kandydat, który się do nas zgłasza, jest bardzo dobrze przygotowany, wie, co robimy – a jako Arkency pracujemy czasem nad dosyć unikalnymi rzeczami – i przychodzi już właściwie z pewną ofertą, wymienia kwestie, które pomoże nam ulepszyć. To jest mistrzostwo świata. Totalnie rozkłada nas na łopatki. W tym momencie oczywiste jest, że rozmowa toczy się już w konkretnym kierunku.

Maciej: U was jest specyficzna sytuacja, bo twoja firma – podobnie zresztą jak ta, w której ja pracowałem – ma taki brand, że nie musicie się starać, aby ludzie do was przychodzili. Ludzie chcą u was pracować.

Andrzej: Ale to wciąż jest zaskakujące, jak często kandydatury, które musimy rozpatrywać, opierają się na zasadzie: „To jestem ja, podziwiajcie mnie”. Nawet jeśli mamy ten brand i powinniśmy przyciągać fajnych ludzi.

Maciej: Obecnie nie ma parcia na rynku, ludzie nie muszą się starać. Ale jeśli jest konkretna firma, w której chcesz pracować, powinieneś wykazać się inicjatywą.

Sławek: To, że nie trzeba się starać, to dość cyniczna postawa. Jeśli dasz się polubić od pierwszego wejrzenia, będziesz inaczej traktowany, być może nawet Twoja stawka wzrośnie o 40% z takiej tylko przyczyny, że odrobiłeś lekcje w domu, co Ci zajęło parę godzin. Chyba warto.

Andrzej: A propos tej wcześniejszej rozmowy o korporacjach i polityce: miałem właśnie taki ciekawy fuck up korporacyjny, polityczny, kiedy powierzono mi funkcję gościa, który miał pogodzić dwa projekty i ich integrację. To była tak naprawdę polityczna sprawa, a ja, głupi, myślałem, że chodzi o rozwiązanie problemu. I faktycznie przeprowadziłem tę integrację, i wyniknęła z tego katastrofa, w ogóle nie o to chodziło. Źle się dla mnie skończyła ta sytuacja. Ja wtedy nie rozumiałem celu swojego istnienia w tej firmie.

Maciej: Jest jedna rzecz, której się wstydzę do dziś, chociaż zdarzyła się ładnych parę lat temu. Mimo to opowiadam o niej na każdym szkoleniu. Jak każdy pisałem kiedyś system internetowy, który miał wysyłać do klientów SMS-y. Pomyślałem, że będę bardzo sprytny, bo nie zrobię synchronicznej wysyłki SMS-ów (polegającej na tym, że gdy ktoś klika guzik, to SMS wędruje do adresata), bo wówczas, jeśli bramka SMS-owa pada, to pada również cała aplikacja. Zapisywałem sobie SMS-y do wysłania w bazie. Tam była flaga pending lub send. I zaimplementowałem sobie jakiś lazy loading na MySQL z NHibernate, który raz na 15 sekund pobierał wszystkie wiadomości do wysłania, wysyłał je, oznaczał jako send, a na koniec robił save w całej kolekcji. Jednak źle coś skonfigurowałem w bazie i ten ostateczny save się wywalał. Więc co 15 sekund system się budził, raz jeszcze pobierał i wysyłał wszystkie SMS-y, następnie próbował je zapisać – i się wywalał. To działało sobie na wątku
pobocznym tak długo, aż wyczerpały się pieniądze na koncie w bramce SMS-owej dla mojego klienta. To było smutne.

Sławek: Kiedyś, jako architekt nowego, gigantycznego rozwiązania, dostałem zadanie, aby zintegrować ze sobą istniejące systemy z wielu krajów. Usiadłem więc i zacząłem rysować prostokąty, hipotetyczne możliwe scenariusze integracyjne. Wszystko rozrysowałem. Okazało się natomiast, że dyrektorowi chodziło o to, abym kupił bilety na samolot, poleciał do pięciu krajów, porozmawiał z tymi ludźmi, jakie mają API, co potrafią wystawić – i to polepił. A ja sobie przez trzy miesiące rysowałem prostokąty, które ostatecznie trafiły do kosza, bo nie miały nic wspólnego z zadaniem. Już później nie robiłem tej integracji.

Andrzej: Pamiętam wiele takich stresujących nocy, kiedy naprawiałem coś na serwerach. Nie pamiętam tylko szczegółów, co ja tam dropnąłem, usunąłem.

Maciej: Tydzień temu wyczyściłem produkcyjną bazę z konkursu Daj się poznać, wszystkie zgłoszenia mi się usunęły, bo nie na tej bazie, co trzeba, puściłem delete. Na szczęście Azure naprawdę robi backup. Co prawda nie zadziałała funkcja restore, bo kiedy ją uruchomiłem, wywaliła się po jakimś czasie, ale akurat tę tabelę, o którą mi chodziło, przywrócił.

Sławek: Ja się jeszcze pochwalę, że trzy dni temu straciłem pół dnia, żeby zrobić rekursję czy rekurencję – to się różnie nazywa. Straciłem szacunek do siebie, bo to klasyczny głupi błąd studenta pierwszego roku.