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