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

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

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

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

Идеального собеседования не существует

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

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

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

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

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

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

Знай место между селом и Google

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

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

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

Как в той истории с автором Homebrew, которого не взяли на работу в Google

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

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

Корпоративная честность с собой — большая редкость.

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

Где искать людей

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

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

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

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

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

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

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

Только три качества кандидата, на которые надо смотреть

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

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

1. Мудрость (умность)

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

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

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

2. Умение делать дела

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

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

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

3. Совместимость с командой

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

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

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

Как избегать собственную необъективность

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

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

Если ты задаёшь кандидату вопрос, на который есть однозначный ответ и ты его знаешь, — это плохой вопрос.

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

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

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

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

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

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

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

Структура хорошего технического интервью

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

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

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

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

Шаг первый: рассказ о компании, продукте, задачах и планах

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

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

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

Шаг второй: «Расскажи о себе»

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

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

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

Шаг третий: смоллтолк за жизнь и технологии

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

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

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

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

Шаг четвёртый: настоящая задачка

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

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

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

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

Шаг пятый: тестовое на дом

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

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

Наличие кода на GitHub заменяет тестовое на 100%.

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

Шаг шестой: вопросы от кандидата

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

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

Вы счастливы делать то, что делаете? Почему?

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

Вадим Скворцов

Рубрика: 
Ключевые слова: 
+1
0
-1