Анатомия эффективного собеседования. Что делать и чего не делать на собеседовании

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

К моему удивлению, многие компании до сих пор не имеют никаких руководств и образовательного процесса для своих интервьюеров. То есть, интервьюер часто даже не знает, каких людей компания ищет на эту конкретную должность! Как можно найти подходящих людей, если вы не знаете, кого ищете? Вам нужен умный, быстро обучаемый джуниор, который будет быстро расти вместе с компанией, или вам нужен опытный ветеран, который может быть полностью автономным? Или, возможно, вам нужен архитектор/ведущий разработчик, чтобы направлять вашу команду в определенной области? Это разные люди и разные подходы к собеседованию с ними.

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

Это обширная тема, поэтому я здесь поделюсь только парой своих наблюдений и руководящими принципами собеседования, которые я использую на всех моих собеседованиях (предполагая, что вы ЗНАЕТЕ, кого ищете!).

• Первое - собеседование не про ВАС. Никого не интересует, что ЗНАЕТЕ ВЫ. Не пытайтесь утверждаться за счет других. Собеседуемый может не знать некоторые темы, и это нормально.Позитивное отношение к кандидатуобязательно. Человек, с которым вы проводите собеседование, уже находится в состоянии большого стресса, не нужно ещё добавлять к этому. Еще лучше - положительные намерения. Я всегда стараюсь заранее сообщить людям, что одна из основных целей собеседования - предоставить им обратную связь, чтобы они могли улучшить свои навыки. Так что они на самом деле не могут провалиться - они получат предложение о работе или хорошую обратную связь, которую смогут использовать позже.Нынче довольно часто я вижу, когда интервьюер наполовину слушает и пытается одновременно выполнять свои другие задачи. Не раз я видел, как интервьюер всё собеседование пялиться в свой ноутбук. Я тоже признаю себя виновным в этом😔, и когда это происходит, результатом является неполноценное собеседование.
• Основные навыки, на которые я обращаю внимание, - это умение решать проблемы и способность быстро учиться. Если подумать - человек с этими навыками сможет быстро освоить остальное и потребует минимум обслуживания. К тому же, в отличие от технических навыков, это не так просто приобрести. Звучит очевидно? Но не для многих интервьюеров и менеджеров по найму. Я регулярно сталкиваюсь с многочисленными примерами, когда кандидата отклоняют на основании того, что он не знает какую-то конкретную технологию. Это довольно глупо. Типа, кандидат быстро учится и имеет глубокие знания в области фронтенд-разработки, но не имеет опыта работы с Typescript. Ну и что? Сколько времени потребуется этому человеку, чтобы его изучить? Три дня, может быть, или даже неделю? Но навыки решения проблем легко не приобретешь.
• Еще один важный навык, на который стоит обратить внимание, - это коммуникация. Я знаю, что некоторые программисты считают это не важным. К сожалению, даже в технической сфере стать старшим специалистом без навыков коммуникации довольно сложно. И работать с таким человеком боль. В конце концов, мы все работаем с людьми и создаем продукты для людей.

Как видите, это очень общие правила, но я бы хотел, чтобы мне кто-то рассказал мне их 10 лет назад.

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

• Обзор резюме
• Теоретические вопросы
• Поведенческие вопросы
• Вопросы по проектированию
• Задача на кодирование
• Вопросы кандидата (да, это тоже важно оценивать)

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

Чтобы составить представление о кандидате, я обычно спрашиваю о 1–3 недавних проектах. Люди склонны забывать детали по проектам старше трех лет, так что не стоит спрашивать про проекты которые были при царе горохе.

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

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

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

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

НИКАКИХ ЗАПУТАННЫХ И ХИТРЫХ ВОПРОСОВ!

Да, я вынужден написать это заглавными буквами, потому что вижу их слишком часто. Мы здесь не играем в викторину. Запутанные вопросы не являются показателем чего-либо, кроме идиотизма интервьюера (если он реально собирается по ним оценивать кандидатов а не спрашивает по приколу). Кому какое дело, почему люки круглые? Я слышал, это чтобы черепашки-ниндзя могли пролезть в них.

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

Некоторые примеры:

• Расскажите о самой сложной технической проблеме и как вы ее решили.
• Расскажите о конфликтах, с которыми вы сталкивались в прошлом, и как вы их решали.
• Топ-5 личных достижений.
• Сложное решение, которое вам пришлось принять в прошлом.
• Ваши сильные и слабые стороны (кстати, правильный ответ - у вас нет слабых сторон, только области для улучшения :)

Это открытые вопросы на которые нет одного правильного ответа. Цель - понять, понимает ли кандидат архитектуру и оценить его зрелость/экспертность. Это актуально для mid+ позиций и выше, понятно что джуниор тут мало что может сказать.

Примеры вопросов по проектированию:

• Спроектируйте бэкенд Twitter
• Спроектируйте фронтенд Whatsup
• Спроектируйте конкретный компонент

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

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

Я со-основатель AI интегратора Рафт.

Делюсь опытом в ТГ-канале.

Всем добра!