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

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

Большинство компаний-разработчиков программного обеспечения производят простое программное обеспечение CRUD. То есть софт с формами, базой данных и отчетами.

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

Вот как я провожу собеседования с разработчиками для типичных софтверных компаний:

Шаг 1. Назначьте базовую задачу программирования

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

Прагматичный кандидат ответит: «Я бы использовал API моего языка, потому что в нем уже есть функция реверса строки». Или они скажут: «Я бы поискал это на Stack Overflow, потому что там обязательно найдется хорошее решение, быстрое и без ошибок».

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

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

При необходимости я бы переформулировал вопрос: «Как бы вы написали код для переворачивания строки, если бы вы не могли использовать существующий API и не могли обратиться за помощью в Интернете».

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

Удивительное количество людей не в состоянии выполнить эту задачу. Это нормально; собеседование должно помочь отфильтровать таких людей, чтобы вы знали, что их нельзя нанимать.

Шаг 2: Защитите свой код

Предполагая, что они действительно пишут код, мой следующий вопрос: «Теперь найдите ошибку в своем ответе». Я спрашиваю это, могу ли я увидеть ошибку или нет. Там почти наверняка есть ошибка, потому что такова природа написания инструкций для тупоголовых компьютеров. Даже если ошибки нет, это показывает их подход к отладке. Могут ли собеседники снисходительно принять возможность того, что они допустили ошибку, или они отказываются принимать такую ​​возможность? Внимательно ли они просматривают код в поисках проблем? Они начинают думать о крайних случаях, которые могут быть проблемой?

Далее я спрошу, какие тестовые примеры они будут использовать для проверки правильности работы этой функции. Вот что я ищу:

  • знают ли они о тест-кейсах и тепло ли относятся к концепции
  • правильно ли они продумывают крайние случаи

Шаг 3. Оцените мягкие навыки

Как только я убедился, что они действительно могут выполнить базовую задачу по программированию, меня теперь интересуют межличностные навыки, например, как они работают в команде, как они принимают обратную связь и приходят ли они вовремя. Любой приличный программист может делать CRUD-приложения. Но будет ли с ними приятно работать? Точно сказать сложно, поэтому отчасти приходится пользоваться своей интуицией. Я оцениваю, пришел ли интервьюируемый вовремя или даже раньше. Я выясняю, читали ли они о моей компании и нашем продукте.

Шаг 4: Есть сомнения? Отклонить их

Принимать не того человека в команду болезненно. Это намного болезненнее, чем отсутствие никого в этой роли. Я совершил ошибку, наняв людей, в которых был уверен только на 75%. Теперь я лучше оставлю роль пустой, чем возьму кого-то, кто может ошибаться.

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

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