Мой способ проводить собеседования

Перевод статьи Адама Ситника – инженера .NET в Microsoft о том, как он проводил свои собеседования до присоединения к команде MS.

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

Кандидат, при этом, оценивает вас как интервьюера. Очень часто, именно вы производите первое впечатление о компании, поэтому вам необходимо сделать все возможное, чтобы оно было положительным. Никто не хочет работать с грубыми и некомпетентными людьми!

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

Мой стиль интервьюирования эволюционировал с годами. Изначально я был сфокусирован на задании прямых технических вопросов:

• Каковы различия между Value и Reference Types?
• Как работает Garbage Collector?
• В чем разница между DROP TABLE и TRUNCATE TABLE?

Но очень скоро я понял, что тот факт, что кто-то может ответить на подобные вопросы, не означает, что он или она сможет выполнять свою работу

Кроме того, тот факт, что кто-то не знает ответов, не означает, что он не сможет их быстро найти и обучиться, когда это требуется.

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

Узнайте как можно больше о проекте, по которому вы проводите собеседование. Это что-то из разряда Rocket Science? Или техническое обслуживание? Или простой CRUD? Какая технология?

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

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

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

После этого мы могли бы поговорить пару минут о выходных. Кандидат просто должен начать говорить! Если кандидат не был в отпуске в течение многих лет, вы можете сказать, что компания может предложить:

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

И да, мои дорогие читатели из США, 30 или даже 35 дней полностью оплачиваемого отпуска – нормальная тема в Европе. То же самое относится и к неограниченным больничным дням. (прошу прощения, что вклиниваюсь, сам недавно получил рабочую визу в Швецию – реально 35 дней отпуска)

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

• Что вам больше всего нравится в программировании?
• Что такого в программировании, что вам не нравится?
  
• Не могли бы вы описать работу своей мечты?
  

Некоторые кандидаты говорят, что могут делать все, что угодно. В таком случае я спрашиваю, будут ли они рады отладить некоторые старые Java-скрипты в Oracle Bus или мигрировать реляционную базу данных без документации в облачную базу данных NoSQL за две недели. Мне нужно убедиться, что они понимают, что я задаю эти вопросы, чтобы не дать им проект, который им не понравится. Ответы помогают мне понять, подходит ли данный человек для проекта и позиции, о которой идет речь.

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

Самый смешной ответ, который я когда-либо получал:

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

• Какой ваш любимый способ изучать что-то новое?
• Когда вы в последний раз учились чему-то новому? Что это было? Как вы применяли это в работе?
  
• Есть ли у вас люди с авторитетным мнением? Кто они и за что вы их цените?
  
• Когда вы в последний раз не соглашались с какой-либо записью в блоге/книгой/видео? Что это было и почему вы не согласились?
  
• Когда вы в последний раз меняли одну из своих привычек в программировании? Что это было и почему?
  
• Когда вы в последний раз делились своими знаниями с кем-то другим? Вам понравилось? Почему вы это сделали?
  

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

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

Начну с чего-то вроде: Не могли бы вы рассказать о вашей последней большой задаче, над которой вы работали? Что вы должны были реализовать, какие шаги вы предприняли и какую технологию вы выбрали? Секреты компании меня не интересуют, я просто хочу понять ваш подход и как вы решаете проблемы.

Здесь я выслушиваю кандидата и задаю много вопросов:

• Почему вы сделали именно так?
• С чего вы начали? Вы проводили какое-то исследование? Общались с клиентом?
• Какие технологии и/или компоненты вы выбрали и почему?
• Когда вы писали тесты?
• Было ли что-нибудь, что вы могли бы сделать лучше?

Я задаю столько вопросов, сколько нужно. Здесь я очень часто углубляюсь в технические детали. Я задаю глубокие технические вопросы, связанные с инструментами и компонентами, используемыми кандидатом, чтобы понять, знает ли он, как они работают. Если кандидат не отвечает на некоторые вопросы, я говорю что-то вроде: Не бойтесь, это совершенно нормально, что вы чего-то не знаете. Я просто проверяю ваши знания. Я не ожидаю, что вы все знаеете. Иногда это просто ложь, особенно когда человек не может ответить на простой вопрос, но важно не пугать кандидата!

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

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

Таким образом, данный кандидат каким-то образом сумел решить проблему, но не воспользовался нужным инструментом и, более того, не провел нужного исследования. Это занимает много времени и приводит к определенным рискам в боевой системе.

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

Это просто. Я спрашиваю о последней неудаче. Что это было? Почему это случилось? Чему вы научились? Что вы сделали, чтобы проблема не повторилась? Я хочу нанимать людей, которые могут признать, что они сделали что-то не так, и учиться на своих ошибках. Никто не хочет работать с нарциссистами. Обычно люди боятся отвечать на этот вопрос, поэтому я поощряю их, говоря о моей недавней неудаче. Это очень помогает большинству кандидатов открыться.

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

Когда кандидат ответит: Я просто гуглю, я отдаю свой ноутбук и позволяю ей/ему искать решение в течение нескольких минут. Я проверяю, что они вводят в поиск. Большинство кандидатов очень удивляются, когда я это делаю. Но я ищу людей, которые могут решать новые проблемы, а не древность из книги Cracking the Coding Interview. А решение новых задач обычно требует его хорошенько поискать.

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

• Говорите о чем-то позитивном и не связанном с собеседованием, чтобы кандидат смог расслабиться.
• Спросите о том, что кандидат действительно хочет и не хочет делать. Подходит ли позиция и проект?
  
• Спросите об обучении, потому что обучение - это фундаментальная часть работы инженера-программиста.
  
• Задавайте много вопросов о недавнем задании, чтобы узнать, как кандидат подходит к решению проблем.
• Спросите о неудачах, чтобы отфильтровать нарциссов.
  
• Расскажите о вашем недавнем задании, чтобы узнать, как данный человек решит реальную проблему, связанную с работой, на которую вы проходите собеседование. (простите, что опять вмешиваюсь, но пункт – так себе, нырять в чужие костыли еще до найма...)
  

В комментах Адама спросили почему он перестал собеседовать людей, когда попал в Microsoft. Вот что он ответил: