Чому варто наймати джуніорів

image

Коли я починав як розробник на Rails, я постійно колупався з фреймворками весь свій вільний час, якого, однак, було достатньо. Я не був одружений, працював у Coles і підробляв на фрілансі, виконуючи замовлення на PHP і Rails.

Якось я почув про проведеному у місті Аделаїда Ruby Meetup. Відразу після роботи я рвонув на потяг і поїхав на цей захід. Коли я туди потрапив, кілька людей запитали мене, чим я займаюся. Я розповів про роботу Coles, про PHP і Rails, на що мені відповіли «ти не повинен більше працювати в Coles» і троє з них протягнули мені свої візитні картки, сказавши, щоб я подав їм резюме. Я відправив заявку в Sealink і мене взяли.

У Sealink я потрапив у підмайстри команди Rails-розробників, які мали купу терпіння для того, щоб миритися з моїми 19-річними витівками. Я дуже вдячний їм за той час, що вони витратили на моє навчання і, як я вважаю, саме їх наставництво заклало основу моєї кар'єри і всього того, що я робив наступні десять років.

У Мельбурні є багато джуніорів, відвідують Ruby Meetup'и. Я знаю це напевно, бо допомагав організовувати нічні хакатони, на які вони теж ходять. І ось уявіть, якщо б який-небудь новачок на митапе сказав би вам, що він активно шукає роботу, ви б його найняли? Можливо, ні. Створюється враження, що на таких заходах панує атмосфера відрази до найму джуніорів, тому, що вони, джуниоры, віднімають дорогоцінний час команди, яке могло бути витрачено на розробку, на їх навчання.

Раніше існувала серйозна нестача талановитих та кваліфікованих розробників і компаніям доводилося наймати тих, кого вони могли знайти. Саме тому колись я так легко влаштувався Rails-розробником. Думаю, що тепер все повернулося на круги своя і наявність таланту не має жодного значення для того, щоб взяти людину на роботу.

Останнім часом я багато дискутував у Ruby-співтоваристві на тему ухилення компаній від найму джуніорів. Замість них компанії прагнуть наймати мідл і синьоров і не хочуть мати джуніорів в команді, які будуть навчатися у тих же мідл і синьоров.

У адвокатів, слюсарів, механіків і у багатьох інших професіях є культура учнівства (і підмайстрів), так що програмісти гірше? Це досить дивно, тому що в IT-компаніях існує достатня плинність, яка повинна була донести до керівництва урок, що завжди потрібно думати про підготовку кадрів на майбутнє. Ми — молода громада з досвідом менше п'ятнадцяти років і нам потрібно замислюватися про довгостроковій перспективі: хто буде підтримувати наш код після того, як ми підемо?

Найм сеньйорів
Давайте подивимося, чому компанії прагнуть наймати в першу чергу синьоров. У компанії, де я працював, ми хотіли найняти нового middle/senior розробника, тому що наша навантаження дійшла до рівня, коли ми вже фізично не справлялися з поставленими завданнями. Я вважаю, теж відбувається і в інших компаніях. Де б я не працював — у тому числі і по сей день — у мене, та й у вас, я вважаю, завжди стояли люди, які дихали в потилицю і періодично запитували, коли будуть пофикшены баги або реалізовані якісь нові функції.

І для вирішення подібних питань ви наймаєте нового розробника, точніше, намагаєтеся його найняти. Ви хочете, щоб розробник був рівня middle-senior, так як він володіє всіма необхідними навичками, щоб миттєво влитися в роботу без серйозної участі в його процесі «входження» з боку керівництва, щоб відразу ж почати отримувати від нього готовий код.

Тим не менш, зараз не так і просто знайти хоч кого-то підходить під ці вимоги. У поточній ситуації майже неможливо найняти Ruby-розробника рівня middle-senior, готового перейти в вашу компанію. Зазвичай відбувається наступне: розробники отримують агресивні пропозиції від конкурентів, якими останні намагаються їх переманити до себе.

Компанії витрачають тисячі доларів на утримання рекрутерів і силу-силенну часу на теоретичну роботу, профіт від якої неймовірно малий. Компанії витрачають тисячі доларів на полювання за міфічною рок-зіркою світу розробки, «єдинорогом», який варто десятьох звичайних розробників. Але «єдинороги» більше не пасуться на сонячних луках, де їх просто зловити. Вони, ці «зірки», вже десь працюють і їх все влаштовує.

Ми, як спільнота, вже спустошили «басейн» талантів.

