Как да опитомим младши?

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

Опитвам се да опитомя Джуниър

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

Защо изобщо се замислихме да наемем младши?

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

Кой е младши?

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

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

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

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

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

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

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

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

Обявяваме свободна позиция

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

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

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

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

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

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

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

За компанията: Тестовата задача не възпира кандидатите, а помага за съкращаване на фунията.

За младши: Не копирайте и поставяйте тестови - забелязва се. И поддържайте своя github в ред!

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

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

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

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

Почти половината от останалите момчета изпълниха тестовата задача – изпратиха ни решенията 54 кандидати. Невероятно прозрение - колко изпълнения на tic-tac-toe, готови за copy-paste, мислите, че има в интернет?

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

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

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

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

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

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

За младши: Не забравяйте, че това не е изпит - не се опитвайте да мълчите за C или да бомбардирате професора с поток от всичките си възможни знания, така че той да се обърка и да даде „отличен“.

Какво искаме да разберем в едно техническо интервю? Проста работа - как мисли кандидатът. Вероятно има някои трудни умения, ако е преминал първите етапи на селекция - остава да видим дали знае как да ги използва. Разбрахме се за 3 задачи.

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

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

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

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

1. "ракета". Той никога не се успокоява, включва се във всичко и по време на интервю ще ви залее с поток от мисли, които дори не са пряко свързани със зададения въпрос. Ако беше в университет, това би бил познат опит да демонстрирате, е, всичките си знания, когато всичко, което си спомняте за билета, на който сте попаднали, е, че снощи сте решили да не го изучавате - все още не можете да получите вън е.
2. "Грут". Доста трудно е да се свържеш с него, защото той е Грут. По време на интервю трябва да прекарате дълго време в опити да получите отговори дума по дума. Добре е, ако това е просто ступор - в противен случай ще ви бъде много трудно в ежедневната ви работа.
3. "Дракс". Работех в карго транспорта и по отношение на програмирането научих само JS на Stackoverflow, така че не винаги разбирам какво се обсъжда на интервю. В същото време той е добър човек, има най-добри намерения и иска да стане страхотен front-end разработчик.
4. Е, вероятно "звезден лорд". Като цяло добър кандидат, с който можете да преговаряте и да изградите диалог.

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

Културно прилягане

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

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

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

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

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

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

За младши: ААААААААААА!!!

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

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

Ето например пътната карта на моя младши

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

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

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

Заключение

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

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

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

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

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

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