Як потрапити до великої компанії, якщо ти джуніор? Як найняти гідного джуніора, якщо ти велика компанія? Під катом розповім нашу історію найму хлопців-початківців на фронтенд: про те, як ми опрацьовували тестові завдання, готувалися проводити інтерв'ю та вибудовували менторську програму для розвитку та онбордингу новачків, а також чому не працюють стандартні питання для співбесід.
Я намагаюся приручити джуніора
Вітання! Мене звуть Павло, я роблю фронтенд у команді Wrike. Ми створюємо систему для управління проектами та спільної роботи. Займаюся вебом з 2010 року, 3 роки пропрацював на зарубіжному віддаленні, брав участь у кількох стартапах та читав курс з веб-технологій в університеті. У компанії я беру участь у розвитку технічних курсів та менторської програми Wrike для джуніорів, а також безпосередньо їх набором.
Чому ми взагалі задумалися про найм джуніорів
Донедавна ми набирали на фронтенд розробників рівня middle або senior — достатньо самостійних, щоб після онбордингу виконувати продуктові завдання. На початку цього року ми зрозуміли, що хочемо змінити цю політику: за рік кількість наших продуктових команд збільшилася майже вдвічі, кількість фронтендерів підійшла до сотні, а в недалекій перспективі все це має подвоїтися ще раз. Роботи багато, вільних рук мало, на ринку їх ще менше, тому ми вирішили звернутися до хлопців, які тільки розпочинають свій шлях у фронтенді та зрозуміли, що готові вкладатися у їхній розвиток.
Хто такий джуніор?
Це найперше питання, яке ми собі поставили. Є різні критерії, але найпростіший і зрозуміліший принцип такий:
Джуніор потрібно пояснювати, яку фічу і як зробити. Міддлу треба пояснити, яка фіча потрібна, і він сам розбереться з реалізацією. Синьйор сам пояснить тобі, чому цю фічу не потрібно робити взагалі.
Так чи інакше, джуніор — це той розробник, якому потрібна порада, як саме реалізовувати те чи інше рішення. Від чого ми вирішили відштовхуватися:
- Джуніор — той, хто хоче розвиватись і готовий для цього багато працювати;
- Він не завжди знає, в який саме бік хоче розвиватись;
- Потребує поради і шукає допомоги ззовні — свого ліда, ментора чи ком'юніті.
Ще в нас було кілька гіпотез:
- На позицію джуна буде шторм із відгуків. Потрібно фільтрувати довільні відгуки ще на етапі відправки резюме;
- Первинний фільтр не допоможе - Потрібні ще тестові завдання;
- Тестові завдання всіх налякають - Вони не потрібні.
Ну і звичайно, у нас була мета: 4 джуніори за 3 тижні.
Із цим усвідомленням ми почали експериментувати. План був простий: почати з максимально широкої вирви та пробувати поступово звужувати її так, щоб встигати обробляти потік, але щоб не звести його до 1 кандидата на тиждень.
Розміщуємо вакансію
Для компанії: Будуть сотні відгуків! Подумайте про фільтр.
Для джуніору: Не бійтеся опитувальника перед відправкою резюме та тестового завдання — це ознака того, що компанія про вас подбала і добре налаштувала процес.
У перший же день до нас прилетіло близько 70 резюме від кандидатів зі знанням JavaScript. А потім ще. І ще. Ми фізично не могли покликати всіх на інтерв'ю в офіс і вибрали з них хлопців із найбільш класними пет-проджектами, живим гітхабом чи хоча б досвідом.
Але головний висновок, який ми зробили для себе в перший же день — шторм почався. Настав час додати форму опитувальника перед відправкою резюме. Її завданням було відсіяти кандидатів, не готових докласти мінімальних зусиль для відправки резюме, і тих, хто не володіє знаннями та контекстом хоча б тією мірою, щоб загуглити правильні відповіді.
У ній були стандартні питання про JS, верстку, веб, Computer Science - їх знає кожен, хто уявляє, що запитують на співбесіді на фронтенді. У чому відмінність let/var/const? Як застосувати стилі тільки для екранів, менших ніж 600px завширшки? Ми не хотіли ставити ці питання на технічному інтерв'ю — практика показала, що на них можна відповісти після 2-3 співбесід, зовсім не розбираючись у розробці. Але вони змогли первинно показати нам, чи розуміє в принципі кандидат контекст.
У кожній категорії ми заготовили по 3-5 питань і день за днем змінювали їхній набір у формі відгуку, поки не виключили найпрохідніші і найскладніші. Це дозволило скоротити потік – за 3 тижні ми отримали 122 кандидати, з якими можна було працювати далі Це були студенти-айтішники; хлопці, які захотіли перейти на фронт із бекенда; робітники або інженери по 25-35 років, які кардинально захотіли змінити рід діяльності та доклали різну кількість сил до самоосвіти, курсів та стажувань.
Знайомимося ближче
Для компанії: Тестове завдання не відлякує кандидатів, але допомагає скоротити вирву
Для джуніору: Не копіпастите тестові - це помітно І тримайте в порядку свій гітхаб!
Якби ми покликали всіх на технічне інтерв'ю, нам довелося б проводити приблизно по 40 інтерв'ю на тиждень лише для джуніорів та лише на фронтенді. Тому ми вирішили перевірити другу гіпотезу про тестове завдання.
Що для нас було важливо у тестовому:
- Вибудувати хорошу масштабовану архітектуру, але без оверинжинірингу;
- Краще робити довше, але зробити добре, ніж за ніч зліпити виріб і відправити з коментарем «обов'язково доведу до кінця»;
- Історія розробки в гіті — інженерна культура, ітеративність розробки і те, що рішення не скупчене зовсім нахабно.
Ми зійшлися на тому, що хочемо подивитися одне алгоритмічне завдання та невеликий веб-додаток. Алгоритмічні були заготовлені на рівні лабораторок початкових курсів – бінарний пошук, сортування, перевірка на анаграми, робота зі списками та деревами. У результаті ми зупинилися на бінарному пошуку як перший пробний варіант. Веб-додатком повинні були стати хрестики-нуліки з використанням будь-якого фреймворку (або без нього).
Тестове завдання подужала майже половина з хлопців, що залишилися — нам надіслали рішення 54 кандидати. Неймовірний інсайт — як думаєте, скільки реалізацій хрестиків-нуліків, готових до копіпасти, є у мережі?
Скільки?Насправді, схоже, що тільки 3. І в переважній більшості рішень були саме ці 3 варіанти.
Що не сподобалося:
- копіпаста, або розробка по тому самому туториалу без своєї архітектури;
- обидві завдання в одному репозиторії у різних папках, історії коммітів при цьому звичайно немає;
- брудний код, порушення DRY; відсутність форматування;
- суміш моделі, юшки та контролера в один клас довгою в сотні рядків коду;
- відсутність розуміння юніт-тестування;
- рішення «в лоб» - хардкод матриці виграшних комбінацій 3х3, що досить важко буде розширити до 10х10, наприклад.
А ще ми звертали увагу на сусідні репозиторії — класні пет-проджекти йшли у плюс, а купа тестових завдань від інших компаній була скоріше дзвінком: чому ж кандидат не зміг пройти туди?
У підсумку ми знайшли класні варіанти на React, Angular, Vanilla JS – таких набралося 29. І ще одного кандидата ми вирішили запросити без тестових за його круті пет-проджекти. Наша гіпотеза на користь тестових завдань підтвердилася.
технічне інтерв'ю
Для компанії: До вас прийшли не міддли/сеньйори Потрібно більше індивідуального підходу.
Для джуніору: Пам'ятайте, що це не іспит - не намагайтеся відмовчатися на трійку або завалити професора потоком усіх своїх можливих знань, щоб він заплутався і поставив «відмінно»
Що хочемо зрозуміти на технічному інтерв'ю? Просту річ - як кандидат розуміє. Ймовірно, він має якісь хард скіли, якщо пройшов перші етапи відбору — залишилося з'ясувати, чи вміє їх застосовувати. Ми зійшлися на 3 завданнях.
Перша — про алгоритми та структури даних. Ручкою, на листочку, на псевдомови та за допомогою малюнків ми розбиралися, як скопіювати дерево або як видалити елемент із списку. Неприємним відкриттям стало, що не всі розуміють рекурсію та те, як працюють посилання.
Друга – лайв кодинг. Ми заходили на , вибирали нескладні речі на кшталт сортування масиву слів за останньою літерою та протягом 30-40 хвилин разом із кандидатом намагалися змусити всі тести пройти. Здавалося, не повинно бути сюрпризів від хлопців, які здолали хрестики-нуліки — але на практиці не всі змогли усвідомити, що значення потрібно зберігати в змінну, а функція має щось повертати через return. Хоча я щиро сподіваюся, що це був мандраж, і хлопці спромоглися розібратися з цими завданнями в більш лайтових умовах.
Зрештою, третя — трохи про архітектуру. Обговорювали, як можна зробити пошуковий рядок, як при цьому працює debounce, як рендерувати різні віджети у підказках пошуку, як фронтенд може взаємодіяти з бекендом. Знайшлося чимало цікавих рішень, у тому числі про server-side рендеринг та веб-сокети.
Ми провели 21 інтерв'ю за такою схемою. Публіка була зовсім різношерста — давайте на коміксах:
- «Ракета». Ніколи не заспокоюється, скрізь залазить, а на інтерв'ю завалить вас потоком думок, які навіть не пов'язані із заданим питанням. Якби справа була в університеті, це була б знайома багатьом спроба продемонструвати ну взагалі всі свої знання, коли про квиток, що попався, пам'ятаєш тільки, що вчора ввечері вирішив не вчити його — все одно не витягнеш.
- «Грут». З ним досить важко увійти в контакт, бо він є Грутом. На інтерв'ю доводиться довго розгойдувати, витягувати відповіді словом за словом. Добре, якщо це просто ступор, інакше потім у щоденній роботі вам буде дуже важко.
- «Дракс». Раніше займався вантажоперевезеннями, а з програмування вчив лише JS по Stackoverflow, тому не завжди розуміє, про що взагалі йдеться на співбесіді. При цьому хороша людина має найкращі наміри і хоче стати класним фронтендером.
- Ну і мабуть, «Зоряний лорд». Загалом непоганий кандидат, з яким можна домовитися та вибудувати діалог.
Під кінець наших досліджень 7 кандидатів вийшли у фінал, підтвердивши свої хард скіли класним тестовим завданням та гарними відповідями на інтерв'ю.
Культурна відповідність
Для компанії: Вам з ним працювати Чи кандидат готовий працювати екстремально багато для свого розвитку? Чи точно він впишеться до команди?
Для джуніору: Вам з ними працювати Чи компанія готова вкладатися в зростання джуніорів, чи просто звалить на вас всю брудну роботу за низьку зарплату?
Кожен джуніор крім продуктової команди, лід якої повинен погодитися взяти, потрапляє до ментора. Завдання ментора — провести його через тримісячний процес онбордингу та прокачування хард-скіллів. Тому на кожен cultural fit ми приходили як ментори і відповідали собі на запитання: «Чи візьму я на себе відповідальність прокачати кандидата за 3 місяці за нашим планом?»
Цей етап проходив без особливостей і зрештою приніс нам 4 оффера, 3 з яких були прийняті і хлопці вийшли в команди.
Життя після офферу
Для компанії: Подбайте про ваших джуніорів або це зроблять інші!
Для джуніору: ААААААААААААА!!!
Коли виходить новий працівник, його треба заобордити — ввести в курс процесів, розповісти, як усе влаштовано у компанії та в команді та як взагалі йому працювати. Коли виходить джуніор, слід зрозуміти, як його розвивати.
Коли ми про це задумалися, то сформували список із 26 скіллів, якими, на нашу думку, повинен мати джуніор до кінця тримісячного терміну онбордингу. Туди увійшли хард-скіли (на наш стек), знання з наших процесів, скраму, інфраструктурі, архітектурі проекту. Ми об'єднали їх у роадмап, розподілений за часом на 3 місяці.
Наприклад, ось роадмап мого джуніора
До кожного джуніора ми прикріплюємо ментора, який працює з ним в індивідуальному режимі. Залежно від ментора та поточного рівня кандидата зустрічі можуть проходити від 1 до 5 разів на тиждень до 1 години. Менторами добровільно стають ініціативні фронтендери, котрі хочуть робити щось більше, ніж просто писати код.
Частину навантаження з менторів знімають курси з нашого стеку — Dart, Angular. Курси проводяться регулярно для невеликих груп 4-6 осіб, де хлопці займаються без відриву від роботи.
Протягом 3 місяців ми періодично збираємо зворотний зв'язок від джуніорів, їх менторів та лідів та коригуємо процес індивідуально. 1-2 рази за весь період проводиться перевірка прокачаних скіл, така ж перевірка проводиться в кінці — на їх основі формуються рекомендації, що саме варто підтягнути.
Висновок
Для компанії: Чи варто вкладатися в джуніорів? Так!
Для джуніору: Шукайте компанії, які ретельно відбирають кандидатів і знають, як їх розвивати.
За 3 місяці ми переглянули 122 опитувальники, 54 тестові завдання та провели 21 технічне інтерв'ю. Це принесло нам 3-х класних джуніорів, які зараз пройшли половину своїх роадмапів з онбордингу та акселерації. Вони вже закривають реальні продуктові завдання у нашому проекті, де тільки на фронтенді більше 2 000 000 рядків коду та понад 400 репозиторіїв.
Ми з'ясували, що вирва для джуніорів може і повинна бути досить складною, але через неї проходять тільки ті хлопці, які дійсно готові дуже багато працювати і вкладатися в свій розвиток.
Зараз наше основне завдання — завершити тримісячні роадмапи щодо розвитку для кожного джуніора в режимі індивідуальної роботи з ментором та загальних курсів, зібрати метрики, фідбек лідів, менторів та самих хлопців та дівчат. На цьому перший експеримент можна буде вважати завершеним, робити висновки, покращувати процес та запускати його наново для відбору нових кандидатів.
Джерело: habr.com