Вільних «рок-зірок» вже не залишилося, тому настав час виховувати власних.

Компанії так захоплюються спробами найму конкретних 5% або 10% від загального пулу розробників, що вже не звертають уваги на все інше. Існує більше кількість талановитих людей у решти 90%, але їм потрібні наставники. Якщо вони його отримають, то ми зможемо залучити в наш спільнота розумних людей. Що робити, якщо людину, який займався навчанням у вашій компанії, просунули вище і зробили технічним директором? А якщо б він став тим самим інженером, який стоїть десятьох, і який міг би допомогти кому завгодно і з чим завгодно? Я вважаю, що компанії повністю ігнорують таланти людей, якщо вони не є для них абсолютно очевидними.

Занадто багато організації зосередили свою увагу на короткострокових цілях отримання робочого коду, замість того, щоб звернути увагу на довгострокові перспективи розвитку та професійного зростання власних команд.

Компанії, наймають кращих з кращих — людей з гарантовано високим скиллом — і змушують займатися тим, що, по суті своїй, є черговою фантазією на тему конкатенации

Якщо порівнювати це з наймом піаністів, то ви наймаєте Шопена, Баха і Ференца Ліста для того, щоб вони грали вам «У Мері був маленький баранчик».

Вам не потрібно наймати синьоров. Вам потрібно найняти розробника будь-якого рівня кваліфікації, навчити їх і виростити. Дайте людям шанс, навчайте їх на те, що реально використовується, адже сьогоднішні джуниоры завтра можуть бути великими розробниками у вашій компанії, але ви просто не даєте їм можливість ними стати.

Отримання компенсації
Ви можете подумати: що ми, (як організація) отримаємо з цього? Я вважаю, що думати потрібно у зворотному напрямку: «ми заробили на цьому співтоваристві і тепер настав час зробити щось для нього». Якщо ви інвестуєте (в довгостроковій перспективі) на здоров'я населення, то в подальшому ви отримуєте з цього свої дивіденди. У нашому ж випадку, ви будете мати активний кадровий резерв розробників, які зможуть займатися підтримкою вашого продукту. У короткостроковій перспективі ви отримаєте підтримку рівня продуктивності вашої команди новим талановитим розробником.

Ви можете думати, що вам потрібні тільки найкращі, «круті засранці», тому що ваш додаток — один великий, безструктурний монолітний бегемот, впоратися з яким зможуть тільки ці самі «круті засранці». Вам потрібні синьйори, здатні зорієнтуватися в локшині коду, з якого складається додаток. Можливо, це так. Але в кожному монолітному проекті є крапелька функціональних можливостей, впоратися з якими зможе не тільки синьйор, на яких не-синьйор зможе підвищити свій скілл, за умови, що буде працювати у зв'язці зі старшим розробником.

Це нормально — наймати команду без синьоров для того, щоб працювати з кодом вже робочого продукту. Ми зробили це з «Marketplacer» і ми як і раніше в бізнесі. Зрозумійте, вашу компанію не охопить полум'я тільки від того, що ви почнете наймати джуніорів.

Так, це ризиковано. Спочатку, вартість утримання такого працівника вище, ніж прибуток, який він приносить компанії. Але маючи можливість росту, вони можуть вирости в кращий актив, який ви коли-небудь мали.

image

У момент початку роботи джуніора, доларова вартість виробленої ними продукції менше, ніж вартість їх утримання. Але з хорошим наставником вони можуть змінитися і перейти в стані, коли їх продуктивність вище їх зарплати. Так, існує просадка по продуктивності праці — це правда, але це триває лише 6 місяців, якщо ви все робите правильно. Зрештою, замість одного розробника ви маєте вже двох. Навіть якщо джуніор в половину продуктивний щодо синьйора, то у вас є півтора розробника, що більше, ніж всього один, а з цього випливає полуторний зростання продуктивності команди.

У Marketpalacer ми наймали джуніорів останній рік і я вважаю, що вони стали дуже продуктивними та цінними членами команди. Ми пропустили їх, якщо б були зосереджені виключно на наймання синьоров або людей, які вже мають досвід розробки додатків на Rails.

Ви можете думати «а що, якщо вони підуть»? Цей ризик існує при наймі співробітника будь-якого рівня досвіду. Якщо люди йдуть з компанії, ви повинні зробити для себе висновки і зрозуміти, чому так відбувається. Вони йдуть за власним причин, або справа у вашій компанії? Чи є у вашій компанії, корпоративна культура, з-за якої не хочеться йти? Або люди працюють тут виключно з-за того, що їх цікавить код ЗА для морських перевезень?

