Дисклеймер: это сценарий идеального технического собеседования в Delivery Club Tech. Мнение нашей команды может не совпадать с мнением читателей.
Привет, Хабр! Меня зовут Василий Козлов, я iOS-техлид в Delivery Club. Я часто и много провожу собеседования. В этой статье я собрал накопленный опыт и собственные наблюдения, которыми хочу поделиться. Во второй части статьи приведу пример собеса с комментариями со своей стороны. Итак, начнём.
1. Собесы бывают разные: жёлтые, зелёные, красные (лирическое отступление)
Есть мнение, что сложные технические собесы не работают. Сооснователь платформы для рекрутинга Interviewing.io Алин Лернер ранее писала, что компании, которые подбирают сотрудников, опираясь на сложные технические собеседования, «тратят ресурсы на множество кандидатов, которые не понимают игровую сущность собеседований». В результате на финишную прямую в таких компаниях выходят кандидаты, которые хороши именно в прохождении интервью.
Добавьте сюда стресс от собеседований, разнообразие и непредсказуемость вопросов на технических собеседованиях в разных компаниях. И вспомните свои неожиданные неудачи на этих встречах. Статистика это лишь подтверждает: только около 25% кандидатов способны раскрыть и продемонстрировать свой потенциал, и даже первоклассные специалисты в 22% случаев заваливают технические собеседования.
Эта особенность — задавать на технических интервью сложные, не имеющие никакой связи с реальностью, головоломкие вопросы — появилась в 1950-х годах в Соединенных Штатах в период холодной войны. Тренд задала лаборатория полупроводников Шокли из долины, тогда ещё не носившей имя Кремниевой, вынужденная привлекать на службу безумных гениев для противостояния «красной угрозе». Невозможность писать код на техническом собеседовании по телефону заставляла интервьюеров искать альтернативные варианты для быстрой оценки аналитических способностей, интеллекта и потенциала собеседника. Так появились задачи про фальшивую монету и два взвешивания.
В 1990-х годах с бумом доткомов последовал рост найма технических специалистов, и Microsoft взяла на вооружение подход прошлых лет. Их примеру некоторое время следовала Google.
Впоследствии Google и Microsoft отказались от популярных головоломок из серии «как передвинуть гору Фудзи». «Что касается найма, то мы обнаружили, что головоломки — это пустая трата времени. Сколько мячей для гольфа вы можете поместить в самолет? Сколько заправочных станций на Манхэттене? Полная трата времени. Они ничего не предсказывают. Они служат, в первую очередь, для того, чтобы интервьюер чувствовал себя умным», — признал старший вице-президент по работе с персоналом в Google в интервью New York Times.
Итак, есть мнение, что сложные технические собесы не работают, и я его разделяю, поэтому все технические собеседования в Delivery Club я проводил, не задавая подобных вопросов. Невозможно без соответствующей подготовки к собеседованию взять и пройти таковое. На практические тренировки может уйти 1-2 месяца хождения. Это нормальный процесс, с которым так или иначе согласны все опрошенные мной коллеги.
Появление компьютеров позволяет решать проблемы, которые не проявлялись до их существования. Так и подготовка к собеседованиям позволяет решать проблемы, зачастую возникающие только на собеседованиях. Очень часто это именно так.
IT-индустрия в России с точки зрения IT-найма никак не стандартизована. Способы оценки знаний принимают, зачастую, очень изощренные формы. Один из самых бестолковых примеров на моей памяти — телефонное интервью с HR-специалистом, который записывал ответы кандидата на технические вопросы, чтобы далее передать их техническому специалисту. В этом случае какой-либо диалог полностью исключается, и невозможно поделиться ни мнением, ни оспорить вариант ответа. Всякий диалог также исключен, когда перед соискателем предстает online-тест с выбором из заготовленных ответов, также порой являющийся порождением ума другого технического специалиста с его собственным, уникальным опытом и знанием английского языка. На мой взгляд, английский в разработке важен настолько, что порой проще на собесе объясняться на нём.
Другой пример собеседования, с одной стороны вполне объяснимый, — это желание работодателей получить психологический портрет соискателя, предупреждая «собеседование по существу» встречей с психологом. Самый ушлый работодатель на моей практике всё же провел техническое собеседование, а потом предложил пройти испытание на детекторе лжи, аргументируя такую последовательность тем, что услуга эта платная, а кандидатов много.
Следует признать, что это редкие случаи, и вся совокупность проверки технических знаний сводится, в итоге, к тестовому заданию или очной встрече. Как эти простые инструменты сделать эффективными в поиске подходящего технического спеца? Для начала, как и в любой технической задаче, следует определиться с требованиями к кандидату… и к собесу.
2. Идеальный формат, идеальный кандидат (формируем требования)
«После каждого интервью у вас должно сложиться чёткое ощущение, может ли этот человек повысить вероятность успеха вашей компании», — говорит Нил Роузман в статье «Анатомия идеального технического интервью от бывшего вице-президента Amazon». Пусть эти слова для кого-то прозвучат высокопарно, особенно от вице-президента, пусть и бывшего, но это правда. В конечном счёте именно вам или вашему коллеге предстоит работать с этим кандидатом, если он успешно пройдет собес.
Техническую проблему можно решить, освежив матчасть, а выработать обоюдное для каждой заинтересованной стороны решение — задача, требующая от кандидата понимания общей цели, когнитивных и коммуникативных навыков. Про такое в книжках не напишут, вернее — напишут, но без собственного опыта это не работает. Поэтому soft skills, или личные качества, становятся неотъемлемой частью технического собеседования наряду с профессиональными знаниями кандидата (hard skills).
Командная работа отлично показала себя в кризисное время, когда новые вызовы и неопределенность готовят много вопросов. В такой среде умение вести диалог, выдвигать гипотезы и спрашивать становится основополагающим для эффективного сотрудника. Идея совместить в одном интервью знакомство с софтами и хардами кандидата, устроить миниатюрный рабочий день, казалась очень привлекательной, но как будто бы недостижимой. Не все и далеко не всегда располагают таким количеством времени, имеют юридические возможности, чтобы пригласить кандидата окунуться в кипящие воды разработки своего продукта.
На помощь пришел давнишний подход, впервые применённый в Гарвардской бизнес-школе в 1924 году — ситуационное интервью, или кейс-интервью. Условно его можно разделить на три большие части:
- ценности и взгляды кандидата, soft skills;
- профессиональные навыки и умения, hard skills;
- модели поведения и индивидуально-личностные качества.
Вопрос о том, как совместить ситуационное интервью с известными подходами к оценке технических знаний, оставался открытым. Важно предложить кандидату структурированный, прозрачный план собеса и уместить его в тесное расписание современного разработчика.
Согласно статистическим данным Zety, консультационного сервиса по созданию резюме, в 2017 году наиболее распространенным подходом оставался итеративный, состоящий в проведении нескольких этапов интервью. Самый популярный вариант содержал три интервью.
Получасовой созвон по скайпу — так называемый скрининг — позволяет получить общее представление о кандидате, принять решение о желании общаться дальше, как на первом свидании. Чем, как не эффективной демонстрацией софт скиллов, обусловлена договоренность о следующей встрече? Очень важно, чтобы это был именно видеозвонок, а не гадание по фотографии. Вопросы, которые будут заданы на скрининге, также должны быть направлены на формирование картины ценностей кандидата: представление о ролях в команде, эффективности взаимодействия, о своей роли, эффективности и компетенции. Нелишним будет лично задать вопрос о мотивах смены работы и найти пересечения, пробежавшись по персональному техрадару кандидата, вроде любимых сериалов.
Конечно, эпидемиологическая ситуация в мире внесла свои коррективы, и Zoom вытеснил Skype, но скрининг был и остаётся нашим бессменным первым этапом.
Забегу вперед, оставив самое вкусное на потом, и упомяну третий этап — финал, до которого суждено добраться не всем. Это как знакомство с родителями, если продолжать аналогию со свиданием. Это тоже своеобразный скрининг, но с руководителем подразделения или техническим директором. На этом этапе важно донести до кандидата ценности компании, стратегию развития проекта. Проверив его ещё раз, задавая встречные вопросы о планах и ценностях, если у вас есть сомнения по поводу кандидата.
Оставим детализацию этого процесса на откуп самим руководителям, перейдём к техническому интервью — главному этапу в собеседовании разработчика.
«Отличное интервью — это работа. Требуется время, чтобы подготовиться, провести собеседование, а затем эффективно подвести итог. Если вы не хотите делать эту работу, не берите интервью», — продолжая цитировать Нила Роузмана, стоит согласиться с тем, что это действительно работа, и, вне зависимости от того, какой формат вы выберите, с кандидатом придется вести диалог. Помимо тех, кто фактически обучался найму, — эйчаров, — техническому интервьюеру также следует прокачать навыки хайринга.
3. О бедном эйчаре замолвите слово (про важность хорошего HR-специалиста)
В статье я рассуждаю с выигрышной позиции: крупная компания, известный бренд — многие специалисты даже без уточнения технических деталей согласятся здесь работать. Но в любой компании нельзя недооценивать работу HR-специалиста. Он является своеобразным фильтром на входе в компанию. «Сотрудники, которых вы нанимаете, будут так же хороши, как и команда по найму, которую вы собираете», — подтверждает Роузман.
Главным активом любой компании являются люди. Хороший рекрутер даже при отсутствии бренда, в никому не известном стартапе может обеспечить специалистов с приемлемым уровнем знаний, и сделать даже нечто большее: найти единомышленников — тех, кто будет радеть за продукт.
«Крупная компания, известный бренд могут также осложнять работу HR-специалиста, будучи у всех на слуху. Хорошее знание проекта, процессов разработки и команды позволяют рекрутеру уже на первом этапе принять решение о том, подходит ли кандидат для вакансии. В результате до 60% кандидатов доходят до технического интервью», — говорит руководитель направления подбора персонала Mail.ru Group. Однако объёмы таковы, что 60% — это не 6 человек.
Потенциально каждый специалист может знать ещё одного специалиста, а это плюс один источник кандидатов для хорошего рекрутера. Наличие реферальной программы упрощает первый контакт, делая его более дружелюбным и лёгким благодаря знакомству кандидата и рекомендателя, но дальше всё по-прежнему зависит от профессиональных навыков кандидата.
Хороший рекрутер должен всегда иметь в рукаве нескольких тузов, если вдруг на рынке не найдётся подходящего кандидата в активном поиске работы. Для этого рекрутеры регулярно занимаются поиском «холодных» кандидатов. «Как правило, мы предлагаем людям просто нейтрально познакомиться с нами, без интервью. Далеко не все соглашаются после этого пройти техническое собеседование, и это нормально. Мы строим долгосрочные отношения в надежде на то, что если не сейчас, то через год или два нам всё-таки удастся поработать вместе».
Найм — это комплексный процесс, существенную помощь в котором рекрутеру может оказать сама команда, где кандидату предстоит работать, поэтому необходимо развивать бренд работодателя. Нужен антураж! Крутая статья на Хабре, участие в профильных конференциях повышают шансы на найм профессионалов. Продуманная система найма — откуда к нам приходят люди, как и по каким критериям мы их оцениваем, как принимаем финальное решение — также поможет рекрутеру сориентироваться на рынке, чтобы максимально точно определить потребности компании.
«Главное правило — оставайтесь людьми, и помните про партнерские отношения с каждым кандидатом».
4. Как играть на поле кандидата, не забывая про себя (требования к интервьюерам)
К нам приходят очень разные технические специалисты из разных компаний. В продуктовых компаниях бо́льшее внимание уделяется пользовательским интерфейсам, простым и быстрым реализациям, а в софтверных гигантах сложные технические решения, нативный код, глубокое погружение в недра операционных систем превалируют над внешней составляющей и реакцией на изменяющиеся условия. Так и кандидаты, в зависимости от того, в какой компании они работали, могут специализироваться на определенных технологиях, пусть даже каждый из них претендует на одну условную вакансию iOS-разработчика. Означает ли это, что специалист, погруженный, например, в реализацию родительского контроля на iPhone, никогда не сможет перебежать на сторону продуктовых витрин, заказов и отображения локаций на карте? Как оценить претендента, если в рассказе о прошлом опыте он упоминает подходы, никак не отзывающиеся в вашей памяти?
Многообразие технологий, архитектурных приёмов и фреймворков усложняет поиск кандидатов, но говорить на общем с кандидатами языке можно и нужно. Специалист с головой на плечах сможет адаптироваться к новым для него практикам и даже привнести оригинальные решения в устоявшиеся подходы. Снятие ограничения при поиске кандидатов, скажем, на архитектурные паттерны или языки программирования — в рамках одной технологической платформы, конечно, — потребует от интервьюера знаний в соответствующих предметных областях. Где взять такие знания? Опыт проведения собеседований подскажет интервьюеру, в каком направлении стоит подтянуть знания, какие технологии и подходы распространены на рынке сейчас и в чем их отличие от принятых в компании. Необязательно становиться экспертом насильно. Достаточно представлять в общих чертах предметную область и вести с кандидатом диалог, позволив ему самому объяснить тонкости реализации. Такой подход позволит вам избежать чрезмерных затрат на подготовку к конкретному собесу, а кандидату — продемонстрировать свои гибкие навыки, выраженные в способности объяснять свою точку зрения другому специалисту.
Это отнюдь не означает, что к собеседованию не нужно готовиться. Здесь важно соблюдать баланс. Предложите кандидату самому выбрать и объяснить задачу и её решение при помощи его любимой технологии. Попросите решить типовую задачу из вашей предметной области, но при помощи его инструментов. Так или иначе вы сможете совместно поработать над проблемой, знакомясь и с точкой зрения кандидата, и с привычной ему технологией. Типовые задачи, которые подходят для такого кейс-интервью, как правило, хорошо иллюстрируются проектированием архитектуры сервиса, модуля или экрана. Кандидат абстрагируется от конкретной реализации, а вам не нужно погружаться в техническую специфику. Поэтому открывайте draw.io или любой другой сайт для проектирования блок-схем и диаграмм, и вперёд! Этот формат отлично подходит для Zoom.
Отдельно стоит сказать, что кандидаты, которые способны объяснить какое-либо решение, как правило, зрелые специалисты, что уже является определенным признаком в оценке их способностей. Такой подход, скорее всего, не сработает с джунами и может обернуться неловкой ситуацией для обеих сторон. Поэтому интервьюеру всегда надо иметь возможность предложить задачи различной сложности, либо — что более универсально и элегантно — начинать с простого сценария, постепенно усложняя его новыми вводными.
«Используйте вопросы, являющиеся расплывчатыми и открытыми к обсуждению. Посмотрите, будут ли кандидаты задавать встречные вопросы, чтобы узнать больше», — советует Роузман, предлагая тем самым настроить диалог с кандидатом и иметь место для манёвра, если что-то пойдёт не так.
Задавать технические вопросы, как и проводить техническое собеседование, интервьюер должен структурировано. Нил Роузман предостерегает: «Если вы провели собеседование и всё, что можете сказать — это: “Ну да, он вроде ничего, мне понравился”, тогда вы потратили время зря». Структурированный подход должен стать рутиной в подготовке и проведении собесов.
5. Сценарий идеального технического собеседования
Конечно, здесь я не представлю универсальный, идеальный план проведения технического собеса. Это уникальный для каждой компании и каждого интервьюера процесс. Но я хочу предложить несколько идей, опробованных в реальной практике найма в Delivery Club, применение которых известным образом усилило нашу команду.
Помните про гуманитарную составляющую. Помогите собеседнику расслабиться, учитывайте стрессовую ситуацию, в которой обычно пребывает кандидат. Самым подходящим примером здесь может послужить один из тех разговоров, что случаются на кухне компании среди айтишников после какого-нибудь недавнего технологического анонса или презентации. Можно упомянуть последние новинки технического мира или какую-то общеизвестную боль разработчиков.
Составьте план технического собеседования. Наличие у интервьюера плана с заранее предусмотренными вопросами разной сложности, а также оценками уровня знаний по каждой теме позволит грамотно подвести итог после собеседования. Развернутый результат всегда проще сопоставлять с другими результатами и аргументировано объяснять своё решение по кандидату.
Дальнейшее применение таких оценок, в случае принятия положительного решения по кандидату, может выразится в развитии матрицы компетенций сотрудника. Таким образом, качественное техническое собеседование станет залогом для дальнейшего развития специалиста в составе вашей команды.
Сделайте техническое интервью диалогом двух специалистов. Начните ваш диалог, кратко перечислив темы, которые собираетесь затронуть.
Старайтесь использовать на интервью задачи, максимально близкие к рабочим. Если задаете академический вопрос, а кандидат начинает плавать, попробуйте обрисовать практическую задачу, которая включает в себя ответ на этот вопрос. Вариант для опытных интервьюеров — прислать свои вопросы кандидату заранее, и на собеседовании, основываясь на том, что вы с кандидатом обладаете одинаковыми знаниями, пообщаться и обсудить более практические и сложные кейсы.
Предложите кандидату выполнить code review, вместо того, чтоб заставлять его писать новый код. Практика code review отлично подходит для технической части ситуационного интервью. Подготовьте заранее неоптимальный код или код, в котором допущена ошибка. А если в листинге не содержится секретной информации, то лучше показать тот pull request, для которого коллегами было оставлено больше всего замечаний. Тем самым вы переосмыслите подход к «коду на листочке»: многие кандидаты испытывают трудности при написании кода вне предпочитаемой среды разработки или при стороннем наблюдателе. А code review на собесе позволит вам убедиться в навыках чтения и понимания кода, оценить способность командного взаимодействия по тону и содержанию комментариев кандидата.
Завершите техническое собеседование презентацией проекта, с которым предстоит работать кандидату. Важно не только выслушать кандидата, но и ответить на его вопросы. Не всегда возможно отвечать максимально подробно, но необходимо, чтобы кандидат понимал, с чем ему предстоит работать, хотя бы в общих чертах.
В моей практике с этой задачей отлично справилась презентация о развитии проекта, которую изначально готовили для технической конференции, но она смогла отразить и legacy проекта, и инновационные подходы. Благодаря такой своеобразной визитной карточке ваш проект и команда значительно вырастут в глазах кандидата.
Проведите собеседование от начала и до конца. «Даже если вы понимаете через 15 минут после начала собеседования, что кандидат не подойдет, важно пройти все эти этапы», — говорит Нил Роузман, — «Вы должны постараться провести почти полное интервью, потому что мир очень тесен, и пусть лучше человек думает, что у него только что было отличное интервью, даже если он не получил предложение о работе».
Поиск подходящего сотрудника — это большой труд, и его можно облегчить, если обе стороны будут получать удовлетворение и удовольствие от этого процесса. Вы будете расти и развиваться с каждым новым собесом, с каждым новым кандидатом, и в итоге обязательно найдёте идеального.
Сценарий идеального технического интервью. Драма в пяти действиях
Далее я в игровой манере опишу план одного воображаемого технического собеседования, основанного на разных реальных интервью. После каждой части дам небольшие комментарии о том, какие выводы может сделать интревьюер и как продолжать собеседование.
Действующие лица:
- Олег — молодой, перспективный iOS-разработчик
- Василий — умудрённый опытом тех лид команды iOS
Действие первое
Никто из действующих лиц не знает, как пойдёт собеседование дальше. Олег может начать плутать в коде, скакать по наименованиям методов, тщетно предполагая, где они могут вызываться, а может ввести в поиск “1.5” и точно определить место, где задаётся пауза, так и не сумев объяснить механику работы. Тогда Василий постарается скорее завершить эту часть собеседования, поблагодарив и указав собеседнику на возможность постановки таких задач перед сотрудником только при наличии соответствующих знаний в области Objective-C.
С другой стороны, Олег может логически дойти до требуемого метода, где организована очередь, объяснить выбор параметров очереди и механизм её работы, рассказав попутно про другие виды очередей и способы реализации подобной задачи.
В обоих случаях Василий должен следить за временем, не позволяя процессу размышления и обсуждению затянуться, а также постараться оценить ответ Олега по заранее подготовленной шкале оценок по Objective-C, а возможно, ещё и многопоточности.
Действие второе
От ответа Олега зависит, как интервью будет развиваться дальше. Но даже если он не сумеет ответить на этот вопрос, беседа не прекратится, просто Василий вернётся к базовым вопросам, предварительно ответив на заданный Олегу вопрос.
Если Олега осенит после предложенной подсказки, это будет означать, что можно переходить к более сложным вопросам.
Действие третье
Василий уже понимает, что Олег может решать задачи формирования пользовательского интерфейса в соответствии с требованиями дизайна. Также создаётся впечатление, что Олег больше склонен действовать, а не объяснять, и, возможно, это проливает свет на то, что в некоторых вопросах он плавает, хотя точно знает, как всё работает.
Действие четвертое
У Василия начинает складываться вполне конкретное представление об Олеге, как о возможном будущем сотруднике. Олег разбирается в предметной области, следует требованиям, но не готов давать обратную связь и мыслить более абстрактно, чем, возможно, того требует задача.
Для понимания последнего кейса Василий предлагает Олегу архитектурную задачу.
Действие пятое
Процесс проектирования архитектуры какой-либо системы всегда творческий. Он сопровождается диалогом, постоянными правками. Он уникален и ценен сам по себе, потому что однозначно даёт понять, разбирается ли автор в том, что объясняет, а заодно умеет ли объяснять.
Но и результат этого процесса может кое-что рассказать о кандидате. Если бы Олег спроектировал архитектуру, как показано на одной из иллюстраций, у Василия сложились бы совершенно разные представления о навыках кандидата.
Что в результате нарисовал Олег, мы опустим, и предоставим читателю на основании иллюстраций самому пофантазировать о том, понимает ли Олег выбранную архитектуру.
На этом всё. Спасибо, что дочитали!