Краткая инструкция по найму нормальных людей в ИТ Статьи редакции

Материал автора блога о технологиях «Вастрик.Инсайд».

Привет, Олимпийский!

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

Сортировки и кручёные деревья давно стали мемами говноинтервью. Но как делать правильно, никто так и не рассказал. Попробую я.

Для более удобного чтения рекомендую сразу открывать веб-версию, потому что получился опять лонгрид. Кто не читал выпуск «Войти в айти» — тоже рекомендую. Они во многом пересекаются.

По двум причинам.

Практическая: никто не придумал ЕГЭ для айтишников. Нет универсальной для всех линейки. Стандартные приставки «джун-мидл-сеньор-лид» помогают не больше, чем найденная в лесу палочка построить космический корабль. Потому в каждой компании свои грейды, и сеньор из одной может оказаться недомидлом в другой. Давно пора уже сделать единый стандарт коммьюнити, но пока я такого не встречал (покажете?).

Теоретическая причина чуть сложнее: слишком большое разнообразие необходимых навыков. Получается, что нужна не одна, а более 140 линеек, причём в каждой компании их набор будет свой.

Да он ещё и будет меняться с ростом компании: если в начале выгоднее нанимать тех, кто «с горящими глазам», то в годы стабильности, IPO и текущего по щекам ревенью такие инженеры слишком опасны, и к ним обычно нанимают 9000 дидов-бюрократов, чтобы отвлекать их процессами.

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

Суровая правда жизни, из которой логично вытекает следующий пункт.

Популярная дурная практика — копировать интервью крупных компаний. Культ карго вообще любимое развлечение в ИТ. После выхода книжки про собеседования в Microsoft о круглых люках и шариках для гольфа спрашивали ещё лет десять. Сейчас чудом прекратили.

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

Говно ли это? Да. Зато такой отсев экономит много бабла, а значит, для кровавого корпората это эффективно. Таковы правила игры: хочешь гугловскую зарплатку и ДМС — будь готов месяц на фултайме сидеть над Cracking Code Interview вперемешку с Корменом и в любое время суток размышлять, сколько мячей поместится в Эмпайр-стейт-билдинг.

С другой стороны, есть стартапы, которым пофиг, сколько сортировок ты знаешь, зато жизненно необходимо, чтобы ты делал дела и вписался в команду. Чтобы все были «на одной волне», или like-minded, как там любят говорить. Для них собеседование с пивом в парке — офигенно эффективный процесс, отсеивающий душных дидов.

К сожалению, в реальности же мало кто настолько честен с собой, чтобы прямо сказать: «Ну, мы делаем интернет-магазин, для этого много ума не надо». Все же поголовно больны уникальными корпоративными ценностями и «отбирают только лучших». По крайней мере так написано в той HR-презентации. PowerPoint ведь, как известно, врать не будет.

Если у вас есть внутренние специалисты по найму — вы прекрасны и великолепны, смело пропускайте эту главу. Часто их нет, потому остаётся два варианта.

Первый — рекрутеры-аутсорсеры. Это рак ИТ. Они срали на рынок, компании и кандидатов, но неплохо живут за их счёт, получая по одной-две месячных зарплаты каждого найденого кандидата.

Работают по одному шаблону, которым массово спамят везде: «Доброго времени суток, %username%. Мы заметили у вас большой опыт в %programming_language% и %framework_name%. Для вас уникальная работа в Европейской Компании ООО “Домофон Блокчейн Ltd”. Возможна релокация в Воронеж. Подробности расскажу по телефону. Приготовьте веб-камеру. Название компании под NDA».

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

Когда-нибудь их всех заменят скриптами.

Остаётся второй вариант: искать самим. Пишем честный текст вакансии, пытаясь избежать штампов про «кофе-печеньки-лидеры-рынка», размещаем на одном из популярных сайтов и ждём. Не верьте в сказки, что «хорошие кандидаты сами не приходят» — приходят, да ещё как. Главное — честность. Она привлекает именно тех, кто нужен. Если вы команда распиздяев — так и напишите.

А денежные бонусы лучше платите своим же работникам за приведённых рефералов. Вот и вся тайна.

Цель любого интервью — принять бинарное решение «да» или «нет», и есть лишь три качества в кандидате, на которые надо смотреть. Чувак не подходит хотя бы по одному — сорян, до свидания. Такие вещи не подтягиваются за год, так что на моей памяти компромиссы ни разу не заканчивались хорошо.

