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

Австралийский разработчик и CTO Нейл Сайнсбари в ужасе от того, как собеседуют и принимают на работу технических специалистов. Публикуем перевод его колонки.

29 комментариев
«Почему разработчики участвуют в этом цирке?». Хайринг как главный баг ИТ-индустрии
Австралийский разработчик и CTO Нейл Сайнсбари в ужасе от того, как собеседуют и принимают на работу технических специалистов. Публикуем перевод его колонки.

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

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

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

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

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

По сути, весь процесс превращается в тест на IQ, и довольно-таки посредственный.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Анонимные анкеты на jobs.dev.by — быстрый простой способ быть на виду у белорусских ИТ-компаний и не пропустить интересное предложение.
Заполнить анкету.

Хотите сообщить важную новость?

Пишите в наш Телеграм

Читайте также

Откажитесь от Google и Cookies: как бороться за свою конфиденциальность
Откажитесь от Google и Cookies: как бороться за свою конфиденциальность
Откажитесь от Google и Cookies: как бороться за свою конфиденциальность
Как в США данные помогают бороться за избирателей
Как в США данные помогают бороться за избирателей
Как в США данные помогают бороться за избирателей
Публикуем перевод статьи MIT Technology Review о микротаргетинге, сборе данных и прочих способах заполучить голоса избирателей, практикуемых в США с 2016 года.
Тату с биосенсорами помогут распознавать болезни на ранних стадиях
Тату с биосенсорами помогут распознавать болезни на ранних стадиях
Тату с биосенсорами помогут распознавать болезни на ранних стадиях
Динамические, или нанотехнологические татуировки способны менять цвет под воздействием различных факторов и могут использоваться не только для боди-арта, но и в медицинских целях. К примеру, они реагируют на изменение биохимии крови или повышенный радиационный фон. Ученые надеются, что такие татуировки помогут выявлять раковые образования на ранних стадиях.  Предлагаем перевод статьи доцента Колорадского университета в Боулдере Карсона Дж. Брунса (Carson J. Bruns). 
1 комментарий
Инструмент автодополнения кода Kite добавил поддержку 11 языков
Инструмент автодополнения кода Kite добавил поддержку 11 языков
Инструмент автодополнения кода Kite добавил поддержку 11 языков

Обсуждение

-3

Очень интересно, как заботящийся о пользователях и технически слабый программист будет для упомянутого Google что-то делать, когда любая задача является High Load и Security Critical. А для обычного программиста да, только у него не то что бы сосредотачивали внимание на "алгоритмических аспектах".

10

Из личного опыта могу с уверенностью сказать, что проблемы с задачами хайлоада и секьюрити решаются тренингами и соответствующими курсами примерно недели за две три (и если ресурсный менеджер хорошо справляется со своими обязанностями то он за этим проследит). А вот то, что как написано в статье, на проектах часто работают люди которым вообще неважен конечный продукт, то это проблема проектных менеджеров и руководства (то есть самой компании), так как во первых во многих компаниях все оценивается по количеству выполненных задач, а не качеству, а во вторых большая часть программистов понимает, что в случае кризиса или форс-мажора его выкинут как котенка на улицу и если он не будет думать только о себе и личных знаниях, то он может умереть с голоду. В общем на мой взгляд автор статьи прав!

-3

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

Гений Кодзима
Гений Кодзима Founder в Kojima Productions
1

Денис Семенихин, блогер, пообщался с людьми из кремниевой долины: инженером 4-го уровня в Google, инженером из Netflix, и т.д.

Товарищ из Netflix указал на различие между нашими инженереами, и инженерами в Кремниевой долине. Так вот это различие в том и заключается, что наши не могут в продукт, а могут только в фичи.

А товарищ из Google сказал, что в Google решаются задачи, в которых даже математика не нужна. Или что вы подразумеваете под основанием для технически сильного специалиста? Ведь мыслить алгоритмически, выстраивать логику, добиться изящной архитектуры любой гуманитарий может.

Дмитрий Иванов
Дмитрий Иванов ФРилансер в Global Freelance
5

Всё это мало кого волнует кроме 23 летних сеньёров

0

А что со Stadia не так?

1

Мне кажется, что там есть проблемки.
Нужен или их контроллер или телек с хромкастом + контроллер от старой консоли.
Вы покупаете штуку(подписку на штуку), которая потенциально может не работать. Непонятно нафига мне это надо? Хотя мне никто и не предлагает, т.к. у нас не доступен сервис.
Даже если у всех будет самый быстрый в мире интернет, то скорость света ребята как ни странно не обгонят, и в CS:GO наверное не погоняешь, хотя это было бы круто.

10

Процентов 50%-60% моих коллег однажды поднатарев в прохождении технических собеседований уже не хотят терять этот "скилл". Как результат - регулярная смена работы с последующим повышением.
-Почему вы меняете место работы спустя год?
-Стало скучно.
-Ок, вы приняты.
Знаю мастеров, сменивших 4-5 мест за 3 года.

7

еще одна 132-ая статья на ту же тему "ну почему нам задают эти гадкие скучные трудные вопросы про сортировку?"

6

Автор сама себе противоречит..
Если каждое уникальное место работы определяется людьми, которые там работают, то вполне нормально когда в разные компании проводятся разные собеседования (отбирая так как надо того кого надо)

arseniy-zuev
arseniy-zuev Teamlead ябатек в dev.by
-4

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

4

Все это хорошо, а теперь пусть автор предложит стандартный универсальный план интервью с четкими объективными критериями, чтобы всю эту лирику учесть.
Если человека нанимают писать "обработчик бинарных деревьев", а он вместо этого умеет хорошо общаться и приятен в общении, то что получится?)

Сергей Гончаренко
Сергей Гончаренко Full Stack Developer в ИП Гончаренко
4

Таки вам нужен стандартный и универсальный план? Или план для писателя бинарных деревьев? "Искали фаната .Net - получите". "К пуговицам претензии есть?". Почему не подходить к поиску как к задаче? Проанализировать кто нужен, какие характеристики у этого кого-то должны быть и уже от этого плясать.

1

Это в идеале, но в реале (FAANG) у вас тысячи и десятки тысяч программистов и тысячи интервью на какие угодно позиции. Кто будет индивидуальные планы интервью разрабатывать, проверять что они оптимальные и без ошибок, и проводить эти собеседования по индивидуальным планам?

Гений Кодзима
Гений Кодзима Founder в Kojima Productions
1

Нанимающий менеджер. Никаких процессов. Каждая команда подбирает под себя. Общается менеджер. Без посредников. Он по-братски оценит, поймёт, его ли человек.

1

"Система бьет класс".
Какой-то классный менеджер в стартапе может подобрать под себя идеального кандидата, но это не масштабируется.

14

А я вот с тезисами статьи согласен. Живу на другом континенте, работаю в крупной конторе - лидере рынка в своей области. Причём работаю уже довольно давно. Время от времени меня пытаются захайрить в другие конторы, но, кроме нежелания терять все бонусы, которые уже наработал на текущем месте, останавливает ещё и необходимость терпеть унижение на техническом интервью, когда заведомо более слабые спецы тебя макают в дерьмо носом за то, что ты там не помнишь то, что они заготовили заранее для интервью. Просто потому, что с этим давно не сталкивался, либо оно вообще по работе не нужно. Ну и результаты такого отбора я тоже могу видеть. Получается, что реально сильные люди предпочитают сидеть на попе ровно, а по конторам циркулируют спецы по прохождению интервью, за которых потом всё приходится делать.
Оно понятно, что хозяин - барин, но проблема качества найма она реально существует и временами доставляет, даже если сам работу и не меняешь.

arseniy-zuev
arseniy-zuev Teamlead ябатек в dev.by
1

Живу на другом континенте, работаю в крупной конторе - лидере рынка в своей области.

Казалось бы, причем тут это, особенно про другой континент

2

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

arseniy-zuev
arseniy-zuev Teamlead ябатек в dev.by
0

Не соглашусь насчет редкого исключения, но в целом наверное это и правда реже происходит.
Хотя я достаточно часто сталкивался и с адекватными собеседованиями тут, и с неадекватными там. В общем-то в статье-то даже пример человека, который в гугл собеседовался, а он именно на том континенте, где думаю и Вы.
В целом все очень зависит от целей найма. Для аутсорсинга (которого в Беларуси больше) очень важно держать низкие косты, а унизив собеседуемого есть куда больше шансов, что он себя оценит в плане зп ниже чем есть на самом деле. Плюс (наверное) абстрактные вопросы - прямое следствие множества проектов и большой ротации.
В продукте все же ищут себе в компанию не марже-единицу, а человека в команду в первую очередь, тем более в продукте стабилен и понятен стек, круг задач, поэтому и можно сосредоточиться на задачах, а не крутить деревья и разворачивать списки.
Но и "там" в случае найма в качестве марже-единицы частенько ситуация похожа, поэтому я считаю что дело не столько в континенте, сколько в профиле компаний

П.С.
Это еще и какая-то с детства воспитываемая культура пинания за ошибку. Еще со школы как-то воспитывают в человеке восприятие, что ошибка, плохая оценка - это крест, конец света. И очень любят при других за ошибки отчитывать и высмеивать. В то время как "там" воспитывают более продуктивное восприятие - почти любую ошибку можно исправить.
Ну и получаются в итоге люди, которые в таком stand by режиме на низком старте стоят и только и ждут, чтоб кто-то чего-то не знал или ошибся, чтоб на него накинуться и заклевать. Грустно

1

Скажите, а что страшного в том, что вас кто-то раскритикует? Если критика будет по делу - ок, повод задуматься. Если критика будет не по делу - ок, повод посмеяться. :)

13

Мне неприятна необъективная критика от малограмотных собеседующих. В частности, я наблюдаю, как мой босс собеседует. И, зная его квалификацию, мне лично было бы очень неприятно проходить подобный процесс. В любом случае, если не летать по работам, то навык подобных интервью теряется, ответы на дурацкие вопросы забываются. И оно становится стрессово. А стресса мне и по жизни хватает.

3

+1 Я и двое моих друзей проходили собеседования в европейские компании. Так вот во всех трех кейсах теории было оочень мало. В двух случаях это было парное программирование, а в одном случае это было написание тестового задания с последующем подробным разбором. Психологически это было намного комфортнее чем сортировать бинарные деревья)

-2

У чувака серьезные проблемы с логикой.
Например:

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

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

0

Очевидно что проблема с собесами есть.
Но автор тоже уходит куда-то не туда. Вот к чему это:

Какая разница, что этот человек в одиночку создал и запустил несколько продуктов, что он твёрд и целеустремлён, что он умеет доходчиво изъясняться или приятен в общении?
Разве странно, что у Google всё никак не получается делать и развивать гармонирующие продукты?

Это не о программистах, а о продакт менеджерах. Это их скиллы и вина.
Я обычно собеседую людей на конкретную роль - соответственно, выясняю как человек справится с конкретными задачами под эту роль. Как он решал их раньше. Или хотя бы похожие задачи.
Если в конторе не нанимают людей тысячами, а кандидатов не сотни тысяч, как в гуглах, значит она может позволить себе такой подход. Достаточно включить мозг и осмыслить позицию, на которую нанимаете.
Но обычно даже мелкие конторы делают карго-культ фаанговского найма. Или креативят в сторону софт-скиллов и тестовых заданий на выносливость.

0

Переодически приходят проекты на "закончить это супер технологическое чудо". Суть в том что приходят на проект супер пупер типа сеньеры. Разворачивают мега архитектуру на проекте по новомодному учебнику. Или начитавшись продвинутых техник. И что самое обидное обычно уже задавать вопросы некому. Они свинтили на новый мега оплачиваемый проект. Начинаешь копать код ... а там... к заказчику с вопросом "Типа нафига вы покупали космический корабль Прогресс если вам от него только наклейка нужна была с флажком?" А заказчик сам понимал что что то не то, но мега спец сказал что так очень нужно и без этого никак.

2

