iTechArt logo

Pernej Blog: 10 pytań, których programiści nienawidzą podczas rekrutacji technicznych

Development & QA

(Prawie) Doktor Piotr Pernej z właściwym sobie wdziękiem rozprawia się ze sztampowymi pytaniami zadawanymi podczas rekrutacji technicznej. Jego pierwsza publikacja nie do końca licuje z powagą korporacji. Aczkolwiek, jak się tak dobrze zastanowić, to i nasze nastawienie do świata nie licuje z podejściem korporacyjnym. Zapraszamy więc za kulisy. Przygotujcie się na dużą dawkę humoru, a jeśli jesteście rekruterami technicznymi – życzymy dystansu do siebie!

20220111_135635_cr.jpg

Piotr Pernej

Technical Lead

Piotrek jest w branży od 2008 roku. Przez 5 lat pracował jako wykładowca akademicki na WMiI UŁ oraz pracownik naukowo-dydaktyczny w katedrze KAN, kończąc jednocześnie studia doktoranckie. Obecnie lider w zespole .NET.

Halo deweloperze! 

Czy czujesz się zmęczony technicznymi rozmowami o pracę? 

Czy nużą Cię powtarzające się, sztampowe pytania rodem z pierwszych stron blogów dla technicznych rekruterów? 

Czy czujesz, że pytający odnalazł zagadnienia tuż przed rozmową na pierwszych stronach wyszukiwania Google? 

Czy Twoja kreatywność krwawi podczas rozmów rekrutacyjnych? 

Jeśli na powyższe odpowiedziałeś TAK, to znaczy, że cierpisz na Syndrom Zmęczonych Rekrutacją (SZR). Niestety nie mam na sprzedaż żadnego suplementu diety, który Cię z niego uleczy. Przygotowałem natomiast subiektywną listę 10 pytań zadawanych na rozmowach technicznych, które przyczyniają się do rozwinięcia syndromu. 

Zanim przejdziemy do meritum, małe wyjaśnienie. To, że pytanie znalazło się na liście, nie oznacza z automatu, iż z natury jest złe. Wszystko zależy (jak w całym wytwarzaniu oprogramowania!) od kontekstu, intencji rekrutera, oczekiwanej odpowiedzi, głębi rozmowy technicznej i poziomu samego kandydata. Poniższy zbiór jest wynikiem moich obserwacji jako rekrutera oraz jako osoby rekrutowanej. Na liście zostały umieszczone pytania, które: 

  • Bardzo często powtarzają się na rozmowach - na tyle często, iż są postrzegane jako sztampowe (co nie oznacza, że są złe - po prostu zdarły się z biegiem czasu) 
  • Nie sprawdzają rozumienia i nie dotykają istoty problemu, a jedynie wyuczone regułki, których każdy kandydat może się „wykuć” na pamięć.

Pytania nie są uporządkowane w żaden intencjonalny sposób. 
 

Jaka jest różnica między POST a GET?

Chyba najrzadziej wymienianą różnicą między POST a GET jest różnica w liczbie liter. Większość pozostałych była już wymieniona. Pytanie samo w sobie nie jest złe, ale jest zdarte jak płyta Justina Biebera na półce nastolatki. Można je odnaleźć na wielu portalach, gdzie publikowane są popularne listy pytań z rozmów o pracę. Jeśli kandydat odrobił lekcję - to pytanie go nie zaskoczy, a może wręcz odnieść wrażenie, iż rekruter używał popularnej wyszukiwarki do ułożenia listy pytań. 

Zaimplementuj sortowanie bąbelkowe 

Jak wiemy, wszystkie popularne algorytmy do sortowania, które świat dotąd wymyślił, powstały za czasów komunizmu. Z natury są więc złe i takich gotowych i sprawdzonych algorytmów nie należy używać. Dlatego należy pisać własne algorytmy. Wszystko samemu. Swoje jest najlepsze. Mamy swoje smartfony, swoje warzywa i swoje algorytmy sortowania danych. 

Oczywiście algorytm bąbelkowy wydaje się najpraktyczniejszy do napisania. Używamy go przecież wszyscy co dzień. Każdy szanujący się developer posiada na swoim githubie co najmniej 3 odsłony swojego własnego algorytmu sortowania bąbelkowego. Szlifuje je regularnie, niczym perłę w programistycznej koronie i okazuje tylko najbardziej zaufanym recenzentom. 
Na rozmowie o pracę prezentuje antologię algorytmów bąbelkowych i po udanej rozmowie, w momencie zatrudnienia, wartość intelektualna wynikająca z tych algorytmów wliczana jest w kapitał zakładowy firmy. 

Pisząc już poważnie: wielu rekruterów, polecając napisanie algorytmu sortowania bąbelkowego, sprawdza umiejętności algorytmiczne i zdolność do rozsupływania problemów. Nie ma w tym nic złego, choć po doświadczonych rekruterach spodziewałbym się, iż jednak zaproponują bardziej unikalny problem niż bąbelki. 

