За время работы в IT автор провел более двухсот интервью с инженерами и тимлидами. В этой заметке разберем структуру собеседования, подготовку к нему, а также техники сбора информации о кандидате для принятия решения о найме. Таким образом, читатель сможет лучше понять, как построить интервью и на что обращать внимание.
Прежде чем вы окажетесь в переговорной с кандидатом, опишите, кого вы хотите найти. Для этого в профиле кандидата выделяют три блока: базовый минимум знаний, требования, дополнительные преимущества.
Первый блок — базовый минимум знаний — нужен, чтобы отсеивать непрофильных кандидатов на стадии обработки резюме. Если ваш отдел занимается веб-разработкой, а кандидат про HTTP едва что-то слышал, наверное, это не тот кандидат, который вам подходит. Ошибкой будет включить слишком много пунктов в базовый минимум. Например: ваши фронтендеры пишут на фреймворке Х, на рынке есть много опытных разработчиков, не знающих про Х, возможно, они вам подходят. Помните, базовый минимум знаний — первый фильтр в вашей воронке, не пишите все подряд.
Во втором блоке мы проверяем, насколько кандидат соответствует требованиям. Для определения уровня подходит модель знания-умения-навыки. Прежде чем пойти дальше, давайте разберем, в чем отличия между знаниями, умениями и навыками. Определения могут отличаться от общепринятых, автор использует слова как термины, применимые к данной модели, и не пытается заменить их повседневный смысл.
Знания — теоретические представления о деятельности. Пример: окончивший автошколу человек знает ПДД, понимает, как выполнять параллельную парковку, но ездить по реальным дорогам получается плохо. Другой пример жонглирование — понимание принципов не делает вас жонглером.
Умения — воспроизводимое поведение в определенных условиях. Успешность результата во многом зависит от условий. Я умею водить, но в условиях гололеда теряюсь, и машину ведет. Умею жонглировать тремя теннисными мячиками. Ну или насущный пример с кодинг-интервью — писать код я умею, а на интервью на доске, под стрессом, получается не очень.
Навыки — устойчивое поведение, слабо подверженное влиянию среды. Пример с вождением: я могу доехать из точки А в точку Б в дождь, в гололед, на автомате, на механике. Жонглер умеет жонглировать котятами и бензопилами, стоя на ходулях в гамаке.
Такой подход позволяет выразить требования к роли на трехуровневой шкале. Например, мы ищем разработчика и хотим проверить его знания в области баз данных. При этом у нас в профиле кандидата есть следующие требования:
- Может писать сложные запросы (навык)
- Может оценивать эффективность запросов (навык)
- Умеет строить индексы для ускорения запросов (умение)
- Имеет представление о партиционировании данных (знание)
Вот как может быть построен диалог с кандидатом на эту тему:
— Какую БД вы используете на текущем проекте? Как работаете с БД? Используете ORM?
— У нас все хранится в postgres, ORM не используем, пишем sql руками.
— А какой примерно размер БД? Сколько записей в основных таблицах?
— База весит 6 Гб, в таблице users порядка 50 тысяч записей, в таблице заказов примерно полмиллиона. (Теперь у нас есть почва для проверки нашего профиля.)
— Подскажи, пожалуйста, как можно выбрать всех пользователей, у которых более 10 заказов?
— INNER JOIN пользователей на заказы с группировкой по user_id.
— А как ты узнаешь, у каких пользователей больше 10 заказов?
— Сделаю HAVING count(user_id) > 10
Мы на конкретном примере проверяем, что кандидат умеет писать запросы. Можно задать еще вопрос: «А как выбрать пользователей, у которых нет ни одного заказа?» Если кандидат не смог ответить, практического опыта в написании запросов у него нет. Если бы он написал запрос по памяти на листе, это говорило бы об устойчивом навыке.
Переходим ко второму пункту:
— Давай продолжим, у меня есть таблица заказов, я выбираю все заказы за прошлый месяц, но мой запрос выполняется очень долго. Как я могу понять, в чем проблема?
— Можно запустить EXPLAIN на этот запрос. (Он знает про EXPLAIN, но это не говорит про умение им пользоваться, ищем дальше.)
— Что в результатах вывода EXPLAIN поможет тебе понять проблему
— Не знаю, я пользовался только пару раз, пойду гуглить. (Знание есть, умения нет.)
Несоответствие по второму пункту не мешает нам оценить третий пункт:
— И все же, если ты видишь, что запрос заказов за прошлый месяц выполняется несколько секунд, как можно его ускорить?
— Мы можем повесить индекс на колонку created_at. (Знает про индексы, ищем дальше.)
— Какой тип индекса ты бы использовал для этого запроса?
— B-Tree, мы делаем поиск по интервалу значений. (Шарит, возможно, пробел с EXPLAIN легко закрыть обучением.)
Таким образом, вы плавно погружаетесь в каждый пункт вашего списка требований и оцениваете опыт кандидата. После отработки этого подхода ваши интервью станут похожи на диалог с кандидатом, без пауз, без выдумывания вопросов и перескакивания с темы на тему. Помимо этого, плавное погружение позволяет устранить случайные факторы — кандидат может волноваться, может не понять вопроса, может упустить переход от одной темы к другой.
Вот обратный пример, который я много раз встречал на интервью:
— У вас есть опыт с python, расскажите что такое GIL?
— Какой ИГИЛ?
— Вы писали на javascript, что такое event loop?
— ...
Что вы проверяете? Какую информацию о кандидате вы получаете, задавая такие вопросы? Какие выводы вы можете сделать на основании ответов? Какие выводы собеседник сделает о компании?
Помните, что кандидаты тоже собеседуют вас, у них есть из чего выбирать. На вас свет клином не сошелся, даже если вы Google, Facebook или Amazon. Результат собеседования — это не только решение о найме кандидата, но и его впечатление от интервью.
Имея список технических компетенций, определив их желаемый уровень с помощью модели знания-умения-навыки, у вас появляется возможность сравнивать кандидатов друг с другом. Важно сравнивать кандидатов не с идеалом, а именно друг с другом на основании вашего профиля. Идеальный кандидат может к вам не пойти, он может вовсе не существовать. Снимите розовые очки и работайте с реальностью.
Может оказаться, что профиль у вас ого-го, а уровень кандидатов на входе низкий. Ищите, что не так в системе найма: не там ищете, низкие ставки, плохой hr-бренд, неинтересный проект, вакансия плохо описана.
Дополнительные преимущества кандидата. Помните, что отсутствие плюсов не является минусом, вы не бракуете кандидатов по этой группе. Пример: для вашего профиля будет плюсом опыт работы с облачными провайдерами, а у кандидата этого опыта нет, это не значит, что кандидат вам не подходит.
Допустим, мы проверили кандидата по необходимым знаниям-умениям-навыкам и перешли к поиску дополнительных преимуществ. Допустим, нас интересует опыт низкоуровневых оптимизаций, а кандидат ничего не знает про уровни кешей CPU, кеш-линии, протокол MESI. Не страшно, вы же ищете дополнительные преимущества, если этот опыт обязателен, перенесите в требования.
Процесс найма субъективен и зависит от многих факторов. Помимо уровня кандидата на результат влияют сам интервьюер, имидж компании, обстановка на собеседовании и многое другое.
Задача в процессе собеседования — ответить на вопрос: «Справится ли кандидат с работой?» Для этого мы выражаем суть работы через модель знания-умения-навыки, оцениваем прошлый опыт и отметаем случайные факторы.