Jak oswoić juniora?

Jak dostać się do dużej firmy będąc juniorem? Jak zatrudnić porządnego juniora, jeśli jesteś dużą firmą? Poniżej opowiem naszą historię zatrudniania początkujących na froncie: jak przepracowaliśmy zadania testowe, przygotowaliśmy się do przeprowadzenia rozmów kwalifikacyjnych i zbudowaliśmy program mentorski dotyczący rozwoju i onboardingu nowicjuszy, a także dlaczego standardowe pytania podczas rozmowy kwalifikacyjnej nie działają nie działa.

Próbuję oswoić Juniora

Cześć! Nazywam się Pavel, zajmuję się pracą front-endową w zespole Wrike. Tworzymy system do zarządzania projektami i współpracy. W sieci pracuję od 2010 roku, przez 3 lata pracowałem za granicą, brałem udział w kilku start-upach i prowadziłem kurs z technologii internetowych na uniwersytecie. W firmie zajmuję się rozwojem kursów technicznych oraz programu mentorskiego Wrike dla juniorów, a także bezpośrednio ich rekrutuję.

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

Do niedawna do frontendu rekrutowaliśmy programistów średniego lub wyższego szczebla – na tyle niezależnych, aby po onboardingu wykonywać zadania produktowe. Na początku tego roku zdaliśmy sobie sprawę, że chcemy zmienić tę politykę: w ciągu roku liczba naszych zespołów produktowych prawie się podwoiła, liczba programistów front-endowych zbliżyła się do setki, a w najbliższej przyszłości to wszystko trzeba znowu podwoić. Pracy jest dużo, mało wolnych rąk, a na rynku jest ich jeszcze mniej, dlatego postanowiliśmy zwrócić się do chłopaków, którzy dopiero rozpoczynają swoją drogę na froncie i zdali sobie sprawę, że jesteśmy gotowi zainwestować 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 następująca:

Trzeba wyjaśnić Juniorowi, jaką funkcję i jak to zrobić. Środkowi trzeba wyjaśnić, jaka funkcja jest potrzebna, a on sam wymyśli implementację. Sam podpisujący wyjaśni Ci, dlaczego tej funkcji w ogóle nie trzeba wykonywać.

Tak czy inaczej junior to programista, który potrzebuje porady, jak wdrożyć to czy tamto rozwiązanie. Na czym postanowiliśmy zbudować:

1. Junior to ktoś, kto chce się rozwijać i jest gotowy na ciężką pracę, aby to osiągnąć;
2. Nie zawsze wie, w jakim kierunku chce się rozwijać;
3. Potrzebuje porady i szuka pomocy z zewnątrz – u swojego lidera, mentora lub w społeczności.

Mieliśmy też kilka hipotez:

1. Będzie burza reakcji na stanowisko czerwca. Losowe odpowiedzi musisz filtrować już na etapie wysyłania CV;
2. Filtr główny nie pomoże. — potrzeba więcej zadań testowych;
3. Zadania testowe odstraszą wszystkich - nie są potrzebne.

I oczywiście mieliśmy cel: 4 juniorów w 3 tygodnie.

Mając tę ​​świadomość, zaczęliśmy eksperymentować. Plan był prosty: zacznij od jak najszerszego lejka i staraj się go stopniowo zawężać, aby móc przetworzyć przepływ, ale nie ograniczać go do 1 kandydata tygodniowo.

Ogłaszamy wakat

Dla firmy: Będą setki odpowiedzi! Pomyśl o filtrze.

Dla juniora: Nie bój się ankiety przed wysłaniem CV i zadania testowego – to znak, że firma się Tobą zaopiekowała i dobrze przygotowała cały proces.

Pierwszego dnia otrzymaliśmy około 70 CV od kandydatów „ze znajomością JavaScript”. A potem jeszcze raz. I dalej. Fizycznie nie mogliśmy zaprosić wszystkich do biura na rozmowę kwalifikacyjną i wybrać spośród nich chłopaków z najfajniejszymi projektami domowymi, działającymi na Githubie lub przynajmniej doświadczeniem.

Ale głównym wnioskiem, jaki wyciągnęliśmy już pierwszego dnia, było to, że zaczęła się burza. Nadszedł czas, aby przed przesłaniem CV dodać formularz kwestionariusza. Jej celem było wyeliminowanie kandydatów, którzy nie chcieli włożyć minimalnego wysiłku w przesłanie CV oraz tych, którzy nie mieli wiedzy i kontekstu, aby przynajmniej w Google znaleźć prawidłowe odpowiedzi.

