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