Первые два качества взяты из статьи Джоэла Спольски “The Guerrilla Guide to Interviewing (version 3.0)”, которая сама по себе тоже ок (спасибо, Максим Базаров).

Не стоит путать со знаниями, начитанностью или уровнем IQ. Дипломы олимпиад от говнокода не спасают. Синтетические тесты или вопросы на знания алгоритмов — полный булщит, означающий, что интервьюер вообще не понимает, как делать свою работу (ну либо таков процесс, смотри первую главу).

Ум — это умение рассуждать, задавать вопросы, анализировать аргументы, не делать поспешных выводов, видеть плюсы и минусы решений, процессов, фреймворков. Особенно своих.

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

Get Shit Done, как ёмко называют это умение в английских статьях. Чем моложе и свежее проект — тем больше ему нужны люди, умеющие за неделю на коленке нафигачить стартап. Старым и стабильным проектам, наоборот: чем меньше люди фигачат фичи и больше думают о логике — тем лучше. Если бы Google давала каждому джуну коммитить в мастер, представляете, что бы началось? Так что снова надо знать баланс.

Определить умение делать дела просто — по прямоте ответов на задаваемые вопросы и пресловутым «горящим глазам». Даже если они горят ненавистью ко всему ИТ — этот чувак точно соберёт MVP за неделю.

У умения делать дела есть неприятная особенность: оно уменьшается с ростом мудрости.

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

Брать даже самого умного ботана в команду высокоэффективных алкашей — хреновая затея. «Ниндзя-суперстар» так же сгниёт в команде, в которой переименование файла надо согласовывать с тимлидом (тру стори), а для исправления опечаток назначают сторипоинты.

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

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

Умные интервьюеры помнят, что избавиться от собственной необъективности невозможно, но можно пытаться её обмануть. Много лет назад я придумал свой универсальный способ избегать предвзятость.

Любой вопрос вида «а знает ли он» — провал со стороны интервьюера. Он не знает, а ты знаешь (прочитал об этом пять минут назад или запомнил с универа) — значит, кандидат говно, да? Нет. Говно здесь интервьюер, который не догадывается о собственной предвзятости.

Правильная постановка вопроса — «понять, умеет ли он». Дальше разбираем вместе варианты и оцениваем по трём качествам выше. Всё.

Вопросы не должны быть попыткой самоутвердиться знанием слов «интрузивный список» и запоминанием наизусть статьи про нажатие Enter в браузере или любой другой, что вы недавно прочитали.

Когда вы нанимаете джуна — ок, это может быть условным маркером, что он прочитал две рекомендованные на лето книжки. Сеньор же к своим годам повидал столько говна, что 90% из него он уже тупо забыл.

В универе, например, я помнил наизусть все кодировки юникода и мог прочитать строку циклом по байтам, соблюдая BOM. Сейчас я без гугления даже не назову разницу между UTF-8 и UTF-16. Значит ли это, что я безграмотное быдло? Конечно! Но менее опытным программистом я от этого не становлюсь.

К сожалению, в большинстве случаев на всё забивают и делают интервью по принципу «тимлид с тем чуваком из команды, которому лень сегодня работать, допрашивают, какая функция обрезает строку в РНР».

Напомню, как выглядит классический процесс найма:

• Скрининг эйчаром на предмет общей адекватности и соответствию вакансии.
• Техническое интервью (от одного до бесконечности).
• Разговор с одним из главных инженеров о ценностях, порядках входа в хату и leadership principles (это та хрень, которой сегодня заменили «коммуникабельность» и «нацеленность на результат», когда все стали над ними слишком уж откровенно ржать).
• Оффер, и все пьют.

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

Не пытайтесь упихать все этапы в истощающий интервью-марафон. Всё это отлично делится на несколько 30-минутных разговоров

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

• Мы в %company_name% занимаемся тем-то.
• Наша команда делает то-то для того-то (чтобы стало понятно зачем).
• Нас N человек, из которых M разработчиков, и так далее (команда и процессы).
• Мы пишем всё на %language_name% с использованием %framework_name% и %database_name% (описание стека).
• Сейчас ищем новых людей, чтобы то-то (планы и понимание, что будем пилить).

Всё. Вы великолепны.

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