Пошук джуніорів
Звідки можна почати пошук джуніорів? Ну, для початку — код-академії. Немає якоїсь конкретної, але моя улюблена — Тьюринга. Код-академії зараз дозволяють частково вирішувати проблему відсутності наставництва. Люди платять «академіям» тисячі доларів, щоб освоїти ази. Деякі з «академій» навіть дають гарантії працевлаштування по закінченню їх курсу. Найчастіше там навчають азам HTML, CSS, Javascript, Ruby і, як правило, «випускникам» досить легко пов'язати свій подальший шлях конкретно з Ruby. Спочатку ці люди дуже «зелені», але вони, все ж, стають частиною спільноти і починають працювати.

На жаль, з-за нашого прагнення знайти синьоров ми не наймаємо цих новачків. В академіях формуються таланти, але ми їх ігноруємо. Цим людям доводиться боротися за кілька місяців для того, щоб влаштуватися хоча б на стажування і я спілкувався з багатьма з них.

Не у всіх випускників академій є час, щоб відточувати і розвивати свої навички, так як часто вони десь працюють на повну ставку або мають інші обов'язки, що вимагають їх уваги. На щастя, вони часто отримують підтримку код-академій навіть після того, як закінчують курс. Ну, у всякому разі, так робиться в хороших академіях.

Мені б хотілося, щоб компанії змінили своїй пристрасті до найму досвідчених розробників і звернули увагу на випускників цих академій. Все більшій кількості компаній потрібно зайнятися наставництвом та навчанням того, чим вони займаються. Люди ж, які закінчують код-академії, реально хочуть вчитися і, виходячи з мого досвіду, вони дуже серйозно мотивовані.

Безумовно, є джуниоры, які так само прагнуть до знань і володіють тією ж мотивацією, але ніколи код-академії не закінчували. Вони вчилися самостійно, періодично шукаючи консультації у інших членів нашої спільноти. Я можу назвати п'ять, ні, навіть десять чоловік, які подають великі надії в плані перейняття досвіду у своїх наставників в нашій компанії.

Якщо б я був відповідальним за рекрутинг нашої організації, я б найняв замотивированного джуніора, платив би їм достатню для життя зарплату і впритул зайнявся їх навчанням.

У Асима Аслана (chuhnk) був хороший твіт на цю тему:

When hiring remember that someone once gave you an opportunity when you didn't have the experience. Hire smart raw talent and mentor them.  Asim Aslam (@chuhnk) 14 квітня 2016 р.


Також існує відмінна книга, яку я рекомендую прочитати, називається «The Talent Code». В її слогані говориться: «Великими не народжуються, ними стають». Книга охоплює приклади вдосконалення в таких сферах як спорт, музика та інші області. Всі промислові галузі, описані в ній, так чи інакше використовують модель наставництва і підмайстрів. Тим не менш, це нікого не чіпає в співтоваристві програмістів: ми все ще занадто молода громада.

По секрету розповім вам головну думку цієї книги: коли хто-то в чому реально хороший, він повинен послати все до біса і займатися саме цим. Де ми візьмемо синьоров, якщо ми не наймаємо джуніорів і не дозволяємо їм відточити навички в реальних умовах?

Багато людей говорить про цю проблему, про наймання джуніорів. Так давайте ж почнемо це робити.

Наставництво
Тепер, коли, як я сподіваюся, я переконав вас найняти джуніора, ви можете здивуватися і запитати себе: «що я роблю?» як тільки він з'явиться у вашій команді.

Я допомагав запустити нічний хакатон «Melbourne Ruby Hack night» де люди не були обмежені якимись рамками, де кожен міг взяти з собою будь-Ruby-проект і працювати з ним. Деякі навіть вперше бачачи там Ruby, виявляли великий інтерес. Ці нічні хакатони реально працюють, тому що ці нові розробники відчувають себе в безпеці, відчувають доброзичливу атмосферу і що жодне питання не є надто «тупим», щоб його поставити.

Ви можете почати з наставництва у вашій компанії, намагаючись відтворити атмосферу цих нічних хакатонов. У порядку речей повинна бути ситуація, коли вас ляскають по плечу і задають питання. Якщо запитувач у відповідь отримує закочування очей, зітхання або інші пасивно-агресивні сигнали, то ця не та атмосфера, в якій джуніор зможе чому-небудь навчитися.

