IT интервью
Цель любого интервью — принять бинарное решение «да»/«нет», и есть лишь три качества в кандидате, на которые надо смотреть. Чувак не подходит хотя бы по одному — сорян, до свидания. Такие вещи не подтягиваются за год, так что на моей памяти компромиссы ни разу не заканчивались хорошо.
1. Мудрость (умность)
Не стоит путать со знаниями, начитанностью, или уровнем IQ. Дипломы олимпиад от говнокода не спасают. Синтетические тесты или вопросы на знания алгоритмов — полный булщит, означающий, что интервьюер вообще не понимает как делать свою работу (ну либо таков процесс).
Ум — это умение рассуждать, задавать вопросы, анализировать аргументы, не делать поспешных выводов, видеть плюсы и минусы решений, процессов, фреймворков. Особенно своих. Мудрость может заменяться опытом, но не всегда. Классический опыт — это скорее насмотренность, а чтобы превратить его в знания нужны еще несколько промежуточных шагов.
2. Умение делать дела
Get Shit Done, как ёмко называют это умение в английских статьях. Чем моложе и свежее проект — тем больше ему нужны люди, умеющие за неделю на коленке нафигачить стартап. Старым и стабильным проектам наоборот: чем меньше люди фигачат фичи и больше думают о логике — тем лучше. Если бы гугл давал каждому джуну коммитить в мастер, представляете что бы началось. Так что снова надо знать баланс.
Определить умение делать дела просто — по прямоте ответов на задаваемые вопросы и пресловутым «горящим глазам». Даже если они горят ненавистью ко всему айти — этот чувак точно соберёт MVP за неделю.
У умения делать дела есть неприятная особенность: оно уменьшается с ростом мудрости.
3. Совместимость с командой
Айти — командная игра, одиночки тут не конкурентны. На моей памяти, несовместимость человека с командой — одна из главных причин увольнений. Так что даже при совместимости остальных пунктов, остаётся третий — насколько кандидат «похож» на команду и сработается с ней.
Брать даже самого умного ботана в команду высокоэффективных алкашей — хреновая затея. «Ниндзя-суперстар» так же сгниёт в команде, в которой переименование файла надо согласовывать с тимлидом (тру-стори), а для исправления опечаток назначают сторипоинты.
При этом оба, оказавшись в правильном месте, могут стать гениями эффективности. Поэтому мудрые тимлиды умеют отказывать хорошим кандидатам, которые, к сожалению, не сойдутся с командой.
Любое интервью — это схватка двух якодзун, находящихся в заведомо неравном положении. Сторона компании владеет всей информацией и готова ко всему, кандидат — как студент, пришедший на экзамен без понятия по какому предмету.
Умные интервьюеры помнят, что избавиться от собственной необъективности невозможно, но можно пытаться её обмануть. Много лет назад я придумал свой универсальный способ избегать предвзятость.
Если ты задаёшь кандидату вопрос, на который есть однозначный ответ и ты его знаешь — это плохой вопрос.
Любой вопрос вида «а знает ли он» — провал со стороны интервьюера. Он не знает, а ты знаешь (прочитал об этом пять минут назад или запомнил с универа) — значит кандидат говно, да? Нет. Говно здесь интервьюер, который не догадывается о собственной предвзятости.
Правильная постановка вопроса — «понять, умеет ли он». Дальше разбираем вместе варианты и оцениваем по трём качествам выше. Всё.
Хороша заготовочка со стороны кандидата «расскажи о себе». Во-первых, ради банального знакомства и дальнейших вопросов по резюме. Во-вторых, что важнее, для проверки первичных софт-скиллов. Не могу представить себе позицию выше джуна, на которой не пригодилось бы умение четко доносить свои мысли. План примерно такой:
Я Олег, пишу на том-то столько-то лет.
Сейчас работаю в %company_name%, занимаюсь тем-то (рассказ о настоящем).
Мы всё делаем на том-то с использованием вон той модной хрени (текущий стек).
Раньше я занимался тем-то и сделал то-то (рассказ о прошлом и опыте работы).
Мы делали то-то, а потом то-то, а самое крутое было то-то (более общий технический бекграунд).
По желанию рассказ можно разбавить пруфами и фактами.
Когда контакт установлен, можно бомбить заданиями. Например:
• Давать упрощенную версию задачи, которую сами недавно решали.
Мой любимый вариант. Кандидат сразу понимает чем занимается команда, а команда видит насколько кандидату это интересно. Проходит в режиме диалога: как бы ты решал? А какие ограничения? А что тут использовал бы?
• Как бы ты спроектировал продукт, похожий на наш.
Подходит для молодых продуктов или строгих правил NDA. Можно взять похожий продукт конкурентов и вместе разобрать.
• Вот пул-реквест, сделанный одним из наших джуниоров. Сделайте код-ревью.
Кандидат видит реальный проект, а интервьюер умение читать, писать, обсуждать код без фанатизма и истерик.
• Расскажи о неоптимальном архитектурном решении в одном из твоих прошлых проектов и почему оно было принято.
Инженер должен уметь принимать и обсуждать неоднозначные решения.
+ Наличие кода на гитхабе заменяет тестовое на 100%.
Сам придерживаюсь такого подхода и это мега-удобно. Интервьюеру не надо ждать несколько дней, а кандидату тратить вечер на очередные крестики-нолики. Даже если нет проектов — можно легально выложить на гитхаб тестовое, сделанное для другой компании. Офигенно. Делайте так.