• Я Олег, пишу на том-то столько-то лет.
• Сейчас работаю в %company_name%, занимаюсь тем-то (рассказ о настоящем).
• Мы всё делаем на том-то с использованием вон той модной хрени (текущий стек).
• Раньше я занимался тем-то и сделал то-то (рассказ о прошлом и опыте работы).
• Мы делали то-то, а потом то-то, а самое крутое было то-то (более общий технический бэкграунд).

По желанию рассказ можно разбавить пруфами и фактами. Если какой-то из пунктов упущен — про него можно спросить на следующем шаге.

Место, где начинается собеседование. Здесь стоит вспомнить, что мы нанимаем не продажника с Уолл-стрит. Перед нами инженер, который так запуган книжками про интервью, что уже заранее принял позу для вращения деревьев и выписал на руке основные свойства нотации Big-O.

Потому я всегда начинаю с простейших технических вопросов чтобы пробить стену «свой-чужой», настроить на равный диалог и оценить общую инженерскую адекватность. Не больше пяти минут.

• Какой твой любимый язык или фреймворк? Теперь расскажи его минусы.
• Почему вообще программируешь и что тебя драйвит?
• Ты сеньор и можешь дать один совет себе джуну 10–20 лет назад. Какой он будет? (Спасибо, @theKashey.)

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

Когда контакт установлен, можно бомбить заданиями. Обычно время есть на одно максимум, так что выбирайте с умом. Сразу приведу примеры идиотских и бесполезных из популярных:

• «Какая функция делает X», «какие бывают У», «как работает Z» — и другие вопросы теории. Пустая трата времени и яркий звонок, что интервьюер некомпетентен, контора — говно и надо сразу прощаться.
• «Что происходит после нажатия Enter в браузере». После выхода той самой статьи на «Хабре» все прям заболели этим вопросом. Ничего, кроме потехи самолюбия, этот вопрос не даёт.
• Задачки на монетки, верёвочки и «горы Фудзи». Устарело лет пять назад, и все так и не смогли понять, зачем их спрашивали.
• «Ваши слабые стороны», «личные достижения», «проблемы, с которыми столкнулись» и так далее. В 100% случаях получите социально одобряемый ответ или домашнюю заготовку. Никто не будет отвечать на такое честно. (Спасибо, @skv_nskv.)
• Лайв-кодинг в Whiteboard или «Google Документах». Унизительная практика, особенно когда это делают на время (почти всегда). Хотите понаблюдать, как человек пишет код (зачем-то), — сядьте рядом, займитесь парным программированием в любимом IDE. «Google Документы» хороши, чтобы накидать варианты решений, не более.

Теперь хорошие:

• Давать упрощённую версию задачи, которую сами недавно решали. Мой любимый вариант. Кандидат сразу понимает, чем занимается команда, а команда видит, насколько кандидату это интересно. Проходит в режиме диалога: как бы ты решал? А какие ограничения? А что тут использовал бы? (Спасибо, @crecotun.)
• Как бы ты спроектировал продукт, похожий на наш. Подходит для молодых продуктов или строгих правил NDA. Можно взять похожий продукт конкурентов и вместе разобрать. (Спасибо, @tapokshot и @sshbrnv.)
• Вот пул-реквест, сделанный одним из наших джуниоров. Сделайте код-ревью. Кандидат видит реальный проект, а интервьюер умение читать, писать, обсуждать код без фанатизма и истерик. (Спасибо, @chaos_helga.)
• Расскажи о неоптимальном архитектурном решении в одном из твоих прошлых проектов и почему оно было принято. Инженер должен уметь принимать и обсуждать неоднозначные решения. (Спасибо, @lazeez.)

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

Самый адекватный вариант здесь — предложить тестовое задание на дом. Не больше чем на час-два. Именно предложить, не ограничивая по времени и обязательности его выполнения. Многие программисты по понятным причинам не любят тестовые, потому для них есть лайфхак:

Сам придерживаюсь такого подхода, и это мегаудобно. Интервьюеру не надо ждать несколько дней, а кандидату тратить вечер на очередные крестики-нолики. Даже если нет проектов — можно легально опубликовать на GitHub тестовое, сделанное для другой компании. Офигенно. Делайте так.

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

После вопроса можно откинуться в кресле и наслаждаться потоком звоночков, которые так и посыпятся в ответ, — от лживых шаблонов до глубоких инсайдов из жизни в ИТ. Звучит вопрос так:

Ну и сами на досуге подумайте. Пока.