Jak oswoić juniora?

Jak dostać się do dużej firmy, jeśli jesteś juniorem? Jak zatrudnić odpowiedniego juniora, będąc dużą firmą? Pod cut-em opowiem naszą historię zatrudniania początkujących programistów frontendowych: jak opracowywaliśmy testowe zadania, przygotowywaliśmy się do przeprowadzania rozmów kwalifikacyjnych oraz budowaliśmy program mentorskich dla rozwoju i onboardingu nowicjuszy, a także dlaczego standardowe pytania do wywiadów nie działają.

Próbuję oswoić juniora.

Cześć! Mam na imię Paweł, zajmuję się frontendem w zespole Wrike. Tworzymy system do zarządzania projektami i współpracy. Zajmuję się webem od 2010 roku, przez 3 lata pracowałem na zagranicznej, zdalnej posadzie, brałem udział w kilku startupach i prowadziłem kurs dotyczący technologii internetowych na uniwersytecie. W firmie uczestniczę w rozwijaniu technicznych kursów oraz programu mentorskiego Wrike dla juniorów, a także bezpośrednio w ich rekrutacji.

Dlaczego w ogóle pomyśleliśmy o zatrudnianiu juniorów?

Do niedawna zatrudnialiśmy programistów frontendowych na poziomie mid lub senior — dość samodzielnych, aby po onboardingu móc realizować zadania produktowe. Na początku tego roku zrozumieliśmy, że chcemy zmienić tę politykę: w ciągu roku liczba naszych zespołów produktowych zwiększyła się prawie dwukrotnie, liczba frontendowców zbliżyła się do setki, a w niedalekiej przyszłości wszystko to powinno się ponownie podwoić. Pracy jest dużo, wolnych rąk mało, a na rynku jest ich jeszcze mniej, dlatego postanowiliśmy zgłosić się do osób, które dopiero zaczynają swoją przygodę z frontendem i doszliśmy do wniosku, że jesteśmy gotowi inwestować w ich rozwój.

Kim jest junior?

To pierwsze pytanie, które sobie zadaliśmy. Istnieją różne kryteria, ale najprostsza i najbardziej zrozumiała zasada jest taka:

Junior potrzebuje wyjaśnienia, jaką funkcję i jak wykonać. Midlowi trzeba wyjaśnić, jaka funkcja jest potrzebna, a on sam poradzi sobie z realizacją. Senior sam wyjaśni, dlaczego tej funkcji w ogóle nie należy realizować.

Tak czy inaczej, junior to ten programista, który potrzebuje porady, jak dokładnie zrealizować dane rozwiązanie. Oto na czym się opieraliśmy:

1. Junior to ktoś, kto chce się rozwijać i jest gotów do ciężkiej pracy;
2. Nie zawsze wie, w jakim kierunku chce się rozwijać;
3. Potrzebuje porady i szuka pomocy na zewnątrz — u swojego lidera, mentora lub w społeczności.

Mieliśmy także kilka hipotez:

1. Na stanowisko juniora będzie sztorm zgłoszeń. Należy filtrować przypadkowe aplikacje już na etapie wysyłania CV;
2. Wstępny filtr nie pomoże — potrzebne są jeszcze zadania testowe;
3. Zadania testowe wszystkich przestraszą — nie są potrzebne.

Oczywiście mieliśmy także cel: 4 juniorów w 3 tygodnie.

Z tym świadomością zaczęliśmy eksperymentować. Plan był prosty: zacząć z jak najszerszym lejem i stopniowo go zwężać, aby nadążać z przetwarzaniem napływu, ale nie sprowadzać go do 1 kandydata na tydzień.

Ogłaszamy ofertę pracy

Dla firmy: Będzie setki zgłoszeń! Pomyślcie o filtrze.

Dla juniora: Nie bójcie się ankiety przed wysłaniem CV i zadań testowych — to znak, że firma dba o Was i dobrze zorganizowała proces.

Już w pierwszym dniu otrzymaliśmy około 70 CV od kandydatów „znających JavaScript”. A potem jeszcze. I jeszcze. Fizycznie nie mogliśmy zaprosić wszystkich na rozmowy kwalifikacyjne w biurze i wybraliśmy z nich osoby z najbardziej interesującymi projektami, aktywnym GitHubem lub przynajmniej doświadczeniem.

