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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Горячие события

Конкурс EY Entrepreneur Of The Year 2020
31 мая

Конкурс EY Entrepreneur Of The Year 2020

EMERGE 2020
1 июня — 3 июня

EMERGE 2020

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»
4 июня

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»

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

HackerEarth: Go снова назван самым востребованным языком среди программистов
HackerEarth: Go снова назван самым востребованным языком среди программистов

HackerEarth: Go снова назван самым востребованным языком среди программистов

150+ ИТ-компаний продолжают нанимать. Обновляем список
150+ ИТ-компаний продолжают нанимать. Обновляем список

150+ ИТ-компаний продолжают нанимать. Обновляем список

17 комментариев
20 вещей, которые я вынес за 20 лет в программировании
20 вещей, которые я вынес за 20 лет в программировании

20 вещей, которые я вынес за 20 лет в программировании

Программист Schibsted Алекс Эвелёф в блоге на Medium рассказал о главных правилах и принципах, которые вывел для себя за многие годы работы в ИТ. Публикуем перевод статьи.
12 комментариев
Wolfram открыла доступ к своему движку для разработчиков
Wolfram открыла доступ к своему движку для разработчиков

Wolfram открыла доступ к своему движку для разработчиков

Обсуждение

-4

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

10

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

Pavel Seradzenka
Pavel Seradzenka QA Engineer в Klika Tech
-3

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

2

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

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

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

5

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

vsv
vsv
0

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

1

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

10

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

7

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

5

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

-3

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

3

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

4

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

1

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

1

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

0

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

13

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

0

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

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

2

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

0

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

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

drew
drew ведущий инженер-программист в SCAND
1

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

12

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

3

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

-2

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

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

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

0

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

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

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

0

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

1

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

Спасибо! 

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

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