Я нанимаю людей постоянно. На самые разные позиции и роли. Мне также требуется растить людей в своей команде, помогая им пробовать себя в совершенно непривычных для них ролях. Возможно, мне просто везёт, и у меня всё получается в 9 из 10 случаев. Случаются провалы, которые почти всегда можно объяснить как минимум двумя факторами: неучтённый бэкграунд человека и его (или её) банальная усталость.
Я хорошо насмотрен на людей и их поведение в командах. Предположу, что кроме везения, у меня есть какое-то врождённое умение видеть в людях перспективу. Всё это помогает мне создавать надёжные команды, которые способны решать самые разные задачи.
Так вот, эта статья будет про найм людей в команду. Про мои убеждения в прошлом и обновлённые убеждения в настоящем. Надеюсь, что моя статья поможет кому-то пересмотреть свои взгляды. Даже если это будет всего пара человек.
В общем, так вышло, что примерно 10 лет назад я незаметно для самого себя впервые стал тимлидом и начал участвовать в найме вместе с тогдашним техническим директором. Техдиректор был очень строгим и требовал от кандидатов не просто уверенных знаний, а понимания фундамента Computer Science. Это выглядело логично. Помимо простых вопросов про технологии и инструменты, он задавал вопросы про алгоритмы, разные задачки "на подумать". Иногда даже давали тестовые задания и уже тогда устраивали лайвкодинг. Здесь важно отметить, что лайвкодинг 10 лет назад — это не звонок в Zoom, а ситуация, когда тебе дают ноутбук и ты реально печатаешь код. На доске или бумаге, как правило, не писали, хотя пару раз и такое случалось. Сейчас, возможно, это звучит кринжово, но 10 лет назад было вполне реальностью: тебя могли попросить объяснить однострочник из bash, написанный от руки на листе А4.
Найм был чаще всего в 1 или максимум 2 этапа. HR-ы обзванивали кандидатов, а те приходили и по очереди собеседовались. Чаще всего (по крайней мере у нас) кандидаты даже не пересекались между собой. HR заходила в кабинет, говорила: "Петров вас ждёт" — и мы шли его собеседовать. Кстати, я не помню, чтобы были проблемы с тем, чтобы назначить сразу 3–5 собесов на день. Люди приезжали. Мы видели их, они видели нас. Сразу же видели офис и то, как всё устроено. Видели атмосферу. Кто-то удивлялся многоэтажному мату из кабинета аккаунт-менеджеров (да, нужна разрядка после разговоров с клиентами, ну а что вы хотели), кто-то отмечал уютную кофе-зону. Тогда ещё мало кто ожидал увидеть в офисах отдельные кабинеты врача, психолога, массажиста. Есть неограниченный кофе и печеньки — уже супер. Столы и стулья в порядке — кайф. Если меня сейчас читают те, кому ещё нет 25–27 лет, поверьте: бывало всякое. А то, что сейчас считается нормой, раньше было жирным плюсом в пользу работодателя. Хотя, наверное, и сейчас далеко не все офисы уютные.
Но не об этом речь.
Найм был процессом, построенным как сдача экзамена. Сидит "препод", задаёт вопросы. Ты пытаешься ответить более или менее подходяще. Успех сильно зависел от того, насколько кандидат умеет лавировать в диалоге и просить переформулировать вопрос, чтобы лучше понять. Я видел много людей, которые от напряжения краснели и терялись. Это были разные люди от 20 до 40 лет. Первые 5 минут они были бодрые, готовые идти в бой, а через пару вопросов "экзаменатора" сдувались, и собеседование скатывалось из формата "взрослый–взрослый" в "родитель–ребёнок", где "ребёнком", разумеется, был кандидат. Мне это уже тогда не нравилось. Примерно в то же время я прочёл у Татьяны Толстой историю про "мачизм", где "крутой мачо-преподаватель" что-то бубнит себе под нос, всё это непонятно, но он показывает видом и словами, что он круче всех присутствующих. Мне это не нравилось, но казалось, что так важно "прощупать" кандидата. Понять его сильные и слабые стороны. Определить границы знаний.
Через несколько лет, работая в другой компании, где я мог выстраивать структуру собеседования и требования так, как мне хочется, HR-ы всё так же делали первичный профайлинг (или скрининг) и передавали мне резюме. Я не помню почему (возможно, потому что пришёл на собеседование после очень бурной ночи и не готовил вопросов), но я не стал вести его как раньше: с академическими расспросами и "пристрастием". Никаких олимпиадных задач, "круглых люков" и интеллектуального пинг-понга с человеком, которому даже ракетку не дали. Я начал спрашивать про то, что интересно ему. Рассказал про задачи, на которые мы ищем человека. Я говорил больше кандидата. Делился информацией, спрашивал мнение. Это не было тестом или экзаменом. Да, я делал себе короткие пометки на листе А4, но когда видел, что человек напрягается от этого, говорил прямо: "У меня не всё ок с памятью, впереди ещё много собеседований, просто хочу запомнить диалог". Я общался так, как хотел бы, чтобы общались со мной. Разумеется, я отмечал важные моменты, о которых рассказывал кандидат. В спокойной обстановке человек раскрывался лучше. Он сам говорил о своих недостатках и пробелах. Это оказалось очень полезно: собеседование не превращалось в пустую болтовню, но при этом давало понять, подходит ли кандидат. Используя такой подход, я собирал отличные команды.
Позже я прочёл заметку про то, что в переговорах желательно держаться позиции "я нормальный — ты нормальный". Ещё позже осознал: большинство "собесов с пристрастием" проводятся там, где есть страхи потерять место из-за более скиллованных кандидатов. IT-индустрия сильно поменялась за последние 10–15 лет. Раньше она не была сверхпопулярной. Туда попадали самые разные люди, чаще всего (!) просто из интереса. Были и тогда best practices, фреймворки, паттерны, алгоритмы. Фундаментально ничего не изменилось. Инструменты стали где-то лучше, где-то хуже. Появились новые роли (например, вместо сисадмина теперь есть разные Ops). Это нормально. Ненормальным стало другое: требования и "экзамены" на собесах усложнились и перестали быть сопоставимыми с реальными задачами.
Недавно я общался с бывшим коллегой, которого когда-то нанимал к себе. Он пожаловался, что с его опытом стало трудно проходить формальные части собеседований. Я не хочу называть бренды, вы и так понимаете о ком речь. "В открытом бою" он бы спокойно дожимал и разбивал на голову всех интервьюеров с лайвкодингом и олимпиадными задачами. Но почти никто не давал фидбэк и никогда не интересовался его реальными проектами. Он не понимал, почему HR-ы задают вопросы про RPS и архитектурные решения, слушают его кейсы — а потом это никак не учитывается на следующих этапах. Да, иногда он не был готов сходу разобрать какую-то задачу. Мозг так устроен: не всегда можно ответить мгновенно. Нужно подумать, куда-то заглянуть. Собеседование — не экзамен, но последние 10 лет его именно в экзамен и превратили "эффективные менеджеры". Ты можешь построить за 10–15 лет огромные системы, быть универсалом, но если на техсобесе не напишешь моментально алгоритм брутфорса хэшей или не решишь задачу с LeetCode, всё обнуляется. Это ужасно демотивирует. Коллега сказал: "Как будто от опытных специалистов намеренно защищаются, чтобы не дай бог не создать эдакий вендор-лок на разработчика".
Конечно же фундаментальные знания важны. Здорово, когда кандидат на инженерную позицию отлично разбирается в математике, алгоритмах, вслепую пишет любой код на целевом языке без IDE и тем более LLM. Но это не так важно, как иметь живой ум и иметь за плечами реальные результаты, которые адекватный интевьювер может оценить задав несколько целевых вопросов, если будет сам же готов это сделать. Без лайвкодинга, без окунания собеседника с опытом 10+ лет реального продакшна в задачи, которые не связаны с реальными бизнесовыми кейсами, где 90% времени тратится далеко не сам код, алгоритмы или что-нибудь в этом духе. С точки зрения современного работодателя, все должно быть решено под запись на камеру, за самое короткое время и без права даже открыть собственную вики, которую собирал все эти годы, пока копил опыт. Одна ошибка и ты ошибся, как говорится.
— К сожалению, сейчас мы не готовы пригласить Вас на следующий этап, т.к. остановились на другом кандидате. Желаем вам удачи в дальнейших поисках работы и успехов в карьере.
— Ну да, спасибо за фидбек, вам виднее, вы ведь опытные разработчики и разбирающиеся в людях HR-ы.
— Кто вам сказал?
— Но вы ведь ведете интервью, следите за тем как я пишу код и задаете умные вопросы. Такие задачи придумали, я бы даже не догадался, что можно так сложно задать вопрос с таким простым решением.
— Разработчики типа меня попали в компанию еще до того, как HR-ы придумали карьерные лестницы и ежегодный ассесмент. Вы — доверчивый осел, мистер Пеппердайн. То, что я по ту сторону экрана задаю вам вопросы, не делает меня опытным инженером. Вы даже мой код не видели. Я — мошенник, а вы — дебил.
Как вы поняли, мое мнение поводу многоступенчатых наймов и требований изменилось. Безусловно, есть задачи, которые требуют сложных интервью и особых навыков. Брать программиста, который писал только плагины под Wordpress (что, кстати, заслуживает отдельного уважения к его терпению), на позицию разработчика высоконагруженных приложений будет, мягко говоря, неправильно. Такие требования можно заранее заложить в вакансию. Люди умеют оценивать себя и когда видят, что в вакансии явно указаны конкретные вещи, а не абстрактные "опыт asyncio/threading и умение работать с Redis/Clickhouse", то дважды подумают прежде чем откликаться "на удачу". Напишите явно "у нас столько RPS, такие-то сложности, поэтому хотим вот такого специалиста". Все это можно и нужно детализировать. При этом всё, что больше двух встреч — это оверкилл и откровенная трата времени. Ни одна IT компания не стоит, чтобы тратить на нее столько времени, нервов и получать пинок демотивации. Масла в огонь еще подливают молодые HR-ы, которые не ориентируются в технологиях и реагируют только на триггерные названия, но это совсем другая история.
Честно говоря, я не очень надеюсь, что ситуация будет меняться. Скорее всего, корпорации так и будут закручивать гайки, создавать дополнительные сложности и набивать себе цену экзаменами — не хуже, чем при поступлении на самый сложный матфакультет вуза, — чтобы потом кандидат ощущал большую ценность от того, что прошёл все эти преграды, и не свалил после первых митингов с не вполне адекватным менеджментом, токсичной командой и абсолютно дебильными задачами по перекрашиванию кнопок в приложении, написанном на фреймворке людьми, которым было просто интересно его сделать и которые с очень высокой вероятностью сами бы никогда не прошли подобные собеседования.