Відмінним способом для симулювання атмосфери хакатона є парне програмування. Видача джуніору невеликих простеньких тасков — спочатку відмінний спосіб, щоб завоювати його довіру. Коли я навчав джунов, перше, чого вони потребували, як я думаю — це впевненість у власних силах. Вони знають відповідь, але вони не впевнені в тому, чи правильний він. Вони ставлять під сумнів все: чи використовують вони правильний синтаксис чи правильно пишуть код. Коли з джуном в парі є старший розробник, він може заохочувати їх на те, щоб вони більше практикувалися і дізнавалися щось нове. Якщо у джуна щось не виходить, наявність поруч більш досвідченого розробника гарантує, що він пояснить, що помилки трапляються і направить новачка в потрібне русло. Подібні «зв'язки» — найшвидший спосіб підвищити скілл джуніора і я дуже, дуже його рекомендую.

Я щодня працював в парі з деякими розробниками, за часів моєї роботи в GetUp, і через кілька років вони перетворилися в впевнених розробників на Rails. Я робив те ж саме і в інших компаніях, і кожен раз я бачив стрімке професійне зростання джуніорів, наставником яких був. Одне з найкращих почуттів у світі, це коли джун каже: «А, я зрозумів!».

Парна робота також допомагає зміцнити і власні знання. Якщо ви не можете комусь щось досить виразно пояснити, то ви недостатньо добре це знаєте. Парна робота корисна молодшим розробникам, тому що вони отримують нові знання, але також це корисно і їх старшим товаришам: в ході спілкування з іншими людьми по темі, для більш ясного викладу, вони структурують свої знання.

Як саме ви повинні працювати в парі з джуниором? Ну, у Лідії Гуаріно є пара розумних твітів на цю тему:

5) For junior devs, a good guideline for scope is something that can be completed in 2-3 days. You want to keep your feedback loop short.  Lydia Guarino (@lydiaguarino) 13 квітня 2016 р.

5) Tasks with scope of more than 3 days are tasks that are not defined well enough. Break them down further.  Lydia Guarino (@lydiaguarino) 13 квітня 2016 р.


І я згоден з обома. Джуни розвиваються найшвидше, коли їм вдається швидко досягти позитивного результату. Коли вони мають постійний зворотний зв'язок, їх довіру до вас росте, а кожен раз, коли вони «виграють» у коді, зростає і їх впевненість в собі, що робить їх тільки сильнішими.

Після того, як вони отримали деяку впевненість у власних силах, ви можете дозволити джуниорам працювати самостійно. Не існує чітких часових рамок, коли цей момент настане, все залежить від того, наскільки здатний ваш новачок.

Дайте їм волю зробити щось невелике і можливість задавати будь-які питання, а найголовніше, дайте зрозуміти, що «неправильних» шляхів реалізації цього немає. Після виконання завдання змусьте їх показати те, що вони зробили, сядьте поруч і розберіть разом написаний код.

Спільний розбір коду важливий, тому що в ньому не написано «чому ти це робиш?» у ньому немає ніяких емоцій, на відміну від ситуації, коли з вами говорить жива людина. Але будьте обережні: джуніор може інтерпретувати ваше запитання «Чому ти зробив так?» агресивний «Е! Чому ти робиш це так?».

Візуальний контакт допомагає встановити зв'язок між учнем і наставником набагато краще, ніж, наприклад, повідомлення в месенджері.

Якщо джуніор допустив помилку в запиті, то ви можете обговорити її з ним і виправити. Це знизить ймовірність того, що вона з'явиться знову.

Рев'ю коду також дозволяє старшим колегам оцінити, наскільки добре ваш новачок справляється з поставленими завданнями. Якщо він відмінно управляється з дрібними дводенними тасками, можливо, настав час дати йому щось на чотири дні? Якщо ж ні, то, по всій видимості, доведеться ще його підучити.

Зрештою, суть навчання полягає в тому, щоб джуніор відчув себе потрібним і безпеки у вашій команді. Насправді, це стосується абсолютно всіх членів колективу. Google запустив проект, який вони назвали «Project Aristotle», в рамках якого вони намагалися знайти спосіб створення ефективних команд. Вони провели опитування співробітників і отримали п'ять пунктів:

image

І пунктом №1 стала «Психологічна безпека(комфорт)»: члени команди відчувають себе у безпеці і можуть дозволити собі бути уразливими.

Google не є особливим. Ця компанія також складається з людей, як і будь-яка інша організація. І ви повинні мати це на увазі, коли будете навчати власних новачків, а також працювати з іншими людьми.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.