Rekrutacja frontend developer

Opublikowane przez lewy w dniu

Temat przewijający się w internetach strasznie często, ale myślę że każdy punkt widzenia wart jest poznania, może akurat trafi się coś nowego.

Od mniej więcej półtora roku w firmie w której pracuję biorę udział w rekrutacjach. Jako jeden z liderów teamów frontendowych zostałem poproszony o przygotowanie kilku pytań które zweryfikują kandydata i pozwolą nam stwierdzić po pierwsze czy jesteśmy zainteresowani, a po drugie zbadać aktualną wiedzę i poziom. Sam w przeszłości odbyłem jakieś rozmowy (akurat na programistę Java) i pamiętając co mi najbardziej przeszkadzało starałem się nie popełnić pytań w stylu „sztuka dla sztuki i pokażę Ci jaki jesteś słaby”. Najlepszy przykład to:
kawałek kodu a w odpowiedziach możliwości:
– wyjątek X podczas kompilacji kodu
– kompilacja poprawna, wyjątek Y podczas działania aplikacji
– kompilacja i działanie aplikacji poprawne
no kto normalny ma kompilator w głowie wraz z możliwymi wyjątkami które to mogą zostać zwrócone w konkretnych przypadkach.

Jako że praca u nas na pozycji frontend developera to 90% programowanie a 10% wygląd to dość naturalnym jest, że pytania poszły w kierunku JavaScript a nie HTML i CSS.

Na początku jak dostaniemy zgłoszenie to po zapoznaniu się z nim, kandydat dostaje proste zadanie do napisania. Najczęściej dajemy dwa weekendy na przysłanie rozwiązania. Kod który otrzymujemy już na początku może sporo powiedzieć o kandydacie, jakie ma nawyki, na co zwraca uwagę. Przy zadaniu nie mamy żadnych wymagań jeżeli chodzi o frameworki, bo wychodzę z założenia że jeżeli ktoś zna język, umie programować, skorzysta z jakiegoś frameworka to przyswojenie frameworka z którego my korzystamy nie powinno stanowić wielkiego problemu. Natomiast narzucamy że aplikacja ma być napisana przy wykorzystaniu JavaScript/TypeScript, npma i dla zapewnienia podstawowego wyglądu należy użyć bootstrapa. Zadanie takie też jest dobrym wkładem na rozmowę kwalifikacyjną, jeżeli się na nią zdecydujemy, czy jest coś co by Pan/Pani poprawiła (napisała lepiej) gdyby było więcej czasu, dlaczego w taki sposób zrobione to, itp.

Po omówieniu zadania przechodzimy do pytań technicznych. Mamy rok który mamy, JS zaczyna jakoś wyglądać, ES w wersji 6 istnieje na ryku już jakiś czas to na rozruszanie kandydata proponuję pytanie jaka jest różnica między let i var i ku mojemu zaskoczeniu połowa się na tym pytaniu wykłada (i nie jest to grono tylko kandydatów na juniora), ktoś zaczyna mi mówić że let jest do zmiennych a const mamy do stałych (wtf? nie pytałem o consta), sporo osób kojarzy że let jest lokalny a var globalny, niestety to nie do końca prawda. OK stres zjadł od następnego pytania będzie lepiej.

I tu leci pytanie o hoisting. Wydawać by się mogło, że pewniak na rozmowie kwalifikacyjnej na programistę JS. Wydawać by się mogło, że jak idzie się na rozmowę to coś tam w internecie się sprawdzi o co mogą zapytać i pewnie 95% źródeł rzuci ten temat, a rzeczywistość jest taka że może lekko trochę ponad połowa pytanych osób kojarzy temat. Uwaga tutaj mały hint, mnie osobiście strasznie zdziwił ale raz mi się trafiło, kandydat mówi że nie kojarzy, mówię o co chodzi i dostaję odpowiedź ja to znałem jako „windowanie”…