Jaka jest różnica pomiędzy klasą abstrakcyjną a interfejsem? 

Oj, słysząc to pytanie ma się wrażenie, że rekruter w weekend robił porządki w piwnicy, a odnaleziony zeszyt ze studiów do podstaw programowania obiektowego otworzył się samoistnie na notatkach z pierwszych październikowych ćwiczeń. Reszty notatek nie było, więc cóż... Zapytajmy o te różnice. 

Pytanie to pojawia się nad wyraz często i niestety w przypadku, kiedy zadawane jest bardziej doświadczonym developerom, może stwarzać wrażenie, iż rekruter chce przejść interview po linii najmniejszego oporu. Jak inaczej wyjaśnić dobór pytania, które jako pierwsze przychodzi na myśl wybudzonym w środku nocy programistom? 

Czy metoda interfejsu może zawierać implementację? (.NET) 

Och...Niech język uschnie lub przynajmniej stanie dęba temu śmiałkowi, który jeszcze o to zapyta programistę .NET. 
Jest jedno usprawiedliwienie: w .NET Core dodano możliwość domyślnej implementacji w interfejsie (Java już wcześniej miała taką możliwość). Pytanie może więc mieć drugie dno – sprawdzające, czy programista jest na czasie ze zmianami w środowisku, w którym pracuje na co dzień. 

Wymień znane Ci wzorce projektowe 

Taaaak, z każdym pustym wymienieniem kolejnego wzorca otrzymuję automatycznie +10 do szacunku. A jeśli wymieniłem wszystkie wzorce z GoF, mój szacunek jest już na tyle duży, że właściwie jestem gotowy do napisania książki. Książki o wyliczaniu wzorców projektowych. Tytuł "100 sposobów na wymienianie wzorców projektowych" jest ciągle tytułem nieobecnym na rynku, więc nisza czeka. 

Dodatkowo możesz porozmawiać z rekruterem jak zrobić klasę Pizza w oparciu o wzorzec dekoratora. Dla uproszczenia możecie otworzyć kilka stron internetowych z pizzą i dekoratorami, na pewno znalezienie nie będzie stanowiło problemu. A później możecie razem spróbować zaimplementować tak dużo nadmiarowych wzorców projektowych w maksymalnie małym fragmencie kodu, jak to tylko możliwe. Na pewno przydadzą się w przyszłości i na pewno będą wyglądać bardzo fajnie i modnie. Przecież im więcej wzorców wymienię i wypiszę, tym jestem lepszym developerem! Aby dodatkowo pełniły rolę odstraszająco-obronną przed zmianami innych developerów, dodaj jeszcze parę wzorców zupełnie tam nieprzystających. To Twój medalion na przyszłość. Poziom rozdmuchania kodu będzie na tyle duży, że na pewno nikt Twojej klasy nie dotknie. 

Mówiąc o wzorcach - oczywiście ich znajomość jest potrzebna, ale nie w sensie wymieniania jednym tchem wszystkich, jakie znam, wraz z napotkanymi i powielanymi (oklepanymi) przykładami, lecz umiejętność (poprawnego!) zastosowania w realnej sytuacji. Odnalezienie prawidłowego rozwiązania problemu, przy wsparciu doświadczeniem swoim oraz kolegów i koleżanek (przecież tym są wzorce, prawda?) jest istotniejsze niż bycie rekordzistą w ich wyliczaniu na czas. 

Za wzorcami kryje się pewne dodatkowe zagrożenie - kiedy wyuczymy się ich na pamięć w postaci: klasa problemu - jaki wzorzec zastosować, mogą uśpić kreatywność, odciągając programistę od nowatorskiego myślenia na rzecz szablonowego używania "gotowca". 

Należy pamiętać, iż stosowanie wzorców ma jedynie pomóc w rozumieniu rozwiązań określonych klas problemów. Nie jest on gotowcem, który wystarczy bezrefleksyjnie wziąć, lecz jedynie podpowiedzią, którą należy dostosować do kontekstu i konkretnego problemu. 

Czy mogę utworzyć egzemplarz klasy abstrakcyjnej/interfejsu (.NET)? 

Legenda głosi, iż jeśli szybko 5 razy pod rząd wymówi się frazę "abstrakcja" stojąc naprzeciwko wyłączonego monitora, w jego odbiciu pojawi się zinstancjonowana po raz pierwszy klasa abstrakcyjna. 

Jeśli wchodząc na rozmowę przeczuwasz, iż padnie takie pytanie, możesz od razu odpowiedzieć nieproszony: 

- Dzień dobry, jestem Piotr, nie można utworzyć takiej instancji. 
- Dziękuję panie Piotrze, proszę wejść i usiąść, możemy rozpocząć. 

Dzięki temu oszczędzisz rekruterowi energię, jaką by zmarnował na wypowiedzenie kilkunastu słów użytych do sformułowania pytania. A jako efekt uboczny może nastąpić tzw. “efekt wróża”. Możesz zostać zatrudniony na stanowisku Senior Jasnowidza, pełniąc obowiązki np. przewidywania bugów w legacy systemie po releasie. 

Pytanie to oczywiście może być zadane w przypadku rozmowy z początkującym developerem. Lecz z racji jego powszechności - zalecam umiar. 

Rozszyfruj skrót SOLID 

I znów: wymień. Wymień, wymień, wymień. Świetne pytania dla kandydata, testujące jego sprawność umysłową w rozszyfrowaniu akronimów. Jest to pytanie sztampowe do tego stopnia, iż spotkałem się w swojej karierze rekrutera z sytuacją, kiedy nie pytając o SOLID, kandydat sam zadał sobie to pytanie i zaczął rozszyfrowywać jednym tchem skróty. Albo wyglądałem na takiego, co prędzej czy później o to zapyta, albo kandydat chciał mi oszczędzić czasu w myśl reguły: pan nie pyta, ja odpowiem. 

Zasady SOLID stały się kanonem programowania obiektowego, lecz znacznie lepszym pomysłem będzie pogłębione sprawdzenie (może być na praktycznych przykładach), czy są one dobrze rozumiane przez programistę. Jeśli je dobrze rozumie - nie ma dla mnie większego znaczenia, czy dobrze rozszyfruje akronim. 

Jaka jest różnica pomiędzy interfejsami IQueryable a IEnumerable (.NET)? 

Brawo, właśnie zostałeś uznany za winnego zbrodni. Zbrodni zabicia kreatywności developera. Oczekuj na softwarową policję, zjawi się u Ciebie w kodzie i będzie kazać pisać skomplikowane wyrażenia regularne 3x dziennie. 

Jest to kolejne, bardzo popularne pytanie, które nie pogłębione przez rekrutera sprowadzi się do mechanicznego powtórzenia przez programistę (być może) wyuczonej na pamięć tabelki porównawczej odnalezionej w internecie. 

Co to jest REST i jak bardzo jesteś RESTful? 

Jeśli na rozmowę wszedł kandydat, który już na początku Cię zraził i wiesz, że nie chcesz go zatrudnić, lecz brakuje Ci odwagi i eleganckiego powodu by odmówić - zadaj właśnie to pytanie. Jest spora szansa, że wybierze ofertę konkurencji. Przy okazji będziecie mogli się przekomarzać kto z Was jest bardziej RESTful. 

Pytania o REST, mimo że dające przestrzeń do pewnej pogłębionej rozmowy, są już na tyle zdarte, iż sami rekruterzy zaczęli zauważać jego „nadmierną” popularność oraz wyuczone odpowiedzi kandydatów, co stało się przyczynkiem do odwrotnego trendu – coraz częściej jest po prostu pomijane na rozmowach. 

Pytania bazujące na powszechnie znanych i oklepanych przykładach 

Pytania, po których nie masz ochoty mieć kontaktu z rekruterem nawet przez spróchniały kij oraz nerwowo rozglądasz się po pokoju, szukając ukrytej kamery. Mowa tutaj o rozprawkach na temat dziedziczenia na podstawie klas Figura i Prostokąt, na omawianiu wzorca projektowego dekorator na przykładzie pizzy, na dysputach o wzorcu builder przy użyciu klasy Samochód i o meandrach Liskov Substitution Principle na przykładzie sztucznej kaczki. 

Wszyscy bowiem wiedzą, iż w każdym szanującym się software house developerzy piszą głównie klasy do obsługi pizzy a klasa Figura jest klasą bazową każdej innej klasy. Stąd umiejętność dziedziczenia z pizzy i stosowania figur, czy na odwrót, jest obowiązkiem każdego szanującego się developera. Czy za wymienianie pizzy w dekoratorze, samochodów w builderze i figur w dziedziczeniu branże gastronomiczne, automotive oraz kółka matematyczne zyskują jakieś benefity? Jeśli tagować je na każdej stronie z pytaniami rekrutacyjnymi, ich pozycja w wyszukiwarkach byłaby nad wyraz mocna. 

Jako podsumowanie z punktu widzenia rekrutera należy postawić pytanie: czy zadania, jakie są dawane programiście, odzwierciedlają wiedzę, której oczekuję od niego w codziennej pracy? Czy oczekuję od niego implementacji sztucznych kaczek i czy szukam specjalistów od sortowań bąbelkowych oraz tworzenia instancji klas abstrakcyjnych? Na ile ograniczone czasem pytania i odpowiedzi pozwalają mi określić i zgłębić jego wiedzę, a na ile są tylko szablonem, w który rekruter wpisuje kandydata? 

Sporo pytań. Odpowiedzi każdy sam dopisze :-)