Ale główny wniosek, który wyciągnęliśmy już w pierwszym dniu — sztorm się rozpoczął. Nadszedł czas na dodanie formularza ankiety przed wysłaniem CV. Jego zadaniem było odfiltrować kandydatów, którzy nie są gotowi włożyć minimalnego wysiłku w wysłanie CV, oraz tych, którzy nie posiadają wiedzy i kontekstu na tyle, aby wyszukać poprawne odpowiedzi.

Zawierał standardowe pytania o JS, front-end, web, Computer Science — zna je każdy, kto ma pojęcie, co się pyta na rozmowie kwalifikacyjnej na frontendzie. Jaka jest różnica między let/var/const? Jak zastosować style tylko dla ekranów o szerokości mniejszej niż 600px? Nie chcieliśmy zadawać tych pytań na rozmowie technicznej — praktyka pokazała, że na nie można odpowiedzieć po 2-3 rozmowach kwalifikacyjnych, nie mając pojęcia o programowaniu. Ale z drugiej strony mogły one początkowo pokazać nam, czy kandydat w ogóle rozumie kontekst.

W każdej kategorii przygotowaliśmy po 3-5 pytań i dzień po dniu zmienialiśmy ich zestaw w formularzu zgłoszeniowym, aż nie wyeliminowaliśmy najprostszych i najtrudniejszych. To pozwoliło nam ograniczyć napływ — w ciągu 3 tygodni otrzymaliśmy 122 kandydatów, z którymi można było dalej współpracować. Byli to studenci IT; chłopaki, którzy chcieli przejść z backendu na frontend; pracownicy lub inżynierowie w wieku 25-35 lat, którzy radykalnie pragnęli zmienić swoją profesję i włożyli różną ilość siły w samokształcenie, kursy i staże.

Poznajmy się bliżej

Dla firmy: Zadanie testowe nie odstrasza kandydatów, ale pomaga skrócić proces rekrutacji.

Dla juniora: Nie kopiujcie testów — to jest zauważalne. I dbajcie o swoje GitHub!

Gdybyśmy zaprosili wszystkich na techniczne rozmowy, musielibyśmy przeprowadzać około 40 rozmów w tygodniu tylko z juniorami i tylko w frontendzie. Dlatego zdecydowaliśmy się sprawdzić drugą hipotezę — o zadaniu testowym.

Co było dla nas ważne w teście:

1. Zbudować dobrą skalowalną architekturę, ale bez nadmiernego inżynieryjstwa;
2. Lepiej robić dłużej, ale dobrze, niż w nocy sklecić coś na szybko i wysłać z komentarzem „na pewno dokończę”;
3. Historia rozwoju w Gicie — kultura inżynieryjna, iteracyjność rozwoju i to, że rozwiązanie nie jest po prostu skopiowane.

Zgodziliśmy się, że chcemy zobaczyć jedno zadanie algorytmiczne i małą aplikację webową. Zadania algorytmiczne były przygotowane na poziomie laboratoriów pierwszych kursów — wyszukiwanie binarne, sortowanie, sprawdzanie na anagramy, praca z listami i drzewami. Ostatecznie zatrzymaliśmy się na wyszukiwaniu binarnym jako pierwszej próbie. Aplikacją webową miały być kółko-krzyżyk przy użyciu dowolnego frameworka (lub bez niego).

Zadanie testowe wykonała prawie połowa z pozostałych chłopaków — otrzymaliśmy rozwiązania 54 kandydatów. Niesamowity wgląd — ile myślicie, że jest realizacji kółka-krzyżyka gotowych do kopiowania w sieci?

Ile?Tak naprawdę wydaje się, że tylko 3. I w przytłaczającej większości rozwiązań były właśnie te 3 warianty.
Co mi się nie podoba:

• kopiowanie, lub rozwój według tego samego samouczka bez własnej architektury;
• obie zadania w jednym repozytorium w różnych folderach, oczywiście bez historii commitów;
• brudny kod, naruszenie zasady DRY, brak formatowania;
• mieszanka modelu, widoku i kontrolera w jednej klasie o długości setek linii kodu;
• brak zrozumienia testów jednostkowych;
• Rozwiązanie „na twardo” — hardkod macierzy zwycięskich kombinacji 3x3, co będzie dość trudno rozszerzyć do 10x10, na przykład.