Kolejna rzecz o którą pytam, jakie mamy sposoby zapisu funkcji w JS i jakie są różnice. Najczęstsza odpowiedź to że mamy „normalną” funkcję i arrow function. Co prawda nie o to mi chodzi, dlatego szybko wykładam karteczkę z kawałkiem kodu (do każdego pytania posiadam prosty kawałek kodu (3-15 linijek) który może rozjaśnić pytanie i ułatwić odpowiedź). W pytaniu tym oczywiście chodzi mi o to, że funkcje możemy zapisać jako deklarację i jako wyrażenie oraz jaka jest między nimi różnica.
Pytanie o arrow function jest osobnym pytaniem, co to jest, jak wygląda, czym się różni od „normalnej” funkcji.

Następne pytanie jest o to, jak działają operatory logiczne i to jest chyba najbardziej podchwytliwe pytanie ze wszystkich, poprawnie odpowiedziało mi może 15% osób. Temat dla mnie jest na tyle ciekawy, że szerzej o nim w następnym wpisie.

Kolejne pytania podnoszą poziom i mają głównie za cel sprawdzenie czy mamy do czynienia z bardziej zaawansowanymi/ambitnymi osobami i czy w krótkim czasie możemy spodziewać się ich progresu, albo nawet od razu zatrudnienia na wyższe stanowisko niż junior.
Pytania te to:
– setTimeout jak działa
– destrukturyzacja (destructuring assignment, spread operator)
– rest parameters w funkcji
– this i jego kontekst
– domknięcia (closure)

Po sekcji pytań bardzo technicznych wpadają jeszcze pytania bardziej ogólne.
– programowanie obiektowe, czy kandydat miał styczność, jakie ma cechy, dodatkowe pytania o dziedziczenie, hermetyzację czy polimorfizm
– TypeScript, czy słyszał, korzystał, jeżeli tak jakie największe zalety widzi
– programowa reaktywne, co to, czym się charakteryzuje
– programowanie funkcyjne (jako dość głośny temat ostatnimi czasy, choć sam nie do końca pojmuję ten fenomen) i tu przestroga, nie chodzi o to, aby odpowiedzieć że program wykonuje się funkcja po funkcji…
– pytanie o gita, czy zna/korzystał, w jak dużym zespole
– npm, co to i czy korzysta
– sass, czy słyszał/zna/korzysta

Na koniec jeszcze moje ogólne uwagi/ostrzeżenia/rady.
Jeżeli dostajecie zadanie w którym jest napisane, że aplikacja ma działać tak i tak, a nie jest wymagane żeby robiła to, to skupcie się na napisaniu aby działała tak jak tego od was wymagają, aby kod był czytelny, aby to jakoś wyglądało a jak starczy czasu to zacznijcie robić „wodotryski”, bo niestety umieszczenie w treści zadania że coś jest nie wymagane nie wiadomo dlaczego uruchamia u ludzi trigger i skupienie się na tym czymś zamiast na jakości kodu i poprawnym działaniu podstawowych zachowań.
Druga sprawa to naprawdę proponuję przed pójściem na rozmowę zapytać wujka googla o co pytają na rozmowie kwalifikacyjnej na frontend developera, tego jest pełno w sieci a brak znajomości różnicy pomiędzy let a var czy pojęcia hoisting dla mnie jest dość mocnym sygnałem, że kandydat przed rozmową nie zrobił nic aby się na nią przygotować.
Ostatnia sprawa to przesyłane CV, też temat przewijający się wszędzie, nie warto kłamać, nie warto wpisywać na wyrost, dziś nie przyjmuje się już każdego jak leci, a wiedza jest na rozmowach weryfikowana. Jeżeli ktoś ma 2 lata doświadczenia w pracy programisty frontend to fajnie, ale nie znaczy to że ma (bardzo) dobrą znajomość języka JavaScript, a taki wpis przynajmniej w moim przypadku załącza trigger „sprawdzam”, a potem załamka bo ten hoisting nie do końca, bo nie wiem jak działa setTimeout, bo nie wiem jakie są różnice między „normalną” funkcją a arrow function.

I na koniec, wiem że się łatwo mówi, ale na prawdę nie stresujcie się, po drugiej stronie też są ludzie, trochę pokombinujcie przy odpowiedziach (ale na temat), spróbujcie się sprzedać i nawet jak wam nie wyjdzie to starajcie się jak najwięcej z takiej rozmowy wyciągnąć aby uniknąć błędów na przyszłość.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *