Как да обучим джуниор?

Как да стигнете до голяма компания, ако сте начинаещ? Как да наемете достоен начинаещ, ако сте голяма компания? Под статията ще разкажа нашата история за наемането на начинаещи в фронтенда: как изработвахме тестови задачи, подготвяхме се за интервюта и изграждахме менторска програма за развитие и onboarding на новите служители, а също така защо стандартните въпроси за интервю не работят.

Аз се опитвам да опитомя начинаещ.

Здравейте! Аз съм Павел, правя фронтенд в екипа на Wrike. Създаваме система за управление на проекти и съвместна работа. Занимавам се с уеб от 2010 година, три години работих дистанционно за чуждестранна компания, участвах в няколко стартапа и преподавал курс по уеб технологии в университета. В компанията участвам в развитието на техническите курсове и менторската програма на Wrike за начинаещи, а също така активно се занимавам с техния подбор.

Защо изобщо се замислихме за наемането на начинаещи

До неотдавна набираме фронтенд разработчици на ниво middle или senior — достатъчно самостоятелни, за да могат след онбординга да изпълняват продуктови задачи. В началото на тази година осъзнахме, че искаме да променим тази политика: през последната година броят на нашите продуктовите екипи нарасна почти два пъти, числото на фронтендерите наближава сто, а в близко бъдеще всичко това трябва да се удвои отново. Работата е много, свободните ръце са малко, а на пазара има още по-малко, затова решихме да се обърнем към хората, които току-що започват своя път във фронтенда и осъзнахме, че сме готови да инвестираме в тяхното развитие.

Кой е джуниор?

Това е най-първият въпрос, който си задали. Има различни критерии, но най-простият и разбираем принцип е следният:

На джуниора му трябва обяснение каква функция и как да направи. На миддъла му трябва обяснение каква функция е нужна и той сам ще се ориентира с реализацията. Синьорът сам ще ти обясни защо тази функция изобщо не трябва да се прави.

Както и да е, джуниорът е този разработчик, на когото му е нужен съвет как точно да реализира конкретно решение. От това решихме да се ръководим:

1. Джуниор — това е човек, който иска да се развива и е готов да работи упорито за това;
2. Той не винаги знае в каква точно посока иска да се развива;
3. Нуждае се от съвет и търси помощ отвън — от своя лидер, ментор или в общността.

Имахме и няколко хипотези:

1. На позицията за джуниор ще има множество отговори на обявата. Трябва да филтрираме произволни кандидатури още на етапа на изпращане на резюмета;
2. Първоначалният филтър няма да е достатъчен — ще са нужни допълнителни тестови задания;
3. Тестовите задания ще уплашат много кандидати — те не са необходими.

И разбира се, имахме цел: 4 джуниора за 3 седмици.

С това осъзнаване започнахме да експериментираме. Планът беше прост: да започнем с максимално широка верига и постепенно да я стесняваме, така че да успяваме да обработваме потока, без да го сведем до 1 кандидат на седмица.

Публикуваме обявата за работа

За компанията: Ще има стотици кандидатури! Помислете за филтър.

За джуниора: Не се притеснявайте от въпросника преди изпращане на резюмето и тестовото задание — това е признак, че компанията се е погрижила за вас и е настроила добре процеса.

В първия ден получихме около 70 резюмета от кандидати с „умения по JavaScript“. След това още. И още. Физически не можехме да поканим всички на интервю в офиса и избрахме момчетата с най-вълнуващите им пет проекта, активен GitHub или поне с известен опит.

Но основният извод, който направихме още в първия ден — бурята започна. Време е да добавим формуляр за проучване преди изпращане на резюметата. Неговата цел беше да отсява кандидати, които не са готови да положат минимални усилия за изпращане на резюме, и тези, които не притежават знания и контекст, поне в такава степен, че да си потърсят правилните отговори в Google.

В него имаше стандартни въпроси за JS, уеб дизайн, уеб и компютърни науки — всеки, който има представа какво се пита на интервю за фронтенд, знае тях. Каква е разликата между let/var/const? Как да прилагаме стилове само за екрани, по-малки от 600px в ширина? Не искахме да задаваме тези въпроси на техническото интервю — практиката показа, че на тях може да се отговори след 2-3 интервюта, без да се разбира в разработката. Но те поне успяха да ни покажат дали кандидатът разбира контекста.

Във всяка категория сме подготвили по 3-5 въпроса и ден след ден променяхме техния набор в формата на обратна връзка, докато не изключихме най-обикновените и най-трудните. Това ни позволи да намалим потока — за 3 седмици получихме 122 кандидата, с които можем да работим по-нататък. Това бяха студенти от ИТ сферата; младежи, които искаха да преминат от бекенд към фронтенд; работници или инженери на възраст 25-35 години, които драстично искаха да сменят професията и вложиха различни усилия в самообразование, курсове и стажове.

Запознаваме се по-добре

За компанията: Тестовата задача не плаши кандидатите, а помага да се стесни воронката.

За джуниора: Не копирайте тестовите задачи — това се забелязва. И поддържайте гитхаб профила си в ред!

Ако бяхме поканили всички на техническо интервю, щяхме да проведем около 40 интервюта седмично само за джуниори и само за фронтенд. Затова решихме да проверим втората хипотеза — за тестовата задача.

Какво беше важно за нас в тестовата задача:

1. Да изградим добра мащабируема архитектура, но без излишно усложняване;
2. По-добре е да отнеме повече време, но да се направи качествено, отколкото за една нощ да се изработи нещо с коментар "определено ще го довърша";
3. Историята на разработката в Git е инженерна култура, итеративност на разработката и фактът, че решението не е просто копирано безпардонно.

Ние се съгласихме да разгледаме една алгоритмична задача и малко уеб приложение. Алгоритмичните задачи бяха подготвени на ниво лабораторни упражнения от началните курсове — бинарно търсене, сортиране, проверка за анаграми, работа със списъци и дървета. Накрая се спряхме на бинарното търсене като първи пробен вариант. Уеб приложението трябваше да бъде хикс-о-надо с използване на какъвто и да било фреймворк (или без него).

Тестовото задание успя почти половината от останалите участници — получихме решения. 54 кандидата. Невероятно прозрение — как мислите, колко реализации на хикс-о-надо, готови за копиране, съществуват в интернет?

Колко?Всъщност, изглежда, че само 3. И в огромното мнозинство от решенията бяха именно тези 3 варианта.
Какво не ми хареса:

• копипаста, или разработка по един и същи туториал без собствена архитектура;
• и двете задачи в единен репозиторий в различни папки, но историята на комитите, разбира се, липсва;
• неприемлив код, нарушение на принципа DRY, отсъствие на форматиране;
• смешване на модел, изглед и контролер в един клас с дължина стотици редове код;
• липса на разбиране за юнит тестиране;
• решение "в лоб" — директно хардкодиране на матрицата с печеливши комбинации 3х3, което по-трудно ще бъде разширено до 10х10, например.

Освен това, забелязахме съседни репозитории — страхотни пет-проекта печелели, докато куп тестови задания от други компании бяха по-скоро сигнал: защо кандидатът не успя да мине там?

В крайна сметка намерихме страхотни варианти на React, Angular, Vanilla JS — успяхме да съберем 29. И решихме да поканим още един кандидат без тест заради невероятните му пет-проекти. Нашата хипотеза за ползата от тестовите задания се потвърди.

Техническо интервю

За компанията: Не са дошли мидъли/сеньори! Нужен е по-индивидуален подход.

За джуниора: Помнете, че това не е изпит — не се опитвайте да мълчите, за да получите тройка или да преливате професора с всичките си познания, за да се обърка и да постави "отлично".

Какво искаме да разберем на техническото интервю? Едно просто нещо - как кандидатът мисли. Най-вероятно той притежава някакви хард скиллове, ако е преминал първоначалните етапи на подбора - остава да разберем дали може да ги приложи. Съгласихме се на 3 задачи.

Първата - свързана с алгоритми и структури на данни. С химикал, на лист хартия, на псевдоязик и с помощта на рисунки разглеждахме как да копираме дърво или как да изтрием елемент от свързан списък. Неприятното откритие беше, че не всички разбират рекурсията и как работят указателите.

Втората - лайв кодинг. Влизахме в codewars.com, избирахме лесни задачи като сортиране на масив от думи по последната буква и в продължение на 30-40 минути заедно с кандидата се опитвахме да преминем всички тестове. Изглеждаше, че не би трябвало да има изненади от момчетата, които са се справили с кръстословици - но на практика не всички успяха да осъзнаят, че стойността трябва да се запазва в променлива, а функцията трябва да върне нещо чрез return. Въпреки това искрено се надявам, че това е било просто стрес, и че момчетата са могли да се справят с тези задачи при по-лесни условия.

Накрая, третата част — малко за архитектурата. Обсъждахме как може да се направи търсачка, как работи debounce, как да се рендерират различни уиджети в подсказките за търсене, как фронтендът може да взаимодействва с бекенда. Намериха се немалко интересни решения, включително за server-side рендеринг и уеб сокети.

Проведохме 21 интервю по този модел. Публиката беше напълно различна — да разгледаме на комиксите:

1. «Ракета». Никога не спира, навсякъде се намесва и на интервюто ви залива с поток от мисли, които пряко не са свързани с зададения въпрос. Ако ставаше въпрос за университет, това щеше да е позната на много хора опит да се демонстрират абсолютно всички свои знания, когато за попадналия билет помните само, че снощи сте решили да не го учите — пак няма да можете да го изтеглите.
2. «Грут». С него е трудно да се установи контакт, защото той е Грут. На интервюто трябва да го разколебавате дълго, да извличате отговори дума по дума. Добре е ако е просто ступор — иначе после в ежедневната работа ще ви бъде много трудно.
3. «Дракс». По-рано се е занимавал с транспортировка на стоки, а от програмиране е учил само JS от Stackoverflow, затова не винаги разбира за какво става въпрос на интервюто. Въпреки това, е добър човек, има добри намерения и иска да стане страхотен фронтенд разработчик.
4. А вероятно, «Звезден лорд». В общи линии, е добър кандидат, с когото може да се уговорите и изградите диалог.

В края на нашите разисквания 7 кандидата преминаха финала, потвърдили своите хард скилъри с отлична тестова задача и добри отговори на интервюто.

Културна съвместимост

За компанията: Ще работите с него! Дали кандидатът е готов да работи извънредно много за собственото си развитие? Дали наистина ще се впише в екипа?

За джуниора: Ще работите с тях! Дали компанията е готова да инвестира в растежа на джуниорите, или просто ще свали цялата мръсна работа на вас за ниска заплата?

Все джуниори, наред с продуктовим екип, чий лидер трябва да се съгласи да ги приеме, получават ментор. Задачата на ментора е да ги води през три месеца процес на включване и усъвършенстване на хард скиловете. Поради това на всяко оценяване на културната съвместимост ние идвахме като ментори и си задавахме въпроса: "Ще поема ли отговорност да развия кандидата в рамките на 3 месеца по нашия план?"

Тази стъпка премина без особености и в крайна сметка ни донесе 4 оферти, 3 от които бяха приети и момчетата се присъединиха към екипите.

Живот след офертата

За компанията: Грижете се за вашите джуниори, иначе другите ще го направят!

За джуниора: АААААААААААА!!!

Когато нов служител започне, той трябва да бъде включен — да бъде запознат с процесите, да му се обясни как всичко работи в компанията и в екипа, и как изобщо да работи. Когато джуниор започне, трябва да разберем как да го развиваме.

Когато помислихме за това, изготвихме списък от 26 умения, които, според нас, един джуниор трябва да овладее до края на тримесечния период на онбординг. Включени бяха хард скиллс (според нашия стек), познания за нашите процеси, скрам, инфраструктура и архитектура на проекта. Събрахме ги в роадмап, разпределен във времето за 3 месеца.

Например, ето роадмапа на моя джуниор

На всеки джуниор прикрепяме ментор, който работи с него индивидуално. В зависимост от ментора и текущото ниво на кандидата, срещите могат да се провеждат от 1 до 5 пъти седмично по 1 час. Менторите стават доброволно инициативни фронтенд разработчици, които искат да правят нещо повече от просто писане на код.

Част от натоварването на менторите се сваля с курсове по нашия стек — Dart, Angular. Курсовете се провеждат редовно за малки групи от 4-6 души, където участниците могат да учат, без да се откъсват от работа.

В продължение на 3 месеца периодично събираме обратна връзка от джunior-ите, техните ментори и лидери и индивидуализираме процеса. 1-2 пъти през целия период се провежда проверка на усвоените умения, същата проверка се провежда в края - на тяхна основа се формулират препоръки какво точно трябва да се подобри.

Заключение

За компанията: Струва ли си да се инвестират средства в джuniors? Да!

За джуниора: Търсете компании, които старателно подбират кандидати и знаят как да ги развиват.

За 3 месеца прегледахме 122 анкети, 54 тестови задания и проведохме 21 техническо интервю. Това ни донесе 3 страхотни джуниора, които вече са преминали половината от своите пътеводители за onboarding и акселерация. Те вече решават реални продуктови задачи в нашия проект, където само на фронтенда има над 2 000 000 реда код и повече от 400 репозитория.

Установихме, че фунията за джuniors може и трябва да бъде достатъчно сложна, но в крайна сметка през нея преминават само тези момчета, които наистина са готови да работят много и да инвестират в своето развитие.

Нашата основна задача сега е да завършим тримесечните графици за развитие за всеки начинаещ с индивидуална работа с ментор и общи курсове, да съберем метрики, обратна връзка от ръководителите, менторите и самите участници. Този първи експеримент може да се счита за завършен, за да направим изводи, да подобрим процеса и да го стартираме отново за подбор на нови кандидати.

Източник: habr.com