Мой любимый вид собеседования по программированию

Я ненавижу брать интервью.

Вообще-то... беру свои слова обратно. Я люблю брать интервью. Я просто ненавижу у меня интервью.

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

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

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

Отлично, я слышу, как вы думаете: У меня есть всего пара часов, чтобы познакомиться с этим человеком, как, черт возьми, я могу это сделать?

Проще говоря: с обдуманным планированием и исполнением.

Правильная оценка кандидата

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

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

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

1. Позвольте кандидату выбрать язык программирования.

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

2. Поощряйте знакомую обстановку.

Как правило, компании не должны диктовать инструменты, которые используют их инженеры. Vim или Emacs, CLI или GUI, даже Linux или... вы знаете... другие; в общем, не важно. Производительность превыше всего, и наш выбор инструментов помогает в этой производительности.

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

3. Оценивайте путь, а не пункт назначения.

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

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

Поощряйте прагматизм.

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

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

Выбор проекта

В идеале выбранный проект следует совету Джоэла Спольски о правильной оценке разработчики программного обеспечения по телефону: