Вам знакомо чувство, когда пришел на собеседование на людей посмотреть, себя показать, а ушел со вспотевшими ладошками и в смешанных чувствах? С мыслями: «Ребята, ну неужели не понимаете, что так нельзя?». Недоумевая, почему собеседование превратилось в экзамен.
Много лет назад я был уверен, что когда «подрасту», то точно не стану повторять ошибок моих нанимателей. Но увы. Как только начал сам проводить собеседования — все повторилось. Я угодил в ту же ловушку, что и они.
Все было плохо
Во-первых, я искренне считал, что резюме должно быть четко структурированным и профессиональным. Должно быть одновременно полным, детализированным, но без утомительных подробностей. Разумеется, аккуратно оформленным и идеально грамотным. Желательно — без хвастовства и показухи. В общем, таким, чтобы после прочтения осталась одна мысль: «надо брать».
А так как не хотелось на сомнительного кандидата тратить лишнее время, огромное количество резюме отправлялось в корзину, потому что они были «не такие». Почти как в том анекдоте «А зачем нам неудачники», с той лишь разницей, что я все-таки тратил по 3-5 минут на резюме.
Представьте себе воронку: сначала отбирает HR (20-40%), потом отбираю я (10-20%), затем интервью с HR (60-80%), наконец, кандидат, в свою очередь, отбирает нас (20-40%).
Мы еще не дошли до технического интервью, а уже потеряли 99% кандидатов!
С теми же, кто прорвался сквозь эту воронку, я по классике затевал все эти занудные вопросы, начиная с «расскажите о себе». Потом задавал уточняющие вопросы, да так умело, что полчаса вылетало в трубу.
Ну а дальше на сцену выходил Его Величество Список. У вас в компании ведь тоже есть Список Вопросов Для Собеседования, не так ли?
Итак, я начинал беседу с базовых вопросов по Списку. Человек отвечал.
Копал глубже — отвечал.
Копал еще глубже. Оп-па, нащупал границу знаний в этой области. Так, теперь другая тема.
Ну понятно, все это тактично и аккуратно. Старался не додавливать кандидата по тем вопросам, на которые он ответить не мог. Хотя, каюсь, умение «не давить» тоже пришло не сразу.
В ходе собеседования я рисовал в голове этакое многомерное пространство. Каждая координатная ось представляла собой шкалу по определенной теме. В результате ответов получалась замкнутая область в этой системе координат. Этакое облачко знаний. И визуально представлял наложение этого многомерного облачка на облачко требований по вакансии.
Очень удобно.
В смысле, удобно для технаря, который не умеет в soft skills.
Все усугублялось тем, что соискателей много, а времени — мало. И Список-то ого-го какой длинный! Так что делать ювелирную работу было некогда. Собеседование неизбежно скатывалось в формат быстрых вопросов и ответов. То есть — в экзамен.
У моего поведения была и еще одна причина:
В юности (когда трава была зеленее, девчонки красивее, а программы 16-битные) я подрабатывал техником на родной кафедре. Принимал лабораторные работы по «Архитектуре ЭВМ». Ага, то еще название.
Так вот, в каждой группе было около 25 студентов, и только четверть из них хотела учиться. Хорошие результаты показывала от силы пара человек.
Дважды в неделю ко мне приходила разношерстная толпа из раздолбаев с редкими вкраплениями мотивированных студиозов. Добросовестные студенты приносили программы на куче разных языков с ассемблерными вставками. И не все эти языки были мне знакомы. Менее добросовестные приносили те же самые программы, но только написанные методом Ctrl+Ins и Shift+Ins (более удобные Ctrl+C и Ctrl+V приобрели популярность несколько позднее).
Код следовало оценить. Быстро. Очень быстро.
А еще — определить, кто же из них на самом деле автор.
И тут я понял, почему преподы задают глупые вопросы. Потому что на умные вопросы времени нет. Умные вопросы — для избранных.
(Позанудствую: также источником глупых вопросов бывают не очень умные люди. Или — не компетентные в данной области. Но мы оставим эти грязные инсинуации в скобках)
Глядя на код, я спрашивал самое тупое. Например: «А что такое AX?».
Тупо? Несомненно! Но ведь работает.
Через несколько секунд студент отправляется на пересдачу лабораторки.
Следующий студент уже знает, что такое AX. Но я его спрашиваю: «А сколько же в нем бит?». Все, пересдача.
Следующий знает, что это регистр и в нем 16 бит. Молодец.
— А вот тут у вас написано AH. Что это? — спрашиваю.
— Регистр
— Правильно, а сколько в нем бит?
Нда, пересдача.
Честно, я не хотел никого мучить, сам ведь недавно был на их месте. Просто старался максимально быстро и безболезненно отстреливать халявщиков.
Они упорно тащили какую-то магию на ассемблере, а объяснить, что притащили, не могли.
Поэтому, я оперативно выявлял лодырей и отправлял их домой. Пусть хотя бы конспекты почитают. Хотя бы чужие. Ну, или, на худой конец, методичку.
Мои требования были весьма приземленными. Кто знал, например, что такое «xor ax, ax» и почему это лучше чем «mov ax, 0» — получали зачет автоматом.
Ну а как еще можно поступать при жестком лимите по времени? И так дел невпроворот, а тут еще очередь соискателей. Из которых кто-то не умеет ничего. Или умеет, но совсем не то. Или то, но не так. Это надо оперативно выявить наиболее простым способом. То есть, задавая вопросы в темпе пулеметной очереди.
Наверняка каждый читатель может вспомнить массу потогонных интервью. И у каждой компании был свой Список Вопросов со своим Блэкджеком и задачами про гномиков. Видимо, компании полагают, что так они наиболее эффективно проверяют знания, опыт, умение соображать и навыки решения задач в стрессовой ситуации.
И я так поступал.
Решил, что так уж устроен мир, интервью обязано быть экзаменом. Может быть, чуть более вежливым, с прелюдией и постлюдией, но все же — экзаменом.
Но на волне постковидного «пузыря», когда поток кандидатов стал высыхать быстрее ручья в пустыне, данная техника стала сбоить. HR начали поминать меня незлым тихим словом. Начальство ненавязчиво интересовалось, почему там медленно ищем.
Тут-то я и призадумался. Кто сказал, что оценка знаний и опыта является целью собеседования или же экзамена?
До меня наконец дошло, почему все плохо
Цель экзамена: заставить студентов усвоить материал в объеме курса.
Цель собеседования: найти коллегу.
Ловушка, в которую я угодил, заключалась в неверном целеполагании.
Я не понимал таких простых вещей.
Можете закидать меня помидорами.
Конечно, понятие «коллега» у каждого свое. Но вряд ли оно является синонимом слов «сдавший экзамен». В моем представлении хороший коллега — это тот, кто поможет тащить проект. Остальное — второстепенно.
Еще раз: тащить со мной проект.
Это главный вопрос, который я держу в голове. Потащит ли?
Ну ок, определились. Следует найти спеца, который потащит. А теперь — сюрприз — надо пройти его собеседование.
А точнее, его собеседование надо проходить с первой встречи. Потому что кандидат уже после первого момента делает свои выводы. Которые формируются еще до этапа встречных вопросов. Потом их нереально сложно изменить. По крайней мере, в лучшую сторону.
Не слишком похоже на экзамен, не так ли? Экзаменаторов-то, в отличие от работодателей, обычно не выбирают.
После сеанса рефлексии я перестроил процесс. Точнее, ту его часть, на которую мог влиять.
Вот что я исправил
1. Снизил требования к резюме.
Потому что
За невзрачным резюме может стоять офигенный технарь. Может, конечно, и не стоять (и чаще всего не стоит), тогда потеряем время. Но немного, минут 15 на первичный звонок. Ведь время в это резюме уже было инвестировано: наш HR его нашел. И я как нанимающий менеджер это резюме прочитал. Почему бы не инвестировать еще немного? Ведь если кандидат окажется стоящим, мы с лихвой окупим инвестиции. И нанять его будет в разы проще, ведь большинство компаний его отфутболило на этапе чтения резюме. Особенно это важно, если ваша компания не из «первого дивизиона».
Результат: в четыре раза больше собеседований, которые позволили сделать в два раза больше офферов.
2. Сократил вопросы вида «расскажите о себе».
Ведь я уже читал резюме
Вы ведь, если собеседуете, тоже заранее читаете резюме? Правда? Тогда зачем этот пересказ? Плохая самопрезентация — это потеря драгоценного времени и испорченное первое впечатление. А хорошая говорит лишь об умении кандидата готовиться к выступлениям. Полезный навык, конечно, но мы ведь технаря ищем. Все равно далее будет техническая часть, на которой «мы поглядим, какой это Сухов». И как он умеет излагать свои мысли. А вопросы «расскажите о себе», «какие ваши сильные стороны», «ваши слабые стороны» в нашей культуре встречают отторжение со стороны кандидата. И дают слишком мало информации интервьюеру.
Поэтому данный этап сократил до минимума. Чтобы растопить лед, задаю один базовый вопрос: «Расскажите про ваш самый интересный проект». И слежу, чтобы ответ занял не более 3-5 минут. Самое сложное — удержаться от уточняющих вопросов.
Второй и самый важный вопрос: «Расскажите о процессе разработки на последней работе. Вот у заказчика появляется идея, что с ней происходит дальше?».
Вопрос позволяет понять, насколько кандидат в курсе процессов и сложно ли ему будет перейти на наши. А также помогает оценить «зрелость» разработчика. Показывает его видение разделения ответственности. Его представление о командной игре. Впишется ли он в команду, или мы получим классическую картину: «к пуговицам претензии есть».
Помните, я писал, что для меня важно, «потащит ли»? Так вот, на этом вопросе проясняется, потащит ли «по софтам».
Главное, надо следить за временем и не допускать ситуации «И тут Остапа понесло». Лично мне очень тяжело прерывать монологи кандидатов, но я работаю над этим. На этот вопрос выделяем минут 7-10.
Результат: Не распыляемся, и за 10-15 минут получаем представление, насколько кандидат подходит по soft skills.
3. Самая главная часть: техническая. Тут я могу говорить только про опыт найма разработчиков. А разработчики, по большей части, читают код. Конечно, бывает, и пишут. Хорошие еще и удаляют. Но читают все же больше.
Поэтому, на мой непросвещенный взгляд, самым лучшим заданием для оценки опыта стала задача проведения код-ревью. Я показываю экран синтезированного концентрата кода из копролитов и целлюлозы.
А потом и ставлю задачу:
прочитать код
сказать, что он делает
что в нем плохого и почему это плохо
как улучшить.
Ну а затем, в зависимости от ответа кандидата, задаю уточняющие вопросы.
Стивен Хокинг писал, что каждая включённая в книгу формула вдвое уменьшит число покупателей. Полагаю, это правило верно не только для формул, но и для строк кода. Поэтому буду предельно краток:
public void InviteCustomer(string name, int ordersCount, string age,
bool doNotHaveOrders, bool sex, string surname)Язык — C#, но язык тут не важен. Даже об этой строчке можно долго говорить. Начать с обсуждения большого количества идущих вразнобой параметров странных типов (строковый возраст, например). И закончить предложением инкапсулировать нужные данные в некий класс Customer (попутно спросив, а почему же тут нет идентификатора).
Скорость, с которой кандидат читает код, скорость, с которой он находит косяки, количество найденных косяков, предложения, как их исправить, — всё это скажет о реальных навыках. Имитировать их крайне трудно, если вообще возможно.
Вот, скажем, тема юнит-тестирования. Все как один говорят, что тест нужно писать. Подкованные кандидаты расскажут про TDD, заметив походя, что ну, по канонам TDD никто не пишет, все-таки, обычно сначала код, потом тесты. Легко купиться на теоретические знания.
А вот если показать маленький фрагмент, и спросить: «А как бы вы тестировали?», все станет на свои места.
if (DateTime.Now.Hour > 19)
{
Console.WriteLine("Good evening");
}Забудем про магическую константу и про консоль. Фокусируемся на тестах.
Джун либо растеряется, либо скажет про тестирование в отладчике.
Миддл, вероятно, предложит передавать текущий час как параметр в текущий метод. А затем написать юнит-тесты, в которых вызывать текущий метод с разными значениями часа.
Синьор может порекомендовать подставить через DI некий интерфейс, реализующий провайдер даты-времени, и использовать в коде время из этого провайдера. А для юнит-тестов предложит его «замокать».
Прелесть метода в том, что есть много «правильных» ответов, которые зависят от квалификации. И кандидат, выдав ответ, не будет считать, что ошибся. Но глубина его знаний и опыта неизбежно скажется на глубине ответов.
И подобных фрагментов в задании наберется больше десятка. Есть строчка, которая ну совсем не безопасна при вызове из разных потоков. Есть код, который будет ну очень сильно тормозить. И от синьора ожидается, что он в курсе про сложность алгоритмов, может ее определить по коду и даст рекомендации по оптимизации. Есть строчки, выделяющие лишнюю память на ровном месте. А весь код в целом нарушает SRP.
Фу так писать.
Я не жду, что кандидат найдет все косяки в коде. Это не нужно. Но я жду, что по найденным проблемам будет предложено решение, соответствующее требуемому на данную вакансию опыту.
Если позиция подразумевает глубокие знания в какой-то отдельной области например, знание асинхронности, дополнительно даю мелкий фрагмент асинхронного кода. Вопросы те же.
Результат: У соискателя стресс — меньше. Настроение — лучше. Нет негатива, если на что-то не ответил. У интервьюера же появляется хорошее представление о том, как кандидат будет работать.
Данный этап для спеца миддл+ занимает у меня около 30 минут. Если собеседую синьора - то до 45. Больше нельзя, даже если очень хочется: кандидат устает и «плывет».
Да, при данном формате собеседования всегда что-то не будет проработано. Ну и ладно. Никто не обнимет необъятного.
Вообще я руководствуюсь принципом: если что-то не приближает меня к пониманию, подойдет ли кандидат, это что-то — не важно.
И вот, что попало в этот список неважного:
Наличие сертификатов / конференций. Я видел как супер-спецов с сертификатами, так и пустышек, которые пытались сертификатами компенсировать неумение работать.
Github/pet project. У трети моих знакомых из крутых разрабов есть, что показать. У остальных — нет, но это не делает их менее крутыми.
Работа в компаниях из «первого дивизиона». На мой взгляд, сам факт красивой строчки в резюме ничего не значит.
Умение решать разного рода логические задачки. Ибо оно никак не коррелирует со способностью нанести пользу компании.
Хобби, фото, и подобные не относящиеся к профессии детали.
В финале спрашиваю, что кандидат ожидает от новой работы. Это важно, потому что позволяет понять мотивацию. В принципе, хочет ли кандидат работать? А если хочет - то захочет ли он работать именно с нами? Увы, желающих получать деньги обычно больше, чем желающих работать.
Ну а дальше — «продаем» себя, свой отдел, свой проект, свою компанию. Коротко, задорно, с блеском в глазах. Продаем минут пять.
И даем возможность кандидату задать свои вопросы. Это еще обычно 5-10 минут.
Итого, собеседование с мидлом занимает час, с синьором — час с четвертью.
Кандидат должен уходить с собеседования в хорошем настроении, а не выжатым, как лимон. Узнав что-то новое и полезное для себя. И с позитивными мыслями о компании.
Даже если он не подошел.
Или нет: особенно, если он не подошел.
Мой отчет будет на почте у моего начальника и HR не позднее, чем через 4 часа после собеседования.
И я очень, очень прошу HR, чтобы они отписались бы кандидату в любом случае. И не позднее следующего дня.