Zwracaliśmy też uwagę na sąsiednie repozytoria — fajne projekty pet przynosiły zyski, a wiele testowych zadań od innych firm było raczej dzwonkiem ostrzegawczym: dlaczego kandydat nie przeszedł tam?

Ostatecznie znaleźliśmy świetne opcje na React, Angular, Vanilla JS — uzbierało się ich 29. A jednego kandydata postanowiliśmy zaprosić bez testu ze względu na jego bardzo dobre projekty pet. Nasza hipoteza o użyteczności testów potwierdziła się.

Rozmowa techniczna

Dla firmy: To nie są midy/seniorzy! Potrzebujemy więcej indywidualnego podejścia.

Dla juniora: Pamiętajcie, że to nie jest egzamin — nie starajcie się milczeć na trójkę lub zalać profesora strumieniem wszystkich swoich możliwych wiedzy, żeby się pogubił i dał „doskonały” wynik.

Co chcemy zrozumieć na rozmowie technicznej? Jedną prostą rzecz — jak myśli kandydat. Prawdopodobnie ma jakieś twarde umiejętności, jeśli przeszedł pierwsze etapy selekcji — trzeba tylko ustalić, czy potrafi je zastosować. Uzgodniliśmy 3 zadania.

Pierwsze — o algorytmach i strukturach danych. Pisemnie, na kartce, w pseudojęzyku i za pomocą rysunków rozważaliśmy, jak skopiować drzewo lub jak usunąć element z listy jednokierunkowej. Niemiłym odkryciem okazało się, że nie wszyscy rozumieją rekurencję i jak działają wskaźniki.

Drugie — live coding. Wchodziliśmy na codewars.com, wybieraliśmy proste zadania, takie jak sortowanie tablicy słów według ostatniej litery i przez 30-40 minut wspólnie z kandydatem staraliśmy się, aby wszystkie testy zostały zaliczone. Wydawało się, że nie powinno być niespodzianek od ludzi, którzy poradzili sobie z kółkiem-krzyżykiem — ale w praktyce nie wszyscy zrozumieli, że wartość należy zachować w zmiennej, a funkcja powinna coś zwracać przez return. Choć szczerze mam nadzieję, że to był stres i że koledzy poradzili sobie z tymi zadaniami w bardziej komfortowych warunkach.

W końcu trzecie — trochę o architekturze. Dyskutowaliśmy, jak można stworzyć pasek wyszukiwania, jak działa debounce, jak renderować różne widgety w sugestiach wyszukiwania, jak frontend może współpracować z backendem. Pojawiło się sporo interesujących rozwiązań, w tym dotyczących renderowania po stronie serwera i WebSocketów.

Przeprowadziliśmy 21 wywiad w takiej formie. Publiczność była całkowicie różnorodna — spróbujmy na komiksach:

1. „Rakieta”. Nigdy się nie uspokaja, we wszystkim się wtrąca, a na wywiadzie zasypie cię strumieniem myśli, które niekoniecznie są związane z zadanym pytaniem. Gdyby to miało miejsce na uniwersytecie, wielu temu mogłoby być znane, próbując pokazać wszystkie swoje wiedzę, gdy tylko masz bilet, o którym pamiętasz, że wczoraj wieczorem postanowiłeś się go nie uczyć — tak czy inaczej nie wyciągniesz.
2. „Groot”. Z nim trudno nawiązać kontakt, bo sam jest Grootem. Na wywiadzie trzeba długo rozgrzewać, wydobywać odpowiedzi słowo po słowie. Dobrze, jeśli to tylko zator — w przeciwnym razie w codziennej pracy będzie ci bardzo ciężko.
3. „Drax”. Wcześniej zajmował się transportem, a z programowania uczył się tylko JS z Stackoverflow, więc nie zawsze rozumie, o czym w ogóle mowa na rozmowie kwalifikacyjnej. Mimo to, to dobry człowiek, ma najlepsze intencje i chce zostać świetnym frontendowcem.
4. No i pewnie, „Star-Lord”. Ogólnie, niezły kandydat, z którym można się dogadać i zbudować dialog.

Pod koniec naszych badań 7 kandydatów dotarło do finału, potwierdzając swoje umiejętności techniczne świetnym zadaniem testowym i dobrymi odpowiedziami na wywiad.

Dopasowanie kulturowe

