Вам еще не надоело читать о том, как правильно собеседовать?
Вы себя ощущаете богом собеседований и уверены что способны отобрать лучших специалистов за один разговор?
Вы мастерски придумываете вопросы на собесы?
Вы никогда не самоутверждаетесь за счет собеседуемых?
Как появилась идея этой статьи
Я являюсь гейткипером по Java в компании Globant. Регулярно собеседую людей в компанию, общаюсь с коллегами на тему собеседований. Собственно из общения начал выделять суть и копать вглубь проблемы. Поэтому и хочу поделиться своими выкладками на эту тему.
Введение
Каждый собеседующий со временем сталкивается с большим количеством вопросов:
Какие вопросы задавать?
Что считать хорошим ответом на вопрос?
Насколько вопросы должны соответствовать проекту?
Что должно проверять собеседование?
Как придумывать хорошие вопросы?
Надо ли следовать матрице компетенций?
и это только основные вопросы, которые стабильно возникают у каждого.
Давайте смотреть правде в глаза: практически никого не готовят к участи интервьюера - просто бросают и ждут результата. Чтобы понять качество такого интервью, можно просто представить, какой сайт напишет джуниор по сравнению с сеньором. Сайт, конечно, будет работать, и вроде бы результат удовлетворителен... Но могут возникнуть некоторые проблемы. Также и на собеседованиях - пока вы не получили достаточно опыта, то ваши решения совершенно не валидны. Возможно, мои выкладки выльются в серию статей, но давайте начнем с малого.
Определяем цели собеседования
У меня есть знакомый, с которым мы то работаем в одной компании, то расходимся по разным. У него существует собственный подход к собеседованию: есть стандартный сборник вопросов, которые он придумал или нагуглил, и абсолютно в любой ситуации он берет этот список вопросов и идет спрашивать людей. Любой уровень человека, любая компания, любая роль - вопросы плюс-минус всегда одинаковые. Естественно для джунов вопросы заканчиваются раньше - они дальше просто не в состоянии отвечать на следующие вопросы, у мидов чуть позже, а некоторые сеньоры и до конца списка доживают.
Хороший ли подход?
+: уровень всех разработчиков выстраивается в одну линейку и четко ранжируется
+: ответы хорошо известны и легко сравнивать правильность - да здравствуют контрольные в школах
+: матрица компетенций близка к этому подходу
-: много стандартных вопросов, ответы на которые уже все знают
-: кандидат может не подходить на должность, т.к. вопросы никак не соотносятся с работой
-: cофт скилы на стандартных ответах не проверяются
Его довод: "я в первую очередь стараюсь проверять понимание в разных аспектах программирования, а детали на работе узнают". Как итог, на собеседовании спрашивают про graphQL а проект работает на RPC. Дальше разочарование, страдание, увядание и увольнение, но иногда все заканчивается хорошо.
Безусловно такой подход заслуживает внимания, и по нему работает огромное количество интервьюеров.
Легко заметить, что у подхода хватает как плюсов, так и минусов. Сейчас я выделю цели интервью которые помогут взглянуть на процесс под другим углом.
Цели
Входное интервью
Когда применяется
Данный тип применяется для входа в большую компанию, зачастую аутсорсера. Если кандидат покажет выдающиеся результаты, то даже смело можно принимать на bench.
Задачи:
оценка уровня кандидата в соответсвии с линейкой, принятой в компании
проверка общих soft-скилов
составление примерных областей, в которых силен кандидат
валидация опыта
Фит интервью
Когда применяется
Данный тип применяется для входа на конкретное место или роль.
Задачи:
Оценка того, справится ли кандидат с задачами на проекте
Сможет ли он работать в команде
Анализируя цели, смотря и сравнивая подходы других коллег, я пришел к своей схеме, которая, как мне кажется, соответствует целям и задачам разных типов.
Немного моего подхода
Мой план на Входное интервью:
Валидация опыта - не более 30 минут - человеку проще всего говорить о своем опыте. Легко оценить задачи какого уровня человек решает, и как он исследует проблемы
Проверка умения писать код - 15-20 минут - легкая задача цикл, условия и их смесь. На удивление не всегда сеньоры пишут что-то адекватное.
Немного разговора на английском - 5 минут - никогда не спрашиваю стандартные темы. всегда что-то, связанное с работой. (опишите идеальный pipe деплоя)
Блиц опрос на разные темы - 15 минут - предупреждаю кандидата, что мне не нужны подробные объяснения, а нужны просто ключевые слова. Обычно успеваем вопросов 30 проговорить.
План на Фит
Парное программирование - 30-60 минут. Кто-то из команды совместно с кандидатом решает задачу
Обсуждение актуальной проблемы на проекте в соответствии с уровнем кандидата - до 30 минут. Проблемы могут быть разными: от выбора очереди или кэша до методов деплоя
Заключение
Сейчас я описал только первые вопросы, с которыми я сталкивался, начиная исследовать вопрос собеседований. Начало положено. Если статья зайдет, то продолжу дальше описывать свои изыскания. Спасибо за внимание.
Мораль
Когда идете собеседовать - определите цель, с которой вы это делаете. В зависимости от цели, должна меняться структура диалога, и вещи которые вы проверяете.