Są różne podejścia do rekrutowania i sprawdzania umiejętności programowania. Osobiście jestem wrogiem prób przyłapania kandydata na tym, że czegoś nie wie; przykładem takiego podejścia jest ten test. Co mi się nie podoba w tych pytaniach? Polegają na spostrzegawczości - jeżeli widziałeś kiedykolwiek podobne konstrukcje, to wiesz dokładnie, na jakie rzeczy zwracać uwagę. Jeżeli spędziło się kiedyś przed komputerem dwie godziny zastanawiając się, dlaczego ten cholerny warunek nie działa, jak powinien, tylko po to, żeby odkryć, że postawiło się pojedynczy znak równości zamiast podwójnego, to na zawsze zostanie to wryte w mózg. Jeżeli się tego nie przeżyło, niełatwo to zauważyć. Sęk w tym, że w większości przypadków kompilator nas ustrzeże przed takim siedzeniem, jeżeli tylko wykażemy dość rozsądku, żeby włączyć ostrzeżenia i je potem przejrzeć. Już nie wspominam o pytaniach o konstrukcje, których nigdy nie zobaczycie w produkcyjnym kodzie. x+++3? Jasne, już widzę, jak przepuszczam to przez recenzję... W każdym razie takie podejście nie sprawdza, moim skromnym zdaniem, umiejętności programowania.
Jest za to inne podejście, które sobie upodobałem, które oczywiście podkradłem komu innemu... podejście to zaleca między innymi Jeff Atwood. Chodzi o to, żeby zadając proste pytania móc zaobserwować kilka rzeczy:
- Po pierwsze, czy jeżeli da się petentowi problem, to on naprawdę chce go rozwiązać. Nie wiem, czy też to zauważacie, ale programiści bardzo często chcą wiedzieć bezzwłocznie. To są właśnie Ci ludzie, którzy, jeżeli zadać im ciekawe pytanie podczas imprezy, wyciągną telefon z wifi i zaczną szukać odpowiedzi. Jest problem? Potrzebujemy rozwiązania; Teraz. To jest pasja i zawziętość, które ciężko zafałszować.
- Po drugie, czy osoba podająca się za programistę potrafi rozwiązywać proste problemy mniej-więcej tak szybko, jak jest w stanie pisać. To jest bardzo ważne. Programowanie w dużej mierze przypomina żonglerkę - jeżeli musisz na chwilę przestać i pomyśleć, to jest spora szansa, że upuścisz kilka piłek.
- Po trzecie, czy kandydat dąży do perfekcji. Może to moje własne zboczenie, ale uważam to za kluczowe dla bycia dobrym programistą. Program nie zachowuje się mniej-więcej tak, jak powinien; albo robi wszystko tak, jak tego oczekujemy, albo nie. Poprawność się nie stopniuje.
Dotychczasowe doświadczenia rekrutacyjne nie napawają mnie optymizmem. Nie jest źle, bo nie natknąłem się jeszcze na kandydata, któremu wysmażenie programu typu FizzBuzz zajęłoby 10-15 minut... ale nie natknąłem się też na takiego, który zrobiłby to bezbłędnie. To bym jeszcze przeżył, błędy się zdarzają, często w prostych rzeczach, ale radzenie sobie z tymi błędami zazwyczaj pozostawia wiele do życzenia. Ale o tym innym razem, teraz i tak się rozpisałem.
