Техническое интервью

Дисклеймер: это сценарий идеального технического собеседования в 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, а возможно, ещё и многопоточности.

Действие второе

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

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

Действие третье

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

Действие четвертое

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

Для понимания последнего кейса Василий предлагает Олегу архитектурную задачу.

Действие пятое

Процесс проектирования архитектуры какой-либо системы всегда творческий. Он сопровождается диалогом, постоянными правками. Он уникален и ценен сам по себе, потому что однозначно даёт понять, разбирается ли автор в том, что объясняет, а заодно умеет ли объяснять.

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



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



На этом всё. Спасибо, что дочитали!

Когда я сам был кандидатом и ходил по собеседованиям, больше всего меня бесило ожидание обратной связи: долго, скучно, нельзя обсудить решение. Оказавшись на месте интервьюера, я заметил, что чаще всего все нужные выводы делаются буквально за 5 минут после встречи. Остальное время бесполезное растягивание процесса и бюрократия. Главная причина не отвечать сразу понятна эмоционально сложно обсуждать решение с кандидатом, ведь часто нужно отказывать. В итоге программисты увиливают и передают эту задачу HR.

Я решил выкинуть всё ожидание и рассказывать о результатах собеседования настолько рано, насколько это возможно в конце встречи. Эксперимент удался, делюсь.

Серия статей про собеседования:
1. Я прочитал 80 резюме, у меня есть вопросы.
2. Наш первый обед вместе: почему и как мы проводим тестовый день.
3. Собеседование в Додо Пиццу.
4. Уходя уходи: почему не стоит принимать контроффер.

Я разрабатываю приложения для айфонов, но ещё провожу технический этап собеседования для iOS-разработчиков.

Раньше я проводил собеседование по стандартной схеме:

• слушал рассказ кандидата о себе;
• задавал вопросы;
• рассказывал о следующем этапе собеседования;
• договаривался о времени ответа и мы прощались.

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

Почему я решил давать фидбек сразу

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

Сейчас я провожу собеседование так:

1. Рассказываю о структуре собеседования. Буквально то, что вы сейчас читаете.
2. Рассказываю кратко про наш проект, его интересные стороны и будущие вызовы, про команду. Отвечаю на вопросы, которые могут появиться.
3. Кандидат рассказывает про свой опыт, а я попутно записываю вопросы. Спрашиваю всё в конце, чтобы не перебивать.
4. Если какую-то тему не обсудили, то спрашиваю точечно. Чтобы ничего не забыть, беру с собой на встречу чеклист из тем и вопросов.
5. Часто к концу встречи у кандидата снова появляются вопросы. Отвечаю на них.
6. В конце даю фидбек: принимаю решение на своём этапе технического собеседования и рассказываю о нём.
7. Раньше я думал, что на шестом этапе собеседование заканчивается, но у меня раз за разом происходила магия: после фидбека (неважно, положительного или отрицательного) кандидаты преображались, рассказывали необычные детали о себе и своём опыте, раскрывались с новой стороны.

Стоит отметить, что собеседование со мной не последний этап найма, потом может быть тестовый день и встреча с РО/CTO. Но результаты технического этапа вполне можно обсудить сразу вместе с кандидатом.

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

Инструменты и последствия моментального фидбека

До фидбека

За время собеседования надо не просто перетереть за жизнь и технологии, а узнать всё что нужно о кандидате, принять решение и объяснить его себе и кандидату. Времени мало, поэтому важно задавать правильные вопросы.

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

На собеседовании мне важно выяснить, если ли у кандидата все необходимые технические навыки. Значит, все вопросы должны эти навыки раскрывать.

Чеклист вопросов и тем, чтобы ничего не забыть. Не пропустить какую-то тему мне помогает чеклист. Обычно процентов 60% из него кандидат рассказывает сам. Задавая дополнительные вопросы, стараюсь отталкиваться от рассказа самого человека, чтобы быть в мире собеседника, он там лучше разбирается. Получается нормальное общение.

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

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

Записи могут пригодиться и в будущем: по ним можно достаточно полно вспомнить кандидата, если он вернётся к вам на повторное собеседование через полгода-год. По записям вам будет просто отследить, что изменилось за это время.

Во время фидбека

Для ответа нужно время подумать пару минут. Сходу (экспромтом) выдать идеальный ответ не получится. Попросите у кандидата паузу в пару минут, пройдитесь по записям, посмотрите, как они сходятся в стройный ответ. Если чего-то не хватило, то можно доспросить.

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

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

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

Если вы ведёте собеседование в паре. Решение должен принимать только один из вас (заранее договоритесь, кто это будет), второй человек только уточняет свои вопросы во время интервью, помогая первому раскрыть собеседника.

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

После фидбека

Кандидаты удивляются моментальному ответу. У всего рынка есть привычка брать паузу в несколько дней, прежде чем дать ответ. Люди ожидают этого и от вас. Моментальный ответ даёт вам небольшой кредит доверия в глазах соискателя. Иногда разница с ожиданиями настолько сильна, что это пробивает кандидата на другой уровень общения, ломается официальность и атмосфера экзамена. Например, не все могут в обычном интервью сказать: Я никогда не писал тесты, но очень хочу прокачаться, научите. А после моментального фидбека могут. Из этого может получиться тема для тестового дня или задания.

Вы можете ошибиться. Это нормально: он не так сказал, вы не так поняли, причин услышать не то очень много. Именно поэтому стоит всё записывать и говорить выводы сразу, тогда вы сможете их обсудить, и вас поправят, если что-то было понято неверно. Иначе, через 15 минут вы всё забудете или напридумываете лишнего.

Чтобы сильно не накопить ошибку к концу собеседования, я при обсуждении говорю о том, что услышал из рассказа: Ты сказал вот так, значит вот это? Нет, ага, а как?. Суммарная ошибка уменьшается.

Вы можете ошибиться ОЧЕНЬ сильно. Со мной такое было один раз. Во время фидбека я рассказал, что в ряде технологий кандидат разбирается слабо, а для нас они очень критичны. Он возразил, что про это я даже не особо спрашивал. Я опешил, это казалось полным провалом.

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

Минусы не страшны, если рассказать, как их исправить. Все недостатки кандидата это непопадание в наши/ваши требования. Зачастую им можно просто научиться. Ссылки на статьи, посты и книги очень помогают. Если вы видите, как кандидат может прокачаться, поделитесь с ним этой информацией. В итоге ваше собеседование не окажется пустым и поможет кандидату в будущем.

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

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

Надо уметь объяснять причину отказа. Хорошо, если всё целостно: у нас есть боль, из неё мы составляем портрет кандидата для вакансии, о проблеме я рассказываю в начале интервью и с акцентом на это задаю вопросы. Получается, что в конце собеседования вопрос один: Подходит ли человек для решения нашей боли и проблемы?. Ответ на него и будет вашим фидбеком, надо только добавить, что удалось, а чего не хватило.

Обратный вывод: если вас не взяли в компанию Х, то просто вы не подошли ей. Такое бывает и с сильными разработчиками: специалист по 3D-графике может плохо работать с базами данных и UI-тестами, но отлично справляться с задачами в другом месте.

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

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

Итоги и выводы

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

Что дал мне такой подход? Для меня собеседования стали более структурированными, проводить их стало интереснее и даже проще. Ранний ответ повлиял на всю схему собеседования: я больше понял о наших задачах, мы начали писать про них в наших вакансиях, и я сразу спрашиваю про их возможные решении на первой встрече. Разрозненные этапы стали собираться в одну сильную цепь, где меньше потерь и больше прозрачности.

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

Если в вашей компании открытость и честность это часть культуры, то почему бы не начать прямо на интервью?

Свои мысли и идеи о мобильной разработке я пишу в телеграм-канале Dodo Pizza Mobile. А ещё у нас открыто две вакансии в мобильном направлении. Так что я просто оставлю это здесь: iOS-developer (Нижний Новгород), Android-developer (Нижний Новгород).