Есть и обратная сторона. Некоторые из faang чересчур увлеклись leadership principles.
Сочиняешь для интервью по 20 историй. В итоги нанимают Story tellers, тех кто лучше всех сказки рассказывает.

0

Всё вроде было норм но тут автор сам себя разоблачил:

"человек легко идёт на контакт и хорошо умеет выражать свои мысли. Вы заметите это, например, если потрудитесь узнать, что он ведёт блог. Учитывайте это при рассмотрении его кандидатуры."

Блогеров на техническую позицию без очереди! Спасибо, я уж лучше даже про бинарные деревья спрошу, а для эмоционально-интеллектуальных графоманов и другой работы хватает.

1

Когда-то я писал похожую статью. Имею опыт разработчика более 12 лет, в разных компаниях, множество собственных проектов, в т.ч. довольно успешных, сейчас уже несколько лет работаю на себя, сам нанимал разработчиков и себе, и в другие компании.

Если человек приходит на собеседование, я никогда не спрашиваю его по методичке "30 вопросов программисту на собеседовании" и, тем более, не спрашиваю у него детали технической части или той или иной версии языка. Мне своё время дороже.
Зато я всегда смотрю код, который человек писал (все технические детали и подходы - тут налицо), даю тестовое задание (становятся очевидны желание, масштабы, скорость и возможность выполнять работу), спрашиваю о предыдущем опыте.
Этого более чем достаточно для определения его места в компании и его уровня ЗП.

Проблема, в том, что есть некоторые seniorы, тимлиды и техдиры, которые проводят собеседования по схеме и не способны видеть вне ее рамок.
Эти люди выросли и остановились в парадигме, которую можно обозначить как "цифровая бюрократия".
Регулярно отрабатывая теоретические знания в рамках своих "собеседований", они сами хорошо разбираются в этих вопросах, но не разбираются в людях и не способны отличить экзамен от собеседования.
Одно и то же, раз за разом - они досконально знают "все 5.5 способов проверить валидность этой строки", "чем отличается эта функция git'a от этой, с таким-то параметром" или "а вот что вы можете рассказать о таком-то шаблоне"...

Так вот, экзамен, это проверка, что человек должен знать конкретные ответы на конкретные вопросы. Экзамен бывает уместен только в том случае, когда хочется снизить планку ЗП.
Либо, не имея достаточно ума донести целесообразность снижения ставки иным способом, либо не понимая, что деньги являются мотивацией сотрудника (хорошо) выполнять свою работу, либо возникли такие обстоятельства, что вы очень хотите получить этого человека, а денег вдруг нет. Трюк грязный, но иногда работает.

Пора уже вырасти и понять, что работа разработчика - это не заученные концепции, а способность решать задачи (желательно, наиболее оптимальным для этого способом), умение находить ответы, видеть варианты, личный опыт.
Деньги платят за результативную работу, а не успешную подготовку.

Не всякий разработчик должен знать то, что вам кажется очевидным. Не всякий имеет возможность вспомнить "правильный ответ" здесь и сейчас.
Вот только как насчет того, что за его плечами имеется такой опыт, что иной вопрос, само-собой разумеется, им уже успешно решался или решится за 10 мин. - в рамках практической работы, даже если он этого вопроса не касался никогда.
Вы точно умеете распознавать это в ваших собеседованиях, среди всех этих вопросов о конкатенации строк, кол-ва типов переменных или уровнях изоляции транзакций БД?
Когда вы устраиваете экзамен вместо собеседования, возможно, вы просто делаете не свою работу. Лучше просто пишите скрипты.
Толковых людей всегда нужно поискать, потому они и в цене, а вы их, скорее всего, упускаете, вредите компании, отталкивая нужных людей, затягивая бизнес процессы или набирая таких же "скриптописателей".

Собеседование - это выявление навыков, желания и возможности работать, развиваться. Личные качества тут важнее технических знаний и, тем более, заученных ответов.
На энтузиазме можно освоить новый фреймворк за месяц, даже если ты вообще не работал с фреймворками. Но для "цифрового бюрократа" ты уже неподходящий кандидат, ведь ты "даже не работал с миграциями и тестами".

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

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже