Pull to refresh

Как я провожу собеседования программистов

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

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

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

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

Я не задаю философских вопросов типа «Кем Вы видите себя через пять лет». Этим занимается отдел кадров. Я разговариваю с кандидатами исключительно на технические темы.

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

Здесь, как правило, кандидаты совершают первую ошибку — пишут в резюме то, чего на самом деле не знают. Классический диалог:

— Где Вы применяли XSLT?
— Ну… нам в универе че-то рассказывали про это…

Или (реальный случай):

— Вы знакомы с работой DNS?
— Ну да, че там, было дело…
— Хорошо, скажите, какого уровня домен vkontakte.ru?
— Ну… высокого уровня, наверное…

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

Вообще, теоретическая часть сильно зависит от резюме кандидата. Независимо от резюме я обычно задаю два вопроса — «Какой самый сложный проект Вы делали» и «Приходилось ли Вам работать с какими-то внешними API, типа платежных систем или гуглокарт». Если дело имел и внятно рассказывает — это плюс. Замечание типа «прием уведомлений от яндекс-денег — отстой, у вебманей сделано гораздо удобнее (с обоснованием такого мнения)» — это большой жирный плюс.

Набор практических вопросов у меня давно уже устаканился и выглядит примерно так:

1) Проверка знания SQL

Задача: «Имеется таблица с двумя полями — Отдел и Сотрудник, требуется вывести те отделы, в которых работает более пяти сотрудников.»

Проверяется понимание кандидатом работы групповых функций и оператора HAVING.

Половина людей с группировкой знакомы чисто теоретически. Другая половина, знакомая с группировкой, чаще всего выдает такой результат:

SELECT otdel FROM table WHERE COUNT(sotrudnik)>5 GROUP BY otdel

Вариант этот, понятно, не работает, так как агрегатные функции нельзя использовать в операторе WHERE.

С трансцендентальным оператором HAVING вообще знакомы редкие единицы. На счет HAVING'а у меня бзик. Личные наблюдения показывают, что если человек знает и умеет применять HAVING, то это — толковый человек, почитавший документацию и порешавший практические задачи. Это как лакмусова бумажка.

Кандидат, который не может написать этот запрос, сразу получает большой жирный минус.

2) Проверка знания рабочего окружения

Задача: «В браузере открыт сайт test.local, требуется найти директорию, в которой находятся файлы этого сайта.»

Проверяется знание кандидатом системы DNS (определить IP сервера), умение работать с SSH (зайти на сервер), понимание того, что сайты отдает некий веб-сервер (никаких хитростей, используется Apache), умение прочитать конфиг Apache и найти там директиву DocumentRoot, указывающую на искомую директорию.

У значительной части людей (меня это удивляет и смешит одновременно) мозг взрывается уже при попытке понять, что такое «test.local». Следующая часть теряется на этапе резолвинга этого хоста (не знают про host или хотя бы про банальный ping). Ну и не все оставшиеся умеют читать конфиг Apache. Особенно трудно дается прочтение конфига, в котором виртуальные хосты вынесены в отдельный файл директивой Include.

3) Проверка знания Perl

Здесь у меня такая позиция: я никогда не задаю хитрые вопросы, ответ на которые хрен сразу сообразишь, а сообразив — нигде с пользой не применишь. Т.е. это вопросы типа «что будет если написать print $i++ + ++$i» или «напишите рекурсивное регулярное выражение для проверки вложенных скобок».

Стандартная задача довольно проста: «Напишите скрипт, который читает текстовый файл, построчно его обрабатывает и результат выводит в браузер. В файле находятся e-mail'ы, обработка заключается в проверке e-mail'ов на валидность с помощью регулярного выражения.»

Проверяется умение создать исполняемый perl'овый скрипт, умение работать с файлами, опыт работы с регулярными выражениями и умение выдать результат в удобочитаемом виде в браузер.

Многие, написав скрипт «hello world», вызвав его из браузера и получив ошибку 403 Forbidden, встают в тупик. Я не знаю, как так получается, но многие не в курсе того, что скрипт нужно сделать исполняемым. А кто в курсе — те часто не могут вспомнить команду смены прав доступа chmod.

Дальше мистической загадкой становится чтение из файла. Если открытие дескриптора open знакомо практически всем, то сделать цикл по \<FILEHANDLE\> догадывается не каждый.

Регулярку для проверки e-mail'а я прошу написать сложную настолько, наколько кандидат способен это сделать за несколько минут. Если написание регулярки затягивается дольше пяти минут, я прошу остановиться на достигнутом. Почти в 100% случаев результат получается такой:

/\w+?@\w+?\.\w+?/

Этот результат я считаю неудовлетворительным. Обычно в таком случае я задаю «вопрос на засыпку» — «какой недопустимый символ пройдет эту проверку?». В ответ я хочу услышать «подчеркивание». Не отвечает практически ни один.

Ну и, наконец, очередным камнем преткновения становится вывод в браузер. Примерно половина не догадывается, что вывод собственно результата должен быть предварен выводом HTTP-заголовка. Другая половина, которая помнит, что надо что-то вывести, не помнит, что именно надо вывести.

По ситуации, я могу еще попросить усложнить скрипт — вынести проверку в отдельную функцию, функцию вынести в модуль, и, для самых толковых, модуль сделать объектно-ориентированным. До этих усложняющих этапов доходит примерно четверть кандидатов.

Результаты собеседований меня неизменно расстраивают. Подавляющее большинство кандидатов ужасны.
Tags: perlсобеседованиеработа
Hubs: Lumber room
Total votes 103: ↑74 and ↓29 +45
Comments 189
Comments Comments 189

Popular right now