Чтобы найти хороших разработчиков, заставьте их читать чужой код

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

Старый способ

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

• Вопросы повторяются, и кандидаты часто упорно практикуются в запоминании ответов. Вы проверяете их навыки или их способность запоминать ответы?
• Задачи часто бывают с подвохом и требуют «озарения», чтобы придумать решение O(log(n)). За время собеседования истинное озарение почти никогда не посещает даже самых умных кандидатов.
• Он смещает баланс силы в пользу интервьюера. Кому понравится неуклюже писать код перед глазами судьи, от которого зависят ваши профессиональные перспективы на несколько лет?
• Написание кода на доске или даже в текстовом документе — неестественный и медленный процесс. В своей повседневной работе никто не пишет черновики кода на доске или в «Блокноте». На самом деле люди набрасывают код в IDE, активно пользуясь Google.

Путь получше

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

1. Чтение проверяет самые фундаментальные навыки. Чтение кода — это приблизительно 95% того, что разработчик делает на работе. Даже если он пишет новый код, устраняет баги или создаёт документацию, он постоянно читает. Какие способности нужны кодеру, чтобы хорошо читать код? Вот два важных навыка: 1) Способность запоминать переменные и расположение стеков, и 2) Способность обобщать фрагмент кода после того, как разработчик его понял. Я могу запомнить вопросы с собеседований по кодингу, но я не могу подготовиться к тому, что мне дадут какой-то произвольный код (если только не буду просто постоянно писать и читать код). По сути, подделать эти навыки невозможно.
2. Чтение кода намного эффективнее, чем написание. Кандидат может многое сказать о своих навыках программирования за первые пять минут чтения кода, потому что чтение практически на порядок величин быстрее написания. В собеседовании с чтением я могу пройтись по пяти важным темам за то же время, которое потребуется тому же человеку для написания кода изменения порядка символов в строке.
3. По сравнению с написанием кода чтение меньше напрягает кандидатов. Стресс — враг интервьюера, потому что он повышает уровень адреналина, что сильно снижает IQ, из-за чего вы будете упускать хороших кандидатов. Кандидаты предпочитают читать не только потому, что им не приходится напряжённо писать код, но и потому, что интервьюер может легко подстраивать вопросы по чтению под уровень навыков кандидата. (В такую подстройку можно включить и написание кода, если вам кажется, что кандидат этого хочет.)

Как я делаю это на практике

Вот практические советы по тому, как я провожу собеседования:

• Для каждого нового цикла собеседований я создаю набор упражнений «предскажи результат выполнения», которые поначалу очень просты, а потом становятся сложнее. Сейчас мой набор упражнений начинается с простейшего вызова функции, продолжается многоуровневыми вызовами функций, затем рекурсией, затем побочными эффектами. Обычно это «фальшивые» функции, которые должны обеспечить кандидату быстрый успех, а мне дать представление о том, как будет проходить дальнейшее собеседование. Для более сложных вопросов я беру код из проектов, которые я писал. Мои текущие «сложные» вопросы исследуют навыки создания абстракций во время чтения, а также отслеживания асинхронных операций. (Также для чтения можно использовать процедуры без названий, исполняющие хорошо известные алгоритмы наподобие сортировок или обхода дерева, и просить кандидатов искать баги по выводимым ошибкам.)
• Прежде чем задавать свои вопросы кандидатам, я калибрую задачи на своих коллегах, чтобы получить реалистичное представление о том, как измерять навыки кандидатов. Кроме того, калибровка вопросов позволяет мне совершенствовать их и избавиться от непонятных моментов.
• В начале собеседования я объясняю:
  
  
  • Я не проверяю знание синтаксиса. Считайте меня поисковиком Google с искусственным интеллектом, и я просто отвечу вам, что делает какая-то функция или оператор.
  
  
  • Я не ожидаю от вас, что вы закончите задание, потому что с этим никто не справляется. Мы просто остановимся через 20 минут.
  
  
  • Я не ожидаю от вас, что вы получите правильные ответы. Если ответ будет неверным, мне бы хотелось, чтобы вы вернулись назад и «отладили» свои рассуждения. Для меня это столь же ценно, как и всё остальное.
• Проверка будет проходить так:
  
  
  • Я показываю закомментированную строку кода, вызывающую некую функцию и возвращающую вывод.
  • Кандидат читает код и предсказывает вывод
  • Я раскомментирую строку и запускаю программу, чтобы он увидел ответ.
  • Если ответ отличается от предсказания кандидата, он возвращается обратно и объясняет, почему так получилось.
• Я даю кандидату 20 минут на то, чтобы он продвинулся настолько, насколько он сможет. Это даст мне время задать дополнительные вопросы. В отчёте о собеседовании я пишу, как далеко добрался кандидат и какие слабые и сильные стороны он продемонстрировал.

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

Возможно, кто-то из вас хочет знать, как развить свои навыки, чтобы хорошо проходить такие собеседования. Мой ответ прост — пишите много кода, потому что ничто не заменит регулярную практику. Как практиковаться? Проще всего — разрабатывать нетривиальные хобби-проекты, которые вам интересны. Игру, веб-сайт, приложение — всё, что угодно. Стремитесь уделять интересному вам коду по 4-8 часов в неделю и превратите его в то, что вам нравится использовать и чем вы гордитесь. (Кроме того, стоит захостить проект куда-нибудь и выложить исходники на Github, чтобы будущие работодатели могли видеть вашу активность и понять, как вы работаете.)