При найме разработчиков мы обращаем внимание на многие вещи, но с годами я обнаружил, что умение писать сырой код — это самое простое качество, на которое можно обращать внимание. Я могу быстро обучить человека знаниям в какой-то области, но я никогда не видел, чтобы способности к программированию исходили из чего-либо, кроме обширной и глубокой практики. Из-за этого я обнаружил, что для выявления талантов некоторые методы работают лучше, чем другие.
По старому
Типичное собеседование по программированию начинается примерно так: «Напишите функцию, которая меняет порядок букв слов в строке на обратный». Затем в течение следующих получаса или более кандидат чертит что-то на белой доске (или в общем текстовом документе, если повезет). Такой подход плох по ряду причин:
- Одни и те же вопросы с собеседований распространяются по кругу, и кандидаты часто очень усердно тренируются, чтобы запомнить ответы. Вы проверяете их навыки или их способность запоминать ответы?
- Проблемы часто представляют собой «хитрые» задачи, требующие глубокого понимания, чтобы найти O(log (n)) решение. Истинное озарение почти никогда не приходит даже к самым умным кандидатам во время собеседования.
- Это смещает баланс сил в пользу интервьюера. Кому нравится неуклюже писать код перед судьей, который будет определять ваши профессиональные перспективы на следующие несколько лет?
- Писать код на вайтборде или даже в текстовом документе неестественно и медленно. Никто не рисует код на доске или в блокноте в рамках своей повседневной работы. Что люди действительно делают, так это набрасывают код в IDE с большой помощью Google.
Лучший способ
Поэтому вместо того, чтобы писать код, подумайте о том, чтобы кандидат прочитал существующий код и рассказал о том, что он делает и как работает. Это дает ряд весомых преимуществ:
- Чтение кода исследует самые фундаментальные навыки. Чтение кода, вероятно, составляет 95% того, что разработчик делает в рамках своей работы. Пишет ли разработчик новый код, исправляет ошибки или создает документацию, он постоянно читает его. Какие способности нужны программисту, чтобы хорошо читать код? Есть пара важных: 1) способность запоминать переменные и расположение стека и 2) способность обобщить фрагмент кода, как только он его понимают. Я могу запомнить вопросы по кодированию на собеседовании, но я не могу подготовиться к тому, что меня впихнут в какой-то случайный код (кроме того, что я буду постоянно писать и читать код). Практически невозможно подделать эти навыки.
- Читать код намного эффективнее, чем писать. Кандидат может многое рассказать вам о своих навыках программирования в первые пять минут чтения, потому что чтение легче и на порядок быстрее, чем письмо. На собеседовании с чтением я могу обсудить около полдюжины важных тем за то время, которое потребовалось бы тому же человеку, чтобы написать код для перестановки символов в строке.
- Чтение облегчает кандидатам задачу по сравнению с написанием кода. Для интервьюера стресс собеседника — враг, потому что он повышает адреналин, который снижает IQ на несколько пунктов, из-за чего вы пропускаете хороших кандидатов. Кандидаты предпочитают читать код отчасти потому, что им не нужно писать его, а также потому, что интервьюер может легко корректировать вопросы чтения в соответствии с навыками кандидата. (Эта корректировка может включать в себя написание кода, если кандидат этого хочет.)
Как я это делаю на практике
Вот несколько практических моментов в том, как я на самом деле делаю это на собеседованиях:
- Для каждого нового цикла интервью я создаю набор упражнений с прогнозируемыми результатами, которые начинаются очень легко, а затем усложняются. Мой текущий набор начинается с вызова базовой функции, затем многоуровневых вызовов функций, затем рекурсии, а затем побочных эффектов. Как правило, это «притворные» функции, которые предназначены для того, чтобы дать кандидату быстрый успех и дать мне некоторые подсказки о том, как пройдет остальная часть собеседования. Для более сложных вопросов я извлекаю код из того, что написал. Мои текущие «сложные» вопросы исследуют способность делать абстракции во время чтения, а также следить за асинхронными операциями. (Некоторые другие вещи, которые обуславливают хорошее чтение, — это непомеченные подпрограммы, которые выполняют хорошо известные алгоритмы, такие как сортировка или обход дерева, поиск ошибок по выходным данным об ошибках.)
- Прежде чем задавать вопросы кандидатам, я сопоставляю свои вопросы с людьми, с которыми работаю, поэтому у меня есть реалистичные ожидания относительно того, как оценить навыки кандидатов. Калибровка вопросов также помогает мне уточнить их и отсеять запутанные.
- В начале интервью я объясняю:
- Я НЕ проверяю знание синтаксиса. Относитесь ко мне как к Google с поддержкой ИИ, и я просто скажу вам, что делает какая-то функция или оператор.
- Я не жду, что вы закончите, потому что этого никто не сделает. Мы просто остановимся через 20 минут.
- Я не жду от вас правильных ответов. Если ответ неверный, я бы хотел, чтобы вы вернулись и отладили свое мышление. Это так же ценно для меня, как и все остальное.
- Тест проходит так:
- Я показываю закомментированную строку кода, которая вызывает некоторую функцию и возвращает значение.
- Кандидат читает код и предсказывает значение.
- Я раскомментирую строку и запускаю программу, чтобы он мог увидеть ответ.
- Если ответ отличается от их прогноза, они возвращаются и объясняют, почему.
- Я даю кандидату 20 минут, чтобы пройти как можно дальше. Это дает мне дополнительное время, чтобы задать дополнительные вопросы. В отчете об интервью я пишу, как далеко продвинулся человек и какие сильные и слабые стороны он показал.
Очевидно, что эти специальные навыки программирования — не единственное, что нужно проверять на собеседованиях. Знание предметной области и культурное соответствие важны, однако я считаю, что чтение кода отлично справляется с отсеиванием кандидатов, которые не подходят по тому, что важнее всего.
Некоторые из вас, возможно, захотят узнать, как развить свои навыки, чтобы успешно пройти такое собеседование. Мой ответ прост: пишите много-много кода, потому что ничто не заменит регулярную практику. Как практиковаться? Самый простой способ — запустить несколько нетривиальных побочных проектов, которые вам небезразличны. Игра, веб-сайт, приложение… что угодно. Выделите 4–8 часов в неделю на изучение кода, который вам небезразличен, и сделайте его тем, что вам нравится использовать и чем вы гордитесь. (Кроме того, полезно опубликовать его где-нибудь и разместить исходный код на GitHub, чтобы будущие работодатели могли видеть вашу активность и понимать, как вы работаете.)
Надеюсь это поможет.