Dla firmy: Będziesz z nim pracować! Czy kandydat jest gotów pracować ekstremalnie dużo dla swojego rozwoju? Czy wpasuje się w zespół?

Dla juniora: Będziecie z nimi pracować! Czy firma jest gotowa inwestować w rozwój juniorów, czy po prostu zrzuci na was całą brudną robotę za niską pensję?

Każdy junior, poza zespołem produktowym, którego lider musi zgodzić się go przyjąć, ma mentora. Zadaniem mentora jest poprowadzić go przez trzy miesiące onboardingu i rozwijania umiejętności technicznych. Dlatego na każde dopasowanie kulturowe przychodziliśmy jako mentorzy i zadawaliśmy sobie pytanie: „Czy wezmę na siebie odpowiedzialność za rozwijanie kandydata przez 3 miesiące według naszego planu?”

Ten etap przebiegał bez szczególnych wydarzeń i ostatecznie przyniósł nam 4 oferty, 3 z nich zostały przyjęte i chłopaki dołączyli do zespołów.

Życie po ofercie

Dla firmy: Zadbaj o swoich juniorów, albo zrobią to inni!

Dla juniora: AAAAAA!!!

Gdy nowy pracownik przychodzi do firmy, należy go onboardować — zapoznać z procesami, wyjaśnić, jak wszystko działa w firmie i w zespole oraz jak ma pracować. W przypadku juniora ważne jest, aby zrozumieć, jak go rozwijać.

Kiedy zaczęliśmy nad tym myśleć, stworzyliśmy listę 26 umiejętności, którymi, naszym zdaniem, powinien dysponować junior na koniec trzy miesięcznego okresu onboardingu. Znalazły się tam umiejętności techniczne (według naszego stosu technologii), wiedza o naszych procesach, scramie, infrastrukturze i architekturze projektu. Połączyliśmy je w roadmap, rozłożony w czasie na 3 miesiące.

Na przykład, oto roadmap mojego juniora.

Każdemu juniorowi przydzielamy mentora, który pracuje z nim w trybie indywidualnym. W zależności od mentora i aktualnego poziomu kandydata spotkania mogą odbywać się od 1 do 5 razy w tygodniu przez 1 godzinę. Mentorami zostają dobrowolnie proaktywni front-endowcy, którzy chcą robić coś więcej niż tylko pisać kod.

Część obciążenia z mentorów przejmują kursy dotyczące naszego stosu technologicznego — Dart, Angular. Kursy są regularnie organizowane dla małych grup 4-6 osobowych, gdzie uczestnicy pracują bez przerw.

Przez 3 miesiące regularnie zbieramy opinie od juniorów, ich mentorów oraz liderów i dostosowujemy proces indywidualnie. 1-2 razy w całym okresie przeprowadzamy weryfikację rozwiniętych umiejętności, podobne sprawdzenie dokonuje się na koniec — na tej podstawie formułowane są rekomendacje, co należy jeszcze poprawić.

Podsumowanie

Dla firmy: Czy warto inwestować w juniorów? Tak!

Dla juniora: Szukaj firm, które starannie wybierają kandydatów i wiedzą, jak ich rozwijać.

W ciągu 3 miesięcy przejrzeliśmy 122 kwestionariusze, 54 zadania testowe i przeprowadziliśmy 21 technicznych wywiadów. To przyniosło nam 3 świetnych juniorów, którzy teraz przeszli połowę swoich roadmapów onboardingu i akceleracji. Już rozwiązują rzeczywiste zadania produktowe w naszym projekcie, gdzie tylko na front-endzie znajduje się ponad 2 000 000 linii kodu i ponad 400 repozytoriów.

Udało nam się ustalić, że lejek dla juniorów może i powinien być wystarczająco skomplikowany, ale ostatecznie przechodzą przez niego tylko ci ludzie, którzy naprawdę są gotowi bardzo ciężko pracować i inwestować w swój rozwój.

Obecnie naszym głównym celem jest zakończenie trzy miesięcznych planów rozwoju dla każdego juniora, w trybie indywidualnej pracy z mentorem oraz wspólnych kursów, zebranie metryk, feedbacku od liderów, mentorów oraz samych juniorów. Na tym etapie pierwszy eksperyment można będzie uznać za zakończony, wyciągnąć wnioski, poprawić proces i rozpocząć go na nowo dla selekcji nowych kandydatów.

Źródło: habr.com