[comp.prog] Должны ли соискатели писать код на интервью?

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

Поиск программистов бывает двух типов – либо ищут программиста “вообще” (нам не хватает рабочих рук, нужно нанять пару толковых товарищей, а то не справимся), либо ищут конкретного спеца (без гуру в криптографии мы эту задачу не решим). Речь пойдет только о собеседовании программистов “вообще”. Возможно, при поиске конкретных узких специалистов ситуация иная.

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

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

• для соискателя собеседование – это стресс. Написание кода в таких условиях – это олимпиадный подход. По собственному опыту могу сказать, что далеко не все люди способны делать что-нибудь разумное в таких условиях. Так что, если вам нужен экстремал, который за 5 минут в три часа ночи через dial-up способен найти и устранить баг в 24x7 системе на другом конце света, то это может быть оправдано. Но тогда есть шанс упустить менее расторопного претендента, в программах которого такие сбои не будут возникать вообще;
• несоответствие масштабов. Вряд ли вы ищете разработчика, которому предстоит писать программки объемом 50-100 строк (и все они будут разными вариантами QuickSort). Скорее вы ищете человека которому предстоит выдавать по 50, ну максимум, по 150 отлаженных строк в день. Лично я не уверен в том, что способность быстро написать маленькую программку является доказательством способности спокойно и тщательно разрабатывать большую программу. Скорее, я уже уверен в обратном. Гораздо больше доверия у меня сейчас вызывает человек, который 20 минут будет обдумывать задачу, чем который за эти же 20 минут набросает ее решение;
• слишком много допущений. Когда вы даете соискателю задание за 20 минут написать небольшую программку, ожидаете ли вы, что он сделает это идеально? Думаю, что вряд ли. Поэтому в оценке наспех написанного кода будет неизбежно присутствовать некая дельта качества. И я думаю, что эта дельта может привести к ошибочным выводам относительно соискателя.

Для меня вышеперечисленные причины являются достаточными для того, чтобы отказаться от программирования на интервью. Но ведь способность соискателя к написанию кода как-то проверять нужно? Обязательно нужно. Но делать это следуют по другому. Сейчас наиболее адекватным способом мне кажется выдача соискателю небольшой задачи накануне интервью (небольшая – это с решением в 200-500 строк). С тем, чтобы решение он прислал перед интервью (это нужно для того, чтобы у вас было время проверить и оценить полученное решение). Почему такой способ лучше?

• человек решает задачу в комфортных для себя условиях. Поэтому, если он написал откровенную фигню, то оправдания “стрессовые условия”, “не было привычной мне IDE”, “не было времени подумать” и пр., идут лесом вместе с самим соискателем;
• вы видите более-менее реальное качество кода, которое способен выдавать человек. Поэтому, если в присланном решении вы найдете корявый стиль, отсутствие комментариев или другие проблемы, можете твердо быть уверены в том, что в лучшую сторону ничего уже не изменится;
• если человек задает вам наводящие вопросы относительно полученной задачи (а задача должна быть такой, чтобы вопросы задавались), вы получаете информацию об “адекватности” и “вменяемости” соискателя. Ведь с очень большой долей вероятности аналогичными вопросами он будет засыпать вас и после приема на работу. Поэтому, если вам встретиться человек, который будет консультироваться с вами по каждой строчке кода, то у вас будет возможность отправить его лесом еще до собеседования;
• вместе с кодом решения человек должен прислать и наборы тестовых данных, на которых он проверял свое решение. Эти наборы очень много расскажут вам о том, насколько качество программы важно для соискателя и как много он готов платить за это качество;
• не менее важную информацию об обязательности и ответственности соискателя вы получите от самого времени получения решения. Поскольку вы можете договориться об отсылке решения до 12:00, а соискатель пришлет вам его в 15:00, за пятнадцать минут до собеседования. И даже не объяснит, почему он не смог сделать этого до 12:00.

Итак, с помощью предварительно выданного задания вы уже получите достаточно много информации о соискателе, как о программисте. Поэтому на собеседовании вам останется выяснить, сам ли он сделал эту программу. Что не так сложно. Достаточно расспросить о том, почему он выбрал именно такое решение, какие альтернативные варианты он рассматривал, почему были выбраны именно такие тестовые данные, что оказалось самым простым, а что самым сложным в решении задачи и т.д.

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

А самый главный недостаток такого подхода в том, что он требует гораздо больше усилий от вас. Ведь задачу нужно придумать. Ее нужно самому решить. Нужно составить ее хорошее описание (с тем, чтобы минимизировать количество “глупых” вопросов, которые неизбежно будут задаваться). Затем, нужно за короткое время проанализировать и полученное решение, и тестовые данные. В общем, вкладывать придется гораздо больше собственных сил, чем в случае с маленьким заданием на собеседовании.

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