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

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

Это действительно то, что нужно выбирать при приеме на работу нового члена инженерной команды — человека, у которого было больше всего свободного времени, чтобы инвестировать в изучение задач leetcode?

Будучи по обе стороны медали, я всегда не любил упражнения с литкодом как механизм оценки технических кандидатов по ряду причин:

  1. Несмотря на то, что решение алгоритмически сложных задач доставляет удовольствие и приносит удовлетворение, реальность такова, что для наиболее продуктивных разработчиков большая часть нашего времени кодирования на самом деле не сосредоточена на этом типе работы.
  2. Большинство из нас регулярно обращаются к StackOverflow, документации и другим онлайн-ресурсам при решении сложных задач кодирования изо дня в день. Мы будем общаться с коллегами и обсуждать различные идеи. С появлением инструментов кодирования ИИ многие разработчики уже включают Copilot и ChatGPT в свои рабочие процессы.
  3. Многие типы/классы сложных задач, мы можем кодировать только один или два раза за голубую луну. Например, у меня есть сложный уровень абстракции Firestore, который я написал однажды, и который я постоянно использую повторно. Смысл написания сложного кода с высокой степенью абстракции заключается в том, что вы пишете этот тип кода только один раз.
  4. Это создает искусственную ситуацию, вызывающую стресс. Немногие из нас программируют, пока другие наблюдают за нами через плечо. И меньшее число из нас программирует в условиях фиксированного временного ограничения в реальной жизни. Для решения сложных задач я могу пойти на прогулку, поговорить с коллегой, исследовать алгоритмы, сначала создать небольшую игрушечную кодовую базу и т. д. Честно говоря, большинство из нас, вероятно, создают свой лучший код в изоляции, когда мы находимся в состоянии потока. ; полная противоположность интервью с высокими ставками.
  5. Разработчики лучше всего пишут код в своей среде с помощью собственных инструментов. Использование незнакомого инструмента может дезориентировать и, опять же, добавить стресса и беспокойства, когда кто-то наблюдает.

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

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

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

8 причин считать код-ревью собеседованием

Есть несколько причин, по которым я считаю, что обзоры кода делают собеседование по техническим вопросам более приятным:

  1. В эпоху ИИ появляется новая причина, заключающаяся в том, что использование сгенерированного ИИ кода является источником риска с точки зрения производительности, безопасности и внутренних передовых практик (особенно важно в регулируемых отраслях). Способность эффективно оценивать код в контексте большей кодовой базы становится еще более важным навыком, когда вы полагаетесь на фрагментарно сгенерированный код.
  2. Это лучшее отражение повседневной деятельности, в которой участвуют инженеры, особенно на более высоких должностях. Предоставление эффективных рекомендаций и качественной обратной связи коллегам и особенно младшим членам команды может повысить общую производительность и качество результатов в долгосрочной перспективе.
  3. Он обеспечивает более целостное представление о том, как кандидат рассуждает, думает и общается; другими словами, это дает лучшее представление о кандидате как о члене команды в целом. Это включает в себя понимание глубины опыта кандидата.
  4. Код-ревью по своей природе более совместный, в то время как написание кода имеет тенденцию быть более изолированным занятием (лично я предпочитаю кодировать в полной тишине в вечерние часы). Проверка кода, возможно, является лучшим индикатором того, каково это работать вместе с кандидатом, а не когда кандидат решает техническую головоломку.
  5. В обзоре кода больше субъективизма; это не черное или белое. Это, естественно, предоставляет больше возможностей для обсуждения и интерпретации. Это также дает больше возможностей для получения выбросов, поскольку единого решения не существует. Для 5 кандидатов вы получите 5 уникальных вариантов, тогда как обычные алгоритмические задачи могут иметь небольшое количество оптимальных ответов.
  6. Трудно «обмануть», используя генеративный ИИ или изучая проблемы с литкодом.
  7. Он лучше подходит для оценки технических ролей, в которых предпочтение отдается чтению кода, а не его написанию. Сюда входят инженеры-менеджеры, архитекторы и вспомогательный персонал.
  8. Это лучше отражает то, как кандидат собирается провести свои первые несколько дней или недель: изучать существующую систему, читая код. Разве не имеет смысла измерять, насколько хорошо они могут это делать, а не то, как быстро они могут решить N-ферзей?

Стратегии

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

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

“На природе”

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

Охотник за ошибками

Намеренно внесите какой-нибудь логический изъян или дефект и посмотрите, сможет ли кандидат его заметить. Хорошая идея — вернуться назад и найти недавние ошибки, которые были устранены, и извлечь исходный код до того, как исправление было применено. Может ли кандидат определить основную причину? Как бы кандидат предложил устранить дефект? Чем этот ответ отличается от того, который был реализован?

Рефакторинг и редизайн

Недавно завершили рефакторинг или планируете рефакторинг? Используйте код до рефакторинга в качестве контекста и посмотрите, что кандидат думает о коде до рефакторинга и какие стратегии кандидат будет использовать для планирования и выполнения рефакторинга. Посмотрите, может ли кандидат определить, почему рефакторинг был бы желателен, и оценить сложность своего подхода; вы можете быть удивлены и найти совершенно новый альтернативный подход!

Это особенно полезно, когда кандидат присоединяется к уже существующему проекту.

ориентированный на производительность

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

Включите существующую схему SQL DDL и общие запросы на естественном языке, которые будет выполнять приложение. Удалите определения индексов и посмотрите, может ли кандидат предложить индексы или альтернативные схемы для повышения производительности.

Вместо того, чтобы спрашивать о принципах нотации Big-O, посмотрите, действительно ли кандидат может обнаружить некоторые O(n^2) код или N+1 проблемы в коде доступа к данным!

Ориентирован на тестирование

Поделитесь фрагментом кода и набором модульных тестов для кода. Все ли случаи покрыты? Есть случаи, которые не охвачены? Как можно улучшить модульные тесты? Эта перспектива может быть более важной в наступающем веке кода, сгенерированного ИИ: понимание пространства предметной области и варианта использования, а также того, как писать модульные тесты с высоким охватом — или оценка полноты сгенерированных модульных тестов — становится ключевым навыком.

Ястреб безопасности

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

Лучшие практики

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

Попробуйте CodeRev.app

Если вы, как и я, поддались этой идее, посмотрите мой новый проект CodeRev.app: https://coderev.app.

CodeRev.app — это (бесплатный) легкий инструмент, разработанный для облегчения проверки кода в виде собеседования.

Зачем использовать его вместо CodeSandbox, Stackblitz или GitHub?

  • CodeRev сосредоточен на чтении и комментировании, а не на написании кода, тогда как GitHub комментирует только PR.
  • CodeRev отлично работает с фрагментами кода, и вы можете смешивать и сопоставлять разные файлы, не пытаясь запустить проект в целом. Просто добавляйте любые файлы для интересного обсуждения!
  • CodeRev устраняет шаблоны, присущие современным проектам, которые могут возникнуть соблазн загрузить в CodeSandbox или Stackblitz. Просто выберите интересные исходные файлы и поместите их в CodeRev.
  • CodeRev позволяет быстро переключаться между ответами от разных кандидатов, чтобы вы могли сравнить и просмотреть информацию и отзывы, которые они предоставили.

Это все еще ранняя стадия, поэтому дайте мне знать, если вы столкнетесь с ошибками или у вас есть идеи!

Заключительные мысли

В Конец среднего Тодд Роуз пишет:

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

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

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

По мере того, как наша отрасль меняется и профессионалы все больше полагаются на инструменты искусственного интеллекта, такие как Copilot и GPT, для создания кода для повышения производительности, все большее значение приобретает поиск способов выявления зазубренных талантов; роботизированное решение алгоритмических головоломок становится меньшим из тех качеств, которые мы хотим видеть в кандидате. Вместо этого, возможно, ключевым навыком является способность читать и анализировать этот код на предмет правильности, передового опыта и безопасности.

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

Спасибо Лефану Тан Цзя Хуэй, Арашу Рохани и Робу Аларкону за просмотр черновиков этой статьи и предоставление отзывов.