«Почему разработчики участвуют в этом цирке?». Хайринг как главный баг ИТ-индустрии

Одно из самых больных мест в индустрии программного обеспечения — механизм найма разработчиков. Состояние «пациента» настолько тяжёлое, что единственные способ помочь ему — полностью снести и отстроить заново.

Я в разработке около 15 лет, и за это время был простым кодером, руководил собственной успешной софтверной компанией, основал стартап, в который вложились венчурные инвесторы, так что мне доводилось нанимать и управлять другими разработчиками. Весь этот многогранный опыт дал мне возможность с разных ракурсов взглянуть на процесс хайринга: как с точки зрения разработчика, который хочет получить место в компании, так и того, кто восседает на противоположном конце стола, пытаясь понять, как подобрать «того» человека, как снова не проколоться. Разобрать каждый из множества изъянов в том, как устроен процесс найма разработчиков, было бы слишком сложно, поэтому хочу остановиться на одном из них, но очень крупном.

Ограниченность

При найме на руководящие должности к человеку обычно строго приглядываются с самых разных сторон: насколько он дружелюбен, насколько хорошо владеет коммуникативными навыками и умеет обосновывать свои идеи, как видит отрасль в целом и сферу деятельности компании в частности, как держится в стрессовых ситуациях — и это далеко не полный список. А потом интервьюер делает субъективное заключение с учётом всех этих качеств.

С наймом разработчиков всё иначе, и просто удивительно, насколько при этом пренебрегают человеком как личностью и сосредотачивают всё внимание исключительно на технических/алгоритмических аспектах.

Между тем мы почти полностью игнорируем бэкграунд человека, судим по нему с ходу, спонтанно, и едва ли оценка его истинных профессиональных качеств и умений получится адекватной. Какая разница, что этот человек в одиночку создал и запустил несколько продуктов, что он твёрд и целеустремлён, что он умеет доходчиво изъясняться или приятен в общении? Ведь единственное, что существует в мире здесь и сейчас — эта игра, где у него один шанс, где он получит всё или ничего, этот аттракцион абсурда под названием «техническое собеседование». 

Но иногда рекрутерам плевать даже на технический багаж и прошлые достижения нанимаемого разработчика. Вот вам Макс Хауэлл, например:

Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.

— Max Howell (@mxcl) June 10, 2015

Google: 90% наших разработчиков пользуются софтом, который ты написал (Homebrew), но ты не можешь инвертировать бинарное дерево на доске, так что пошёл вон.

Как по-вашему, выдающемуся художнику с прекрасным творческим портфолио отказали бы только из-за того, что он не помнит, в каком городе родился Леонардо да Винчи?

Это просто нелепо. И так не должно быть.

Мне кажется, отрасль разработки ПО — и процесс найма разработчиком в частности — очень уникальна в этом отношении. Я не знаю почти ни одной другой «офисной» профессии, в которой бы при рассмотрении кандидата так упорно и всецело игнорировали его реальные, подтверждённые способности, прошлые успехи и разносторонние качества. Так почему с этим мирятся разработчики, да ещё и сами участвуют в этом цирке?

«Неправильные» сотрудники

Ещё смешнее в этом всём то, что, по моему опыту, главная польза, которую разработчик может дать компании, лежит за пределами технических аспектов.

Некоторые из худших разработчиков, которых мне доводилось нанимать, в техническом плане были отличными специалистами.

Чаще всего, по моим наблюдениям, проблемы у этих разработчиков возникают потому, что они слишком одержимы задачей написания кода и могут не понимать, что пилят что-то, что никому не нужно, и чем никто не будет пользоваться. Разработчик, у которого не так сильны технические навыки, но который больше заботится о потребностях пользователей, в конечном итоге окажется в 10 (или 1000) раз ценнее, потому что он потратит 5 часов, чтобы пообщаться с ними, пока тот замечательный, но зацикленный на коде разработчик вкалывает, тратит месяцы на фичу, которая никому не упёрлась.

А как понять, что в человеке уже есть эта ориентированность на пользователя? Подозреваю, она развивается у тех, кто сам строит и запускает продукты, и у кого уже были клиенты. Такой человек легко идёт на контакт и хорошо умеет выражать свои мысли. Вы заметите это, например, если потрудитесь узнать, что он ведёт блог. Учитывайте это при рассмотрении его кандидатуры. Другими словами, у него есть свойства, которые всем в софтверной отрасли при найме сотрудников по барабану.

А ещё я заметил, что у технических профи устремления часто расходятся с целями компании. Они могут слишком увлекаться прикольными техническими вещами, но в ущерб компании. И не жалуйтесь потом, вы ведь сами хотели нанять «фаната».Net. Получайте! Только потом его энтузиазм начнёт выходить за пределы разумного и будет уже не на пользу компании — ведь ещё есть крутой.Net Core, а я так обожаю.Net, поэтому давайте мигрируем на.Net Core, и неважно, что у нас ещё нет product-market fit, а большинство пользователей отваливаются через три месяца.

Компания — это те, кого она нанимает 

По моим наблюдениям, и это вполне закономерно, подходы компании к найму сотрудников отражаются в ней самой и в её продуктах. Компания — это те, кто в ней работает, и решения, которые принимают эти люди. Поэтому если вы нанимаете только людей с техническим «складом», не удивляйтесь, что все продукты у компании получаются «пресными». Разве странно, что у Google всё никак не получается делать и развивать гармонирующие продукты? Разве похоже, что Stadia создавали люди, которые хорошо понимают своего пользователя и умеют делать продукты под него? Или же это плод технарей, задачей которых было (любой ценой) написать код?

Процесс «поломан»

Пора понять, что человека нельзя измерить имитациями тестов «на интеллект». И безоговорочно принять, что хороший разработчик — это комплексное явление, которое включает как технические скиллы, так и эмпатию, опыт, здравый смысл, твёрдость и настойчивость, независимость. Хороший разработчик обладает самыми разнообразными качествами. Поэтому нужно активно искоренять заблуждение, что всё сводится к умению писать код или инвертировать бинарные деревья, и что это — единственная шкала для оценки людей, которые будут работать в команде и строить продукты для других живых людей.

Мы должны исправить это процесс. И очень основательно.

devby 17 лет!

Вспоминаем наш (и ваш) переходный возраст и делимся виш-листом