Zawierały standardowe pytania dotyczące JS, układu, webu, informatyki – zna je każdy, kto wyobraża sobie, o co pytają na rozmowie kwalifikacyjnej. Jaka jest różnica między let/var/const? Jak mogę zastosować style tylko do ekranów o szerokości mniejszej niż 600 pikseli? Nie chcieliśmy zadawać tych pytań na rozmowie technicznej - praktyka pokazała, że ​​można na nie odpowiedzieć po 2-3 rozmowach kwalifikacyjnych, nie rozumiejąc w ogóle rozwoju. Ale początkowo byli w stanie pokazać, czy kandydat w zasadzie rozumie kontekst.

W każdej kategorii przygotowaliśmy po 3-5 pytań i dzień po dniu zmienialiśmy ich zestaw w formie odpowiedzi, aż wyeliminowaliśmy te najbardziej zadowalające i najtrudniejsze. Pozwoliło nam to zmniejszyć przepływ - w ciągu 3 tygodni otrzymaliśmy 122 kandydatów, z którym moglibyśmy dalej pracować. Byli to studenci informatyki; chłopaki, którzy chcieli przejść na przód z backendu; robotnicy lub inżynierowie w wieku 25-35 lat, którzy radykalnie chcieli zmienić zawód i wkładać różny wysiłek w samokształcenie, kursy i staże.

Poznawanie się lepiej

Dla firmy: Zadanie testowe nie odstrasza kandydatów, ale pomaga skrócić ścieżkę.

Dla juniora: Nie kopiuj i wklejaj testowych - jest to zauważalne. I utrzymuj porządek na Githubie!

Gdybyśmy wszystkich zaprosili na rozmowę techniczną, musielibyśmy przeprowadzić około 40 rozmów tygodniowo tylko dla juniorów i tylko na froncie. Dlatego postanowiliśmy przetestować drugą hipotezę – dotyczącą zadania testowego.

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

1. Zbuduj dobrą skalowalną architekturę, ale bez nadmiernej inżynierii;
2. Lepiej zająć więcej czasu, ale zrobić to dobrze, niż z dnia na dzień złożyć rękodzieło i wysłać z komentarzem „Na pewno to skończę”;
3. Historia rozwoju w Git to kultura inżynieryjna, iteracyjny rozwój i to, że rozwiązanie nie zostało rażąco skopiowane.

Uzgodniliśmy, że chcemy przyjrzeć się jednemu problemowi algorytmicznemu i małej aplikacji internetowej. Algorytmiczne zostały przygotowane na poziomie laboratoriów na poziomie podstawowym - wyszukiwanie binarne, sortowanie, sprawdzanie anagramów, praca z listami i drzewami. Ostatecznie zdecydowaliśmy się na wyszukiwanie binarne jako pierwszą opcję próbną. Aplikacja internetowa musiała przebiegać w kółko i krzyżyk przy użyciu dowolnego frameworka (lub bez niego).

Prawie połowa pozostałych chłopaków wykonała zadanie testowe i przesłała nam rozwiązania 54 kandydatów. Niesamowity wgląd - ile wdrożeń gry w kółko i krzyżyk, gotowych do kopiuj-wklej, myślisz, że jest w Internecie?

Ile?Tak naprawdę wydaje się, że jest ich tylko 3. I w zdecydowanej większości decyzji były właśnie te 3 opcje.
Co nie podobało się:

• kopiuj-wklej lub programowanie oparte na tym samym samouczku bez własnej architektury;
• oba zadania znajdują się w tym samym repozytorium w różnych folderach, oczywiście nie ma historii zatwierdzeń;
• brudny kod, naruszenie DRY, brak formatowania;
• połączenie modelu, widoku i kontrolera w jedną klasę o długości setek linii kodu;
• brak zrozumienia testów jednostkowych;
• rozwiązaniem „head-on” jest twardy kod macierzy 3x3 zwycięskich kombinacji, którą dość trudno będzie rozszerzyć na przykład do 10x10.

Zwróciliśmy także uwagę na sąsiednie repozytoria – fajne projekty zwierzaków były plusem, a masa zadań testowych z innych firm była raczej sygnałem alarmowym: dlaczego kandydat nie mógł się tam dostać?

W rezultacie znaleźliśmy fajne opcje w React, Angular, Vanilla JS - było ich 29. I postanowiliśmy zaprosić jeszcze jednego kandydata bez testowania na jego bardzo fajne projekty domowe. Potwierdziła się nasza hipoteza o korzyściach płynących z zadań testowych.

Wywiad techniczny

Dla firmy: To nie średni/seniorzy przyszli do Ciebie! Potrzebujemy bardziej indywidualnego podejścia.

Dla juniora: Pamiętaj, że to nie jest egzamin - nie staraj się milczeć, żeby otrzymać C, ani nie bombarduj profesora strumieniem całej swojej wiedzy, aby się zdezorientował i dał ocenę „doskonałą”.

Co chcemy zrozumieć w rozmowie technicznej? Rzecz prosta – jak myśli kandydat. Pewnie ma jakieś twarde umiejętności, jeśli przeszedł pierwsze etapy selekcji – czas pokaże, czy będzie umiał je wykorzystać. Uzgodniliśmy 3 zadania.

Pierwsza dotyczy algorytmów i struktur danych. Za pomocą pióra, na kartce papieru, w pseudojęzyku i za pomocą rysunków wymyśliliśmy, jak skopiować drzewo lub jak usunąć element z listy z pojedynczym łączem. Nieprzyjemnym odkryciem było to, że nie każdy rozumie rekurencję i działanie referencji.

Drugim jest kodowanie na żywo. Poszliśmy do codewars.com, wybierał proste rzeczy, takie jak sortowanie tablicy słów według ostatniej litery i przez 30-40 minut wspólnie z kandydatem starali się, aby wszystkie testy zaliczyły pozytywnie. Wydawało się, że po opanowaniu gry w kółko i krzyżyk nie powinno być niespodzianek - jednak w praktyce nie każdemu udało się zdać sobie sprawę, że wartość należy przechowywać w zmiennej, a funkcja powinna coś zwracać w zamian. Choć mam szczerą nadzieję, że to była trema i chłopaki poradzili sobie z tymi zadaniami w lżejszych warunkach.

Wreszcie trzeci jest trochę o architekturze. Omówiliśmy, jak utworzyć pasek wyszukiwania, jak działa usuwanie odbić, jak renderować różne widżety we wskazówkach dotyczących wyszukiwania, jak frontend może współdziałać z backendem. Nie zabrakło ciekawych rozwiązań, m.in. renderowania po stronie serwera i gniazd sieciowych.

W tym schemacie przeprowadziliśmy 21 wywiadów. Publiczność była całkowicie zróżnicowana - spójrzmy na komiksy:

1. "Rakieta". Nigdy się nie uspokaja, we wszystko angażuje, a podczas rozmowy zasypie potokiem myśli, które nie mają nawet bezpośredniego związku z zadanym pytaniem. Gdyby to było na uniwersytecie, byłaby to znajoma próba wykazania się, no cóż, całą swoją wiedzą, podczas gdy jedyne, co pamiętasz z biletu, na który natrafiłeś, to to, że wczoraj wieczorem zdecydowałeś się go nie uczyć – nadal nie możesz dostać to wyszło.
2. „Groot”. Dość trudno się z nim skontaktować, bo to Groot. Podczas rozmowy kwalifikacyjnej musisz spędzić dużo czasu, próbując uzyskać odpowiedzi słowo po słowie. Dobrze, jeśli to tylko odrętwienie - w przeciwnym razie będzie Ci bardzo trudno w codziennej pracy.
3. „Draks”. Pracowałem kiedyś w transporcie cargo, a jeśli chodzi o programowanie, JS uczyłem się dopiero na Stackoverflow, więc nie zawsze rozumiem, o czym mowa na rozmowie kwalifikacyjnej. Jednocześnie jest dobrym człowiekiem, ma najlepsze intencje i chce zostać świetnym front-end developerem.
4. Prawdopodobnie będziemy "Gwiezdny władca". Ogólnie dobry kandydat, z którym można negocjować i budować dialog.

Na koniec naszych badań 7 kandydatów dotarli do finału, potwierdzając swoje twarde umiejętności świetnym zadaniem testowym i dobrymi odpowiedziami na rozmowie kwalifikacyjnej.

Dopasowanie kulturowe

Dla firmy: Pracujesz z nim! Czy kandydat jest gotowy do niezwykle ciężkiej pracy na rzecz swojego rozwoju? Czy naprawdę wpasuje się w zespół?

Dla juniora: Pracujesz z nimi! Czy firma jest naprawdę gotowa inwestować w rozwój młodych pracowników, czy po prostu zrzuci na Ciebie całą brudną robotę za niską pensję?

Każdy junior, oprócz zespołu produktowego, którego lider musi zgodzić się na jego przyjęcie, otrzymuje mentora. Zadaniem mentora jest przeprowadzenie go przez trzymiesięczny proces onboardingu i podnoszenia kompetencji twardych. Dlatego też podeszliśmy do każdego dopasowania kulturowego jako mentorzy i odpowiedzieliśmy na pytanie: „Czy wezmę odpowiedzialność za rozwój kandydata w 3 miesiące zgodnie z naszym planem?”

Ten etap minął bez żadnych specjalnych cech i ostatecznie doprowadził nas 4 oferty, z czego 3 zostały przyjęte, a chłopaki weszli do drużyn.

Życie po ofercie

Dla firmy: Zaopiekuj się swoimi juniorami, albo zrobią to inni!

Dla juniora:AAAAAAAAAA!!!

Kiedy wychodzi nowy pracownik, trzeba go wdrożyć – zapoznać z procesami, powiedzieć, jak wszystko działa w firmie i w zespole, i jak w ogóle powinien pracować. Kiedy junior wychodzi na boisko, musisz zrozumieć, jak go rozwijać.

Kiedy się nad tym zastanowiliśmy, powstała lista 26 umiejętności, które naszym zdaniem powinien posiadać junior do końca trzymiesięcznego okresu onboardingu. Obejmowały one umiejętności twarde (według naszego stosu), znajomość naszych procesów, Scruma, infrastruktury i architektury projektu. Połączyliśmy je w plan działania rozłożony na 3 miesiące.

Oto na przykład plan działania mojego juniora

Każdemu juniorowi przydzielamy mentora, który pracuje z nim indywidualnie. W zależności od mentora i aktualnego poziomu kandydata spotkania mogą odbywać się od 1 do 5 razy w tygodniu po 1 godzinie. Mentorzy to ochotnicy, którzy chcą zrobić coś więcej niż tylko pisać kod.

Część obciążenia mentorów odciążają kursy na naszym stosie - Dart, Angular. Kursy odbywają się cyklicznie dla małych grup 4-6 osobowych, podczas których studenci uczą się bez przerwy w pracy.

W ciągu 3 miesięcy okresowo zbieramy informacje zwrotne od juniorów, ich mentorów i leadów i indywidualnie dostosowujemy proces. Napompowane umiejętności są sprawdzane 1-2 razy w ciągu całego okresu, na koniec przeprowadzana jest ta sama kontrola - na ich podstawie formułowane są zalecenia dotyczące tego, co dokładnie należy poprawić.

wniosek

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

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

W ciągu 3 miesięcy sprawdziliśmy 122 ankiety, 54 zadania testowe i przeprowadziliśmy 21 wywiadów technicznych. Dzięki temu mamy trzech świetnych juniorów, którzy ukończyli już połowę planów wdrożenia i akceleracji. Realizują już rzeczywiste zadania produktowe w naszym projekcie, w którym w samym interfejsie znajduje się ponad 3 2 000 linii kodu i ponad 000 repozytoriów.

Dowiedzieliśmy się, że lejek dla juniorów może i powinien być dość skomplikowany, ale ostatecznie przechodzą przez niego tylko ci chłopaki, którzy są naprawdę gotowi bardzo ciężko pracować i inwestować w swój rozwój.

Teraz naszym głównym zadaniem jest ukończenie trzymiesięcznych planów rozwoju dla każdego juniora w trybie pracy indywidualnej z mentorem i kursów ogólnych, zebranie metryk, informacji zwrotnej od leadów, mentorów i samych chłopaków. Na tym etapie pierwszy eksperyment można uznać za zakończony, wyciągnąć wnioski, usprawnić proces i rozpocząć go od nowa w celu wyłonienia nowych kandydatów.

Źródło: www.habr.com