Hello, World, друзі! Днями натрапив на чудову статтю австралійського розробника та CTO Нейла Сайнсбарі про ситуацію, яка зараз панує при прийомі на роботу технічних спеціалістів.
Не зміг пройти повз і зробив переклад його статті, чим хочу поділитись зі своїми читачами.
Одне з найболючіших місць у індустрії програмного забезпечення – механізм найму працівників. Стан “пацієнта” настільки важкий, що єдиний спосіб допомогти йому – це повністю знести та відбудувати заново.
Я у розробці близько 15 років, і за цей час був простим кодером, керував власною успішною софтверною компанією, заснував стартап, у котрий вклались венчурні інвестори, так що мені доводилось наймати та управляти іншими розробниками.
Увесь цей багатогранний досвід дав мені можливість з різних ракурсів подивитись на процес хайрингу: як з точки зору розробника, який хоче отримати місце в компанії, так і того, хто сидить за столом навпроти, намагаючись зрозуміти, як підібрати “ту” людину, як знову не проколотись.
Розібрати кожен з чисельних вад у тому, як влаштований процес найму розробників, було б надто складно, тому хочу зупинитись на одному з них, але дуже вагомому.
Обмеженість
При наймі на керівні посади до людини зазвичай суворо приглядаються з різних сторін: наскільки він доброзичливий, наскільки добре володіє комунікативними навичками та чи вміє він обгрунтовувати свої ідеї, як бачить галузь в цілому і зокрема сферу діяльності компанії, як тримається у стресових ситуаціях – і це далеко не повний перелік. А потім інтерв’юер робить суб’єктивний висновок з урахуванням всіх цих якостей.
З наймом розробників все інакше, і просто дивовижно, наскільки при цьому нехтують людиною як особистістю та зосереджують усю увагу виключно на технічних/алгоритмічних аспектах.
Фактично, весь процес зводиться до тесту на IQ, причому досить посередньому.
Попри все ми повністю ігноруємо бекграунд людини, судимо її сходу, спонтанно, і навряд чи оцінка його істиних професійних якостей та навичок вийде адекватною. Яка різниця, що людина сама створила та запустила кілька продуктів, що він твертий та цілеспрямований, що він вміє доступно висловлюватись чи приємний у спілкуванні? Адже єдине, що існує у світі тут і зараз – ця гра, де у нього один шанс, де він отримає все або нічого, цей атракціон абсурду під назвою “технічна співбесіда”.
Але іноді рекрутерам начхати навіть на технічний бекграунд та досягнення розробника в минулому. Ось вам Макс Хауелл, наприклад:
Google: 90% наших розробників користуються софтом, який ти написав (Homebrew), але ти не можеш інвертувати бінарне дерево на дошці, так що вали звідси.
Як на вашу думку, талановитому художнику з чудовим творчим портфоліо відмовили лише через те, що він не пам’ятає, в якому місті народився Леонардо да Вінчі?
Це просто безглуздо. І так не повинно бути.
Мені здається, що галузь розробки ПЗ – зокрема процес найму розробників – дуже унікальна в цьому плані. Я не знаю майже жодної іншої “офісної” професії, у якій би при розгляді кандидату так вперто та цілком ігнорували його реальні, підтверджені здібності, минулі досягнення та різносторонні якості. То чому з цим миряться розробники, ба більше, самі приймають участь у цьому цирку?
“Неправильні” співробітники
Ще смішніше в цьому всьому те, що згідно мого досвіду, головна користь, яку розробник може дати компанії, лежить поза межами технічних аспектів.
Декотрі з найгірших розробників, яких мені доводилось наймати, в технічному плані були чудовими спеціалістами.
Понад усе, за моїми спостереженнями, проблеми у цих розробників виникають тому, що вони занадто одержимі задачею написання коду та можуть не розуміти, що “пилять” щось, що нікому не потрібно, і чим ніхто не буде користуватись.
Розробник, у якого не такі сильні технічні навички, але який більше турбується про потреби користувача, в кінцевому результаті виявиться у 10 (або 1000) разів ціннішим, тому що він витратить 5 годин, щоб поспілкуватись з ними, поки той чудовий, але зациклений на коді розробник “впахує”, витрачає місяці на фічу, яка нікому не “вперлась”.
А як зрозуміти, що в людині вже є ця орієнтованість на користувача? Підозрюю, що вона розвивається у тих, хто сам будує і запускає продукти, той, у кого вже були клієнти. Така людина легко йде на контакт, добре вміє виражати свої думки. Ви помітите це, наприклад, якщо дізнаєтесь, що він веде блог. Враховуйте це при розгляді його кандидатури. Іншими словами, у нього є якості, на які всім у софтверній галузі по барабану при наймі співробітників.
А ще я помітив, що у технічних профі прагнення часто розходяться з цілями компанії. Вони можуть надто захоплюватись прикольними технічними речами, але не паритись, що компанія від цього може отримати збитки. І не плачте потім, адже ви самі хотіли найняти “фаната” .Net. Отримуйте! Тільки потім його ентузіазм почне виходити за межі розумного і буде вже не на користь компанії – адже ще є крутий .Net Core, а я так обожнюю .Net, тому давайте мігруємо на .Net Core. І неважливо, що у нас ще немає product-market fit, а більшість користувачів відвалюються через три місяці.
Компанія – це ті, кого вона наймає
За моїми спостереженнями, і це цілком закономірно, підходи компанії відображаються у ній самій і в її продуктах. Компанія – це ті, хто в ній працює, і рішення, які приймають ці люди.
Тому, якщо ви наймаєте людей з технічною “складовою”, не дивуйтесь, що всі продукти у компанії виходять “прісними”. Хіба дивує когось, що у Google все ніяк не виходить створювати і розвивати гармонійні продукти? Хіба схоже, що Stadia створювали люди, які добре розуміють свого користувача та вміють робити продукти під нього? Чи це плід технарів, завданням яких було (за будь яку ціну) написати код?
Процес “поламаний”
Час зрозуміти, що людину неможливо виміряти імітаціями тестів “на інтелект”. Та беззаперечно прийняти, що хороший розробник – це комплексне явище, яке містить в собі як технічні скіли, так і емпатію, досвід, здоровий глузд, твердість та наполегливість, незалежність.
Хороший розробник володіє найрізноманітнішими якостями. Саме тому потрібно активно викорінювати оманливе бачення, що все зводиться до вміння писати код чи інвертувати бінарні дерева, і що це – єдина шкала для оцінки людей, які будуть працювати в команді та будувати продукти для інших людей.
Ми повинні виправити цей процес. І дуже грунтовно.
