No to jest taki moment, w którym nawet ja zacząłbym się zastanawiać, co ze mną jest nie tak. ;)
Jak odchodziłem z jednej firmy, to szukałem kogoś na swoje miejsce i pytałem o rzeczy, które robiłem w ostatnim tygodniu pracy. Kandydat miał ochotę wyjść, jak pytałem, czy kiedyś dekompilował binarki dotnetowe, implementował czas Lamporta, analizował zrzuty pamięci czy podglądał ruch sieciowy przez proxy TLS. Oburzenie trochę mu przeszło, jak pod koniec wyjaśniłem mu, że dokładnie takie rzeczy będzie musiał robić. Najwyraźniej pytanie o rzeczy praktyczne też jest kiepskie.
Nie wiem jak inni, ale ja czasami mam tak, że jak dostanę jakieś proste pytanie, to się gubię, bo zaczynam doszukiwać jakichś haczyków.
Poza tym, sam klimat i forma rozmowy ma wpływ na odpowiedzi, ja kiedyś byłem tak przesłuchiwany, że w końcu powiedziałem, że konstruktor nie może być prywatny.
Przesłuchiwania nie robię, a przynajmniej jeszcze nikt z kandydatów nie dał mi takiego feedbacku. Ja im nawet wysyłałem pytania przed rozmową, żeby wiedzieli, z czego się przygotować. Może mam skrzywione podejście, bo nie uważam, że napisanie kawałka kodu na tablicy jest jakoś stresujące, ale jeżeli ktoś tak ma, to może lepiej nad tym popracować w wolnym czasie? Pójście na rozmowę raz w miesiącu nie jest jakoś strasznie wymagające, poza tym raczej wiadomo, że na rekrutacjach trafia się kodowanie na kartce, no i zawsze można zapytać osobę z HR, jak będzie wyglądał proces.
I bardzo dobrze!
Bo jeśli jakaś firma wymaga wstrzeliwania się w gust i prowadzone są w niej wielodniowe rozmowy o nazwie zmiennej, to ja nie chcę tam pracować. A sensowne zadanie z sensownym review/pair programming później pozwala stwierdzić, czy kandydat potrafi napisać działający, testowalny i rozszerzalny kawałek kodu i obronić swoje decyzje.
Tak, tylko to zajmuje masę czasu. Dla kandydata jest to problem, szczególnie w przypadku procesu na miejscu, bo trzeba dojechać, klepać jakieś tam crudy, do tego ludzie potem narzekają, że nie mają swojego IDE, klawiatury, skrótów klawiszowych, swojego krzesełka i kubeczka A dla rekruterów też jest to masa czasu, która w większości jest zmarnowana, bo większość kandydatów się nie nadaje.
No ja ostatnio właśnie miałem taką rozmowę (wcześniejsze kilka razy to były zadania). Efekt jest taki, że pieniądze się niby zgadzają, ale bez interfejsu nie może być klasy, do przechowywania 30 obiektów po kilkunaście bajtów danych tworzone jest readonly struct, bo "klasy są niewydajne" (ale już to, że coś używane jako "baza danych" ma transfer 10kB/s to niewydajne nie jest), a do tego stawiają spację przed każdym nawiasem otwierającym w definicji i wywołaniu metody.
Rekrutacja to proces obustronny, kandydat też ma prawo dowiedzieć się o firmie jak najwięcej. Jeżeli dla Ciebie ważne są spacje przed nawiasami, to mogłeś poprosić o przejrzenie ich kodu.
Tak więc, generalnie nie polecam, sama taka rozmowa to za mało, żeby wykryć patologie.
Dla mnie proces rekrutacyjny to za mało, po okresie próbnym powinna być sensowna rozmowa z współpracownikami i potem odstrzał kandydata, jeżeli ten się nie nadaje, a z takim podejściem można zrobić prostszy i krótszy proces. Tylko to kosztuje masę czasu, pieniędzy, dodatkowo w przypadku wizy i przeprowadzki jest to spory problem. No i firma musiałaby potrafić zaakceptować fakt, że proces rekrutacyjny jest wadliwy, ale przecież każda rekrutuje tylko najlepszych z najlepszych (tak jak wszędzie jest młody zespół i najnowsze technologie dla lidera branży), więc to oczywiście odpada.