Ostatnio pisałem o 5 radach dla osób ubiegających się o stanowisko junior programisty. W dzisiejszym wpisie chciałbym kontynuować ten temat i porozmawiać o błędach, które wywracają Twoje zadanie rekrutacyjne. Warto o tym wiedzieć!
Zadanie rekrutacyjne
Zadania na stanowiska juniorskie są zwykle proste. Oczekiwaniem wobec nich jest sprawdzenie potencjału kandydata i jego obecnych umiejętności. Nawet z bardzo prostego kodu doświadczony programista jest w stanie wywnioskować, czy osoba ubiegająca się o pracę ma już jakieś przygotowanie praktyczne, czy też jest dopiero na bardzo początkowym etapie nauki.
Z moich obserwacji wynika, że jest jednak grupa powtarzających się błędów, które sprawiają, że rekruterzy techniczni mogą odrzucić dane rozwiązanie.
Pamiętaj też, że moje obserwacje dotyczą mojego doświadczenia. A co za tym idzie nie traktuj ich jako jedynego wyznacznika.
1. Brak czytania ze zrozumieniem
Ok. Zaczynamy powolutku. Zadanie rekrutacyjne to krótszy lub dłuższy kawałek tekstu. Ten tekst należy przeczytać ze zrozumieniem. Jasne i oczywiste. Niby tak, jednak to, co ja widzę w rozwiązaniach zadań bardzo często wpisuje się do jednego z poniższych przypadków:
- W zadaniu jest prośba o modyfikację wyłącznie klasy X. Nadesłane rozwiązanie zmienia klasę X, Y i Z. To błąd. Wyraźnie określone jest w zadaniu, co jest do zmienienia.
- Do zadania dodana jest informacja, że w razie wątpliwości można zapytać się mailowe o jakieś szczegóły. Kandydat przysyła rozwiązanie zadania z informacją, że zrobił tak i tak, ale nie do końca rozumie polecenie. To błąd. Jeśli nie rozumiesz polecenia, to dopytaj … zwłaszcza, gdy rekruter wyraźnie pisze, że masz taką możliwość.
- W zadaniu jest określone, że w zadaniu należy korzystać tylko z biblioteki standardowej (np. JDK dla Javy). Rozwiązanie, które pojawia się na skrzynce rekrutera, zawiera natomiast dodatkowe biblioteki typu Apache Commons. To błąd. Takie polecenie służy weryfikacji znajomości języka i jego konstrukcji. Osoby, które sprawdzają takie zadanie dokładnie wiedzą, że są biblioteki, które rozwiążą dany problem szybciej w jednej linijce. Ale nie o to chodzi.
Dlatego pamiętaj o tym, żeby czytać zadanie ze zrozumieniem i dostosować się do jego wymogów.
I teraz jeszcze uwaga. Nie oznacza to, że nie możesz dodać czegoś od siebie. Zawsze możesz skomentować swoje rozwiązanie i opisać alternatywne podejście.
2. Brak dopytania o szczegóły
Skoro już omówiliśmy czytanie ze zrozumieniem, to warto teraz przejść do jednego z trudniejszych dla kandydatów tematów. Czyli wątpliwości:
Zadanie wydaje się łatwe, ale nie rozumiem, czy tutaj może być wartość null i czy to pole jest unikalne.
Na wstępie warto powiedzieć, że część zadań jest specjalnie ułożona tak, żeby nie wszystko było w nich od razu w pełni określone. A dzieje się tak z kilku powodów.
Jednym z nich jest danie kandydatowi możliwości poszukiwania dobrego rozwiązania. Czy w danym momencie może pojawić się wartość null, czy też pusta lista, czy lepiej jest zastosować Optional, czy coś innego. Rekruter techniczny sprawdza dzięki temu sposób myślenia kandydata i to jak podchodzi do rozwiązani problemu.
Takie podejście dodatkowo sprawdza, czy kandydat będzie w stanie wyjść z inicjatywą i dopytać o szczegóły problemu. Alternatywnie będzie sam próbował coś wymyślić i założyć, chyba że już wcześniej spotkał się z podobnym problemem.
Dlatego pamiętaj, że czasem warto dopytać o szczegóły zadania niż przesłać zadanie rekrutacyjne z rozwiązaniem, które będzie mijało się kompletnie z oczekiwanym rezultatem.
3. Kopia z Internetu
Niektóre firmy stosują konkretny typ zadania podczas rekrutacji. Często wynika to z historii danej firmy, jej pierwszego produktu lub pewnego specyficznego, uproszczonego kodu z jakiegoś projektu. Bardzo często takie zadanie rekrutacyjne z roku na rok jest bardzo podobne i jego fragmenty (lub wręcz artykuły na jego temat) można znaleźć w sieci.
Czy to pomaga, czy też jest wręcz przeciwnie?
Moim zdaniem podczas rekrutacji na stanowiska juniorskie to bardziej przeszkadza. Dlatego, że gdy kandydat jeszcze nie umie rozwiązać zadania samodzielnie, to pojawia się pokusa skopiowania takiej treści.
I niestety na krok skopiowania takiej treści decyduje się całkiem spory odsetek kandydatów. Rekruterzy techniczni dokładnie znają rozwiązania zadań dostępne w Internecie. Używają biegle Google’a … serio, uwierz mi na słowo.
Dlatego absolutnie pod żadnym pozorem nie kopiuj rozwiązań dostępnych w sieci. Szkoda tak odpaść z rekrutacji już na samym początku procesu.
Tutaj też taki niuans. Rekruterzy techniczni zmieniają co jakiś czas drobne szczegóły w zadaniach. Także to, że są dostępne w sieci nie znaczy, że są rozwiązaniem poprawnym danego problemu. A dodatkowo nie wszystkie rozwiązania w sieci aktualnej wersji problemu są poprawne.
Dlatego jeśli Ci rzeczywiście zależy na dostaniu się do danej firmy, rozwiąż zadanie rekrutacyjne SAMODZIELNIE.
4. Kopia od koleżanki lub kolegi
Kopia z internetów już była. To teraż czas na drugą kopię. I tutaj będzie szybko.
Jeśli rekrutujesz na dane stanowisko i rekrutuje na nie Twoja koleżanka, kolega, wujek, ciocia, czy babcia … to pamiętaj, że cztery dokładnie takie same rozwiązania zadania rekrutacyjnego w krótkim okresie czasu wzbudzają zastanowienie. Czy takie zastanowienie działa na korzyść kandydata? Pytanie to pozostawię bez odpowiedzi.
5. Null, Stream i Predicate prawdę Ci powie
Z osławionym NullPointerException historii jest bez liku. Prawda jest taka, że zwykle nie możemy zakładać, że coś nie będzie null’em. Nawet najlepsze systemy w swojej historii borykały się lub borykają się czasem z wyjątkiem tego typu.
Mam tutaj taką radę dla kandydatów. Jeśli gdzieś w Twoim kodzie znajduje się coś w rodzaju:
if (name.equals(node.getName().toUpperCase())) {
...
}
to pamiętaj, że masz duży potencjał na NPE. Zwykle nie jest to coś, co od razu skreśla Twoje rozwiązanie. Ale zawsze to jest jakiś mały niuans, który zwraca uwagę.
Dlatego przejrzyj bibliotekę standardową Twojego języka i w przypadku Javy nie bój się stosować m. in. Objects.equals(Object a, Object b) i Optional.
Jeśli chodzi o wykorzystanie stream’ów to warto pamiętać, że wprowadzono je w JDK 8. A co za tym idzie nie jest to nowość, o której można nie wiedzieć. Dlatego należy z nich korzystać, jeśli jest taka możliwość również w rozwiązaniach zadań. Ich zrozumienie jest też wskazówką, że kandydat coś niecoś już kojarzy. Jednak nie stosuj ich, gdy nie rozumiesz ich działania. Jeśli np. zastosujesz parallel(), to lepiej niech ma to sens … zwykle jednak nie będzie miało …
Predicate to fajny interfejs. Jednak należy go stosować umiejętnie. Także zastanów się dwa razy zanim zmienną tego typu jawnie zastosujesz w kodzie.
6. Spring dobry na wszystko?
Nie wiem dlaczego tak się dzieje, ale jakoś tak się zdarza, że niektóre rozwiązania zadań rekrutacyjnych, w których nie ma ani słowa o Spring Framework w rozwiązaniu mają np. adnotacje @Autowired, @Component, czy @Configuration.
To dla mnie duże zaskoczenie. W treści nie ma nic o Spring. A rozwiązanie na skrzynce e-mail ma dodatki ze Springa. Lekka konfuzja. Nie działa to raczej na korzyść kandydata.
Wszyscy wiemy, że Spring Framework, czy też bardziej konkretnie Spring Boot, to pewnego rodzaju standard w branży. Jednak jeśli zadanie nie dotyczy Springa, to nie powinien się on znaleźć w rozwiązaniu, np. rozwiązaniu zadania algorytmicznego.
Tutaj wydaje mi się, że kandydaci chcą przez to pokazać, że wiedzą i potrafią używać Springa. Ale nietrafione jego użycie daje efekt zupełnie odwrotny. Dlatego nie stosuj Springa na siłę. Zresztą sprawdzanie wiedzy ze Springa na stanowisko junior developera jest moim zdaniem … bez sensu.
7. Rekurencja … killer
Problem problemowi nierówny
Nie wszystkie problemy wymagają rekurencji. I wiele problemów algorytmicznych można rozwiązać bez niej.
Ale np. struktury zagnieżdżone to jedna z klas problemów, gdzie powinno zaświecić się światełko w głowie kandydata, że rekurencja może być całkiem dobrym pomysłem na rozwiązanie.
Z mojej praktyki wynika, że jednym z wzorców projektowych, który przysparza niezwykle wiele problemów kandydatom, jest kompozyt. Nie jest to trudny wzorzec. Ale dzięki swoje konstrukcji jest świetnym przykładem na możliwość zastosowania rekurencji w przeglądaniu struktury jego elementów.
Dwa słowa o rekurencji i studia vs bootcamp
I tutaj chciałbym dodać ważną moim zdaniem uwagę do innego tematu, czyli „bootcamp, czy studia na kierunku informatyka”. Właśnie w przypadku takich problemów algorytmicznych bardzo wyraźnie widać różnicę w tych dwóch ścieżkach edukacji.
Studenci kierunków informatycznych zwykle bez większych trudności rozwiązują podstawowe problemy rekurencyjne. Wynika to z tego, że stykają się z nimi podczas wielu zajęć na uczelni i piszą w tym czasie wiele projektów, gdzie rekurencja jest naturalnym elementem rozwiązania.
Żeby zrozumieć rekurencję …
To understand recursion, one must first understand recursion.
Stephen Hawking
Dlatego, jeśli aplikujesz na stanowisko junior programisty to pamiętaj, że rekurencja to killer zadań rekrutacyjnych. Pisałem już o tym w Junior Java Developer Handbook. Jeśli jeszcze nie rozumiesz, jak ją stosować to szybko nadrób zaległości. A wzorzec projektowy kompozyt to taki wzorzec, który musisz znać.
Warto też pamiętać, żeby dobrze wybrać miejsce wywołania funkcji rekurencyjnej. Czasem zdarza się, że choć rozwiązanie korzysta z rekurencji, jednak gdzieś pojawia się za wcześniej return i np. nie jest przejrzane całe poddrzewo w strukturze drzewiastej. Nie jest to zwykle błąd dyskwalifikujący. Zwłaszcza, że zwykle z tego, co obserwuję, taki błąd zdarza się w kodzie, który z dużym prawdopodobieństwem został napisany samodzielnie. Ale na dalszym etapie rekrutacji trzeba się będzie z tego wytłumaczyć.
I co najważniejsze. Jeśli widzisz struktury zagnieżdżone to praktycznie na 100% Twoje rozwiązanie odpadnie, jeśli przejrzysz tylko pierwszy poziom zagnieżdżenia. Pamiętaj o tym.
W ramach ciekawostki. Najdziwniejsze rozwiązanie zadania dotyczącego rekurencji, jakie w ostatnim czasie czytałem, zawierało opis słowny rozwiązania. W opisie tym było zwrócenie uwagi, że problem jest rekurencyjny i tak też będzie zakodowany. Natomiast w kodzie rekurencji nie było. Dlatego naucz się rozpoznawać problemy rekurencyjne, ale również naucz się je implementować.
8. Testowanie
Testowanie swojego kodu jest ważne. Nie chodzi tutaj wyłącznie o testy jednostkowe. Fajnie, gdy kandydat przysyła rozwiązanie z testami jednostkowymi, bo z tej perspektywy wiem, że już coś o nich słyszał. Ale nie to jest najważniejsze i bez użycia np. JUnit też kod można przetestować, a na pewno zaprezentować, jak będzie działał.
I tu wystarczy zwykle coś małego, np. kilka linijek z metody main(). To lepsze podejście niż przysyłanie implementacji bez tego. Dzięki temu fragmentowi rekruter techniczny jest w stanie ocenić kod po zachowaniu, czy kandydat dobrze zrozumiał problem i wie, jak ten kod zastosować.
Poza tym, przetestowanie takiego kodu, to też możliwość dla kandydata na dokonanie w nim poprawek. Dlatego testuj swój kod i dołączaj przykłady jego wywołania w rozwiązaniu zadania rekrutacyjnego. Z mojej perspektywy to bardzo działa na korzyść kandydata.
9. Zadbaj o jakość … przekazu
Po pierwsze. Rekrutując na stanowisko junior programisty w Javie Twoje rozwiązanie w formie kodu powinno być w pliku *.java. Nie *.txt, *.test, *.rekrutacja. Serio …
Jeśli jednak Twoje rozwiązanie przesyłasz jako fragment treści maila, a czasem tak się zdarza to zwróć uwagę na inny szczegół. Zadbaj o to, żeby ten fragment wyglądał estetycznie. Co mam na myśli? Jeśli kopiujesz kod np. z Intellij Idea i masz ustawiony Dracula Theme (a wierzę, że masz, bo to jedyny słuszny używany przez profesjonalistów 😉), to w mailu odbiorca nie powinien dostać 30 linii czarnego tekstu na czarnym tle … wyślij tego maila komuś znajomemu i sprawdź, czy wyświetla się prawidłowo.
BTW Ten żart o jedynym słusznym Dracula Theme zawsze mnie bawi, zwłaszcza, gdy ktoś poważnie uważa, że Dracula Theme daje +10 do skillsów.
Podsumowanie
Hm … wyszedł z tego całkiem długi artykuł. A dziś miało być całkiem krótko. W każdym razie, jeśli właśnie zadanie rekrutacyjne czeka na Twoje rozwiązanie to rzuć okiem na te 9 punktów:
- Brak czytania ze zrozumieniem.
- Brak dopytania o szczegóły.
- Kopia z Internetu.
- Kopia od koleżanki lub kolegi.
- Null, Stream i Predicate.
- Spring … nie jest rozwiązaniem.
- Rekurencja, czyli killer zadań rekrutacyjnych w Javie.
- Brak przetestowania.
- Jakość dostarczenia rozwiązania.
Jeśli na tej liście widzisz coś, co możesz poprawić w swoim rozwiązaniu to jest to pewnie dobry moment. Twoje zadanie rekrutacyjne może być dzięki temu lepsze, a Twoje szanse większe.
Dodałabyś lub dodałbyś coś do artykułu?
Jeśli zainteresował Cię ten temat to rzuć okiem też na Rekrutacja junior programista. 5️⃣ rad. To dobra wiedza. Mam nadzieję, że pomoże Ci zyskać wymarzoną pracę ❗❗❗
wpadłem przypadkiem ale zostanę na dłużej, parafrazując jedną z reklam 🙂
ciekawy artykuł! nie przestawaj pisać i pomagać!
Dzięki wielkie za miłe słowa 🙂
Przydatny artykuł i lekkim piórem pisany 😉
no i cóż.. lecę do kolejnych!
Dzięki za opinię. Mam nadzieję, że się również i pozostałe spodobają.
Kolejny świetny artykuł, szkoda że tak późno tu trafiłem
Dzięki za komentarz. Fajnie, że się ta wiedza przydaje 👍