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

Как появилась идея этой статьи

Я являюсь гейткипером по Java в компании Globant. Регулярно собеседую людей в компанию, общаюсь с коллегами на тему собеседований. Собственно из общения начал выделять суть и копать вглубь проблемы. Поэтому и хочу поделиться своими выкладками на эту тему.

Введение

Каждый собеседующий со временем сталкивается с большим количеством вопросов:

• Какие вопросы задавать?

• Что считать хорошим ответом на вопрос?

• Насколько вопросы должны соответствовать проекту?

• Что должно проверять собеседование?

• Как придумывать хорошие вопросы?

• Надо ли следовать матрице компетенций?

и это только основные вопросы, которые стабильно возникают у каждого.

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

Определяем цели собеседования

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

Хороший ли подход?

• +: уровень всех разработчиков выстраивается в одну линейку и четко ранжируется

• +: ответы хорошо известны и легко сравнивать правильность - да здравствуют контрольные в школах

• +: матрица компетенций близка к этому подходу

• -: много стандартных вопросов, ответы на которые уже все знают

• -: кандидат может не подходить на должность, т.к. вопросы никак не соотносятся с работой

• -: cофт скилы на стандартных ответах не проверяются

Его довод: "я в первую очередь стараюсь проверять понимание в разных аспектах программирования, а детали на работе узнают". Как итог, на собеседовании спрашивают про graphQL а проект работает на RPC. Дальше разочарование, страдание, увядание и увольнение, но иногда все заканчивается хорошо.

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

Легко заметить, что у подхода хватает как плюсов, так и минусов. Сейчас я выделю цели интервью которые помогут взглянуть на процесс под другим углом.

Цели

Входное интервью

Когда применяется

Данный тип применяется для входа в большую компанию, зачастую аутсорсера. Если кандидат покажет выдающиеся результаты, то даже смело можно принимать на bench.

Задачи:

• оценка уровня кандидата в соответсвии с линейкой, принятой в компании

• проверка общих soft-скилов

• составление примерных областей, в которых силен кандидат

• валидация опыта

Фит интервью

Когда применяется

Данный тип применяется для входа на конкретное место или роль.

Задачи:

• Оценка того, справится ли кандидат с задачами на проекте

• Сможет ли он работать в команде

Анализируя цели, смотря и сравнивая подходы других коллег, я пришел к своей схеме, которая, как мне кажется, соответствует целям и задачам разных типов.

Немного моего подхода

Мой план на Входное интервью:

• Валидация опыта - не более 30 минут - человеку проще всего говорить о своем опыте. Легко оценить задачи какого уровня человек решает, и как он исследует проблемы

• Проверка умения писать код - 15-20 минут - легкая задача цикл, условия и их смесь. На удивление не всегда сеньоры пишут что-то адекватное.

• Немного разговора на английском - 5 минут - никогда не спрашиваю стандартные темы. всегда что-то, связанное с работой. (опишите идеальный pipe деплоя)

• Блиц опрос на разные темы - 15 минут - предупреждаю кандидата, что мне не нужны подробные объяснения, а нужны просто ключевые слова. Обычно успеваем вопросов 30 проговорить.

План на Фит

• Парное программирование - 30-60 минут. Кто-то из команды совместно с кандидатом решает задачу

• Обсуждение актуальной проблемы на проекте в соответствии с уровнем кандидата - до 30 минут. Проблемы могут быть разными: от выбора очереди или кэша до методов деплоя

Заключение

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

Мораль

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