Несмотря на всю гиковость и любовь к юниксам, автор все же имеет должность CTO не просто так, поэтому история на этот раз не о технологиях — раскрываю тему найма очень умных людей, обремененных техническим образованием.
Вводная
Ниже описаны некоторые… не совсем обычные методы проверок будущего техлида, которые автор собрал за долгую практику и на основе личного опыта.
Под общим термином «техлид» в зависимости от ситуации, масштаба проекта и отрасли подразумеваются:
тимлиды, архитекторы и
сеньоры-помидорыведущие программисты.
В редких случаях — CTO, если речь про стартап на начальном этапе.
Это те люди, которым придется доверить ваш проект и именно от них будет зависеть его (проекта) выживаемость. Поэтому вопрос найма правильного техлида будет стоять остро в любое время и в любой компании.
Возможно вы сочтете описанные методы неприятными, если вообще законными — ваше право.
Но они работают и действительно помогают в непростом деле найма ключевого технического специалиста.
Базовые принципы найма «людей с признаками интеллекта» автор раскрывал ранее в другой интересной статье (которую пока не перенес на Хабр), сегодня будет про сам процесс собеседования «персонала с высоким уровнем технических компетенций».
Точнее про некоторые специфические трюки, связанные с этим непростым процессом.
Disclaimer
Пожалуйста не пытайтесь применять подобное при собеседовании обычных и тем более начинающих разработчиков — в самом лучшем случае вас не поймут.
В худшем — загоните несчастного кандидата в нервный срыв, депрессию или дурку.
Смысл и цель каждого трюка также приведены, но не рекомендую применять все сразу на одном кандидате — может и не выдержать.
Также сразу замечу, что описанное в статье не сработает если интервьюер не имеет достаточного опыта и серьезных технических компетенций — чудес нет и «технический идиот» никогда не сможет нанять технически грамотного.
Проверка первая: ложь чистой воды
Во время собеседования, после начальной стадии спокойного общения с кандидатом на профессиональные темы, когда ему уже стало понятно что интервьюер — не дурак и тоже что‑то понимает в профессии, вы (интервьюер) спокойно начинаете.. пороть откровенную техническую ересь.
Дайте волю фантазии: «идеальная архитектура системы это фрактал», «приличный программист должен собрать себе компилятор», «кластеры метаданных, которые бороздят просторы инфопространства», «лучший тип данных это строка» — в таком духе.
Если нехватает своей фантазии — возьмите одну из великих работ г-на Луговского и адаптируйте под ваш проект, благо это наилучшее их применение.
Идеально если у интервьюера есть определенная известность и авторитет — будет максимальный эффект.
Излагаемая вами «техноересь» не должна ощущаться искусственной, поэтому вы должны нести бред с серьезным выражением лица а не давясь от смеха — все должно выглядеть максимально правдоподобно.
Чтобы кандидат был полностью уверен, будто собеседующий его человек, еще минуту назад казавшийся умным, адекватным и опытным — на самом деле шиз, поехавший сектант или в лучшем случае наркоман.
Реакция на такой твист от кандидата на серьезную техническую должность — крайне важна и показательна.
Важнее воображаемых «репутационных потерь» и боязни что кандитат сбежит, громко хлопнув дверью.
Зачем все это нужно
Именно таких «авторитетных шизов» под которого вы только что намеренно закосили, нормальный техлид будет обязан отгонять от вашего проекта — временами кулаками и подручными средствами.
Не поверите, но таких персонажей (шизов с иллюзией компетенций) в любой крупной компании много:
всевозможные консультанты, свидетели «высоких технологий», адепты новых подходов, оракулы «свежего взгляда», просто компьютерные радикалы и «AI‑гробовщики», предрекающие скорую смерть программистам от ножа нейросетей — тысячи их.
Многие при этом имеют высокие должности и полномочия в компании.
Бывает, что такие внешние «консультанты» навешивают лапши на уши кому‑то из высшего менеджмента, после чего вниз по карьерной лестнице спускается разнарядка «внедрить немедленно» — такое в красках описано у например Игоря Ашманова.
Если вовремя не распознать техническую дичь и не пресечь разлагающее влияние подобных персонажей на проект и команду — работа будет завалена со стопроцентной гарантией, проверено неоднократно.
Если кандидат промолчит, не распознает и не остановит поток техноереси, сделает вид что не заметил или тем более начнет вам поддакивать — вам с ним не по пути.
Стоит понимать, что хороший техлид это в первую очередь сформировашийся профессионал, со своим собственным мнением, видением и наработанной практикой:
это что-то вроде кристаллической решетки — единственное что отделяет обычный уголь и сажу от алмаза.
Все это практически на уровне физиологии не позволит хорошему техлиду пропускать техноересь мимо ушей без реакции — его обязательно должно начать корежить.
Хотя существует и другая крайняя реакция на такую проверку:
кандидат включает турбо-режим «примадонны» — заламывает руки и громко возмущается «куда он попал и что тут вообще делает среди таких-то идиотов»
Имеет полное право, что сказать.
Зато вы сможете сразу оценить, как нанимаемый на ответственную должность человек будет взаимодействовать с будущими коллегами, не обремененными высшим техническим образованием и многими годами практики в ИТ.
Если не планируете превратить отдел разработки или всю компанию целиком в варьете или бордель — «примадонна» с блестками и истериками на рабочем месте вам врядли понадобится.
Увы, но умение спокойно реагировать на дурость окружающих, вежливо отправляя их по известному адресу это тоже ежедневная работа техлида, так что учите лучшие исторические практики и матчасть.
Проверка вторая: нерешаемая задача
Следующий подлый трюк заключается в том чтобы дать кандидату нерешаемую задачу и наслаждаться посмотреть на процесс решения.
Предупреждаю сразу:
это сложно, очень.
Надо специально заранее заморочиться и найти такую задачу, которая бы только выглядела невинно, но при этом не имела простого и быстрого решения.
Да, это жестоко и подло, да временами плохо заканчивалось — нервы выдерживали не у всех кандидатов и бывали… эксцессы.
Но риск получить по лицу несопоставим с последствиями ошибочного найма, особенно в перспективе.
Зачем это надо
В реальной жизни далеко не все задачи решаемы в принципе, не все можно реализовать, исправить или починить, особенно за ограниченное время и с ограниченными ресурсами.
У программистов (даже очень крутых) часто отсутствует ощущение времени и не менее часто есть раздутое до небес эго, не позволяющее признавать собственные ошибки ни в каком виде.
Считаю что хороший техлид не может позволить себе такое отношение, поскольку отвечает за проект и/или команду разработки а не только за себя одного.
Одна из ключевых задач техлида — распознавать подобные нерешаемые проблемы и вовремя их обходить, вместо того чтобы биться головой об стену в поисках решения.
Плюс отношение к ошибкам и провалам:
Да, мы совершили ошибку, которая заключалась в.. , обсудим на ретроспективе а сейчас едем дальше.
но не:
Обожемой как же я весь такой гениальный мог ошибиться! Не может быть! Покарай меня Господь!
Рефлексия это конечно хорошо, но в свободное время а не посреди горящего проекта, еще и заботливо поливаемого керосином руками инвестора, заказчика или дорогих пользователей.
Кстати заметил, что цель и смысл этого трюка почему‑то очевидны любому сколь‑нибудь приличному управленцу, но «чистых айтишников» он стабильно вгоняет в ступор.
Проверка третья: шатание скреп
К сожалению в современном ИТ стало слишком много фанатизма и все меньше нормальной инженерной работы, что влияет на мышление разработчиков, часто вгоняя последних в религиозный экстаз:
выбор операционной системы, языка программирования и даже рабочего инструментария ныне являются вопросами веры и религии а не инженерной необходимости.
Хороший технический лид должен быть как минимум толерантен в таких вопросах, как максимум — спокойно использовать все что есть под рукой.
Это важно, поскольку в любом дружном коллективе программистов обязательно будут приверженцы противоположных взглядов на разработку.
И переубедить всех не получится.
Так что задача заключается в проверке кандидата на «технический фанатизм» и религиозную нетерпимость к чужим технологиям.
Какой самый простой способ выбесить фанатика?
Правильно:
начать оскорблять его веру.
Что и необходимо проделать во время интервью. Сначала выясняются предпочтения кандидата и его «любимые игрушки»:
линуксоид он или маковод, адепт технологий Microsoft, которые «просто работают» или фанат Java, которая «не тормозит» — вариантов много.
Дальше на любимую технологию ставится «сапог объективной реальности», попирающий и саму «любимую игрушку» кандидата и ее «избранность, идеальность и божественность».
У каждой технологии, языка и фреймворка обязательно есть проблемы и больные места, которые обычно идеально знают интернет‑тролли и используют эту информацию чтобы выбешивать людей в интернете.
Вам нужно сделать тоже самое и внимательно следить за реакцией:
если кандидат в техлиды не признает и в упор не видит никаких недостатков у любимой технологии — все плохо и печально.
Потому что религиозный фанатизм не совместим с серьезной работой и такой «киберфанатик» точно наломает дров в погоне за распространением любимой компьютерной шизы, а поставленный руководить (не дай бог) — вверенную команду немедленно развалит, коллектив переругается и разбежится в разные стороны.
И это не просто частное мнение автора, а увы — его печальный опыт.
Современные реалии (в качестве дополнения)
Пандемия с последующим переходом на удаленный формат работы и наплыв огромного количества самых настоящих жуликов в отрасль, породила новую проблему:
как понять, что перед вами именно тот человек, чье резюме вы читаете и который действительно затем выйдет на работу.
А не подставной, нанятый для разового прохождения технического интервью и с подделанным с помощью AI изображением с камеры.
Да, к сожалению такого стало много, AI‑развивается семимильными шагами и инструменты для «потоковой подделки» лица совершенствуются с каждым днем.
А должности, требующие большого стажа и подтвержденного опыта, но при этом допускающие удаленный формат работы являются для таких жуликов желанной целью.
Очень уж велик соблазн влезть на senior-позицию в крупную компанию и дурковать как можно дольше, списывая все провалы и отсутствие результатов на предшественников, кривую архитектуру, мировой кризис или депрессию.
Получая при этом стабильную и высокую зарплату.
Пройдут месяцы или даже годы пока такого персонажа отловят и уволят, причем скорее всего задним числом, поскольку доказать такое жульничество в суде крайне непросто.
Защита
В идеале любое собеседование на серьезную должность должно проводиться полностью и целиком очно — с личной встречей в офисе, что к сожалению (по многим причинам) происходит все реже.
Поэтому если судьба заставляет собеседовать удаленно, не видя человека в живую — стоит хотя-бы немного защититься от возможного жульничества.
Я (как интервьюер) просил кандидатов… подпрыгнуть или резко переместиться.
Разумеется заранее объяснив ситуацию и рассказав для чего все это нужно.
Звучит дико, но столь простая проверка быстро и просто показывает работу нейросети — поскольку AI еще не научились быстро обрабатывать в потоке резкие движения и при прыжке картинка сразу же поплывет и появятся очевидные артефакты.
Что и раскроет очередного жулика, желающего пожить нахаляву за счет компании.
Еще один рабочий вариант:
просьба сделать круговой обзор комнаты, в которой находится кандидат
Покажет присутствие посторонних помощников, второго монитора или еще каких технических ухищрений.
Тут встает сложный вопрос privacy и неприкосновенности частной жизни, но считаю, что собеседование это все же часть работы, так что фактически кандидат во время собеседования находится на рабочем месте.
И если уж так получилось что вы работаете из дома и ваше рабочее место находится рядом со спальней — убедитесь, что нижнее белье и прочие атрибуты личной жизни не попадают на камеру.
Эпилог
Понимаю возможное негодование «простых ИТ‑специалистов», считающих что собеседование должно быть не более чем пошаговой проверкой на соответствие техническим требованиям, с подсчетом баллов как в ЕГЭ.
Но перед тем как негодовать, стоит помнить, что описанное в этой статье, люди которые нанимаются таким проверками — одна из причин, по которой у простых разработчиков вообще есть работа.
Еще надеюсь, статья даст представление желающим «войти в ИТ» и взлететь сразу на высокую должность о реальном положении дел и позволит трезво взглянуть на свои шансы, благо автор такой не один и далек от мастерства в вопросах найма — есть куда более опытные и изощренные коллеги.
Конечно же актуальных методов «вывода на чистую воду» сильно больше и даже описанные в статье на практике не применяются «в лоб» а очень аккуратно адаптируются под конкретную ситуацию и кандидата.
Ну и на всякий случай напоминаю, что все описанное в статье выше — про найм профи, взрослых и состоявшихся в своей профессии людей, не истеричных «начинающих специалистов», делающих свои первые шаги в индустрии.
Не надо так заморачиваться на обычных собеседованиях.
P.S.
Оригинал статьи в более вольном изложении можно найти в нашем блоге, статья также была опубликована в Сетке (это новая социальная сеть от HH), где тоже вызвала определенный интерес.
Также добавлю, что ввиду печальной ситуации на рынке — наличия огромного количества опытных специалистов и одновременной невозможности взять их всех к себе на работу:
мы готовы помочь с проведением технических собеседований
если ваша компания сейчас нанимает.
Контакты в профиле.
Автор: alex0x08
