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

По одежке встречают

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

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

Швец, жнец и на дуде игрец

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

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

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

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

• Используемые в работе фреймворки, ORM, CMS и сторонние библиотеки.

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

• ООП. Классы, объекты, методы, свойства. Чем отличается абстрактный класс от интерфейса? В чем особенности статического метода и свойства?

Некоторые соискатели оправдывали плохое знание основ ООП многими причинами, в том числе и мифической «громоздкостью» и/или «сыростью». :) С другой стороны, не стоит бить кандидата по почкам, если он не помнит академического определения, но бойко рассказывает на «пальцах».

• Азы архитектуры. Вопросы про знание основных шаблонов/паттернов, MVC.

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

Лирическое отступление: Вообще, главное правило, которое я вывел за 7 лет практики: «Лучше плохие алгоритмы и хорошая архитектура, чем хорошие алгоритмы и плохая архитектура»

Далее идут специфические вопросы, не связанные напрямую с PHP. Для меня такими вопросами были моменты, связанные с основными сопутствующими знаниями: MySQL и фреймворк для работы с JS (предпочтительнее был jQuery), хотя в принципе, если время позволяет, список дополнительных вопросов можно расширить в сторону более низкого уровня (чем POST отличается от GET?) или расширить за счет регулярных выражений и более детальным разбором ООП (передача по значению/ссылке, магические методы и т.д.)

По MySQL можно пробежаться за пять минут, упомянув как общие понятия для реляционных БД (нормализация, ключи, связи между таблицами), так и специфические вещи (а чем там InnoDB отличается от MyISAM? Хранили бы вы всю финансовую информацию в таблице типа MEMORY?). В принципе, от ответов на эти вопросы зависело количество заданий, которое бы соискатель выполнял в практической части.

Тяжело в учении, легко в бою

Обычно, в случае если кандидат бодро отвечал на вопросы первой части я предлагаю ему стандартный набор из 3-5 заданий и оставляю его на полчаса. Какие типы заданий лучше всего могут охарактеризовать человека как специалиста за полчаса?

Паттерн проектирования: отлить в граните

Кандидат должен на бумаге изобразить простой шаблон проектирования в виде декларации класса и его инстанцирования. В этом задании проверяется, насколько человек помнит азы ООП и умеет выкручиваться в случае, если конкретная реализация паттерна подзабыта. В случае, если паттерн построен неверно или соискатель вообще не знает про такой паттерн, можно провести небольшую дискуссию на тему: «А как бы вы стали решать такую задачу..?»

SQL-запрос нашел героя

Далее идут два простых SQL запроса через несколько табличек. Первый — просто проверка, насколько быстро и адекватно человек может построить простой запрос с JOIN'ами. Второй — легкая модификация первого, для проверки знаний об агрегирующих функциях, группировках и HAVING.

Лирическое отступление: Если кандидат «поплыл», то желательно немного побеседовать о нормализации и пересечениях таблиц. На таком разговоре я срезал человека, который очень бодро доложился по PHP.
Когда он не смог построить простой запрос с JOIN'oм, я его спросил: «А как бы вы реализовали такую схему..?».
Правильным ответом было бы: «Я введу дополнительную таблицу связей articles2categories.»
Его ответом было: «Я создам по полю в articles и categories и буду хранить там соответствующие id в засериализованном виде»

Архитектор и творец

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

Конец — делу венец

К концу интервьюирования у вас должно сложиться четкое мнение о соискателе. Основными факторами для принятия решения должны быть:

1. общая оценка человека: поведение, внешний вид, поведение в сложных ситуациях, эмоциональность, энтузиазм
2. знания базиса
3. скорость реакции и адекватность ответов в сложных ситуациях

Собственно вердиктов может быть всего три:

• Моментальный отказ
• Рекомендация к приёму (если есть следующие инстанции перед приёмом)
• Отложенное решение (не более одной недели)

Если есть возможность — посылайте письмо даже в случае отказа. Идеально — указать человеку на недостатки и пожелать успеха :)

Краткое резюме

• Никаких тестов
• Никаких задач типа «напишите алгоритм вывода всех цветов радуги используя #000000 и битовые сдвиги»
• Знания по архитектуре «весят» больше знаний по стандартным функциям
• Задача собеседования — оценить уровень соискателя и его адекватность. Ничего большего.

Все части

• Еще раз об отборе программистов (часть 1)
• Еще раз об отборе программистов (часть 2)

Продолжение следует…