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

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

Се опитвам да обуча джуниор.

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

Защо изобщо помислихме за наемане на джуниори?

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

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

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

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

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

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

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

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

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

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

Обявяваме вакансия.

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестовото задание завършиха почти половината от останалите момчета — получихме решения 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 кандидати влязоха във финала, потвърдили своите хард скиллове с чудесно тестово задание и добри отговори на интервюто.

Cultural fit

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

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

Всеки джуниор, освен продуктова команда, чиито лидер трябва да се съгласи да го вземе, попада при ментор. Задачата на ментора е да го проведе през 3-месечния процес на онбординг и развитие на хард-скиллове. Затова на всеки cultural fit идвахме в качеството на ментори и си задавахме въпроса: „Ще поема ли отговорност да развия кандидата за 3 месеца по нашия план?“

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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