Собеседование Java-разработчиков. Шесть лет спустя

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

Прежде всего отмечу, что мы не используем всяческих анкет и списков вопросов. Несколько раз я сталкивался с компаниями, в которых техническое интервью построено следующим образом: специалист берет соответствующий вакансии список вопросов и задает их кандидату один за другим. Например, 5 вопросов по Java, 3 по Spring Framework, 4 по WebLogic, 5 по SOA и т.д. У нас такой подход не прижился, т.к. он обезличивает процесс. Нет ни собеседуемого, ни собеседующего, есть два механических робота, задача одного из которых прочитать список вопросов, а другого - максимально обще на них ответить. Никакой беседы при этом построить невозможно. "- Вы знаете WLST? - Да", вот и все собеседование.

Вместо этого предпочитаем строить собеседование как разговор равных, уважающих друг друга специалистов. Прежде всего стремимся побольше узнать о предыдущем опыте кандидата, а потом исходя из него задаем вопросы. Например, человек говорит, что разрабатывал что-то для банка на основе Spring Framework и созданная им программа работала на сервере приложений Oracle WebLogic. Здесь можно задать несколько вопросов по предметной области. Важно чтобы человек не просто механически кодировал, но хоть немного понимал что он делает и зачем. Так же можно спросить, а почему кандидат использовал Spring Framework, а не Java EE с EJB или CDI. Ответы бывают довольно интересными. Хотя, конечно, если человек претендует на позицию Junior'а, то он скажет, что данный выбор был сделан не им. Тогда можно продолжить разговор уже про сам Spring Framework и попросить рассказать какой компонент фреймворка отвечает за построение объектов. Общая идея такова: ответ на любой вопрос является источником следующего. Таким образом получается беседа, которая позволяет и кандидату немного расслабиться, и нам понять границы области его знаний.

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

• Вопросы по теории программирования: вывод типов, статическая и динамическая типизация, алгоритмы, работа с памятью Разговор получается интересным, если человек владеет каким-нибудь скриптовым или функциональным языком программирования. Нам важно, чтобы кандидат имел определенную теоретическую подготовку, мог обосновать выбор того или иного подхода или языка программирования с точки зрения удобства разработки, производительности, предметной области. Уметь написать Hello World на Groovy или Scala еще не значит владеть функциональным программированием.
  
  
• ООП и, если знает, функциональное программирование. Про ООП просим рассказать как человек понимает суть парадигмы. Какие преимущества дает объединение данных и кода в объекты. Интересно, как кандидат понимает полиморфизм. Какие виды полиморфизма ему известны. Почему-то вызывает сложности вопрос о том, а можно ли обойтись без наследования. Если человек знаком с функциональным программированием, то интересуемся практическим опытом его применения. Здесь же просим спроектировать что-то несложное.
  
  
• Паттерн "Инверсия управления" (IoC), его разновидности и конкретные реализации. Сейчас трудно найти команду разработчиков, которая в своей работе не использовала бы какой-нибудь IoC-контейнер. В крайнем случае данный паттерн так или иначе переизобретается. Просим рассказать, зачем нужен данный паттерн, какие бывают его разновидности (речь идет о инъекции зависимостей/локаторе сервисов, но отвечать почему-то начинают про инъекцию через конструктор/инъекцию через сеттер). Если кандидат знаком с конкретными реализациями, то задаем вопросы по ним (обычно спрашиваем про квалификационные аннотации в CDI или фабрику бинов в Spring Framework).
  
  
• ORM-фреймворки, JPA, JDBC. Здесь есть где развернуться. Большинство современных корпоративных приложений служат в основном для манипуляции данными в той или иной БД, поэтому владеть соответствующими инструментами необходимо. Мы используем как различные ORM, так и JDBC, причем работаем и с голым JDBC, и со Spring-JDBC. Обычно задаем вопрос: что такое ленивая загрузка и какие проблемы она создает. Здесь можно поговорить и о решении данных проблем. Вскрывается, что человек Hibernate использовал и мэпинги писал, но что такое сессия, транзакция, соединение с БД, как они связаны, разницу между присоединенными и отсоединенными от сессии объектами не понимает. Если же человек действительно понимает, как работают ORM-фреймворки, то можно поговорить о более высокоуровневых вещах, таких как прозрачное хранение, незащищенная модель предметной области (Exposed Domain Model), плюсы и минусы незащищенной модели перед сокрытием бизнес-логики за фасадом из POJO или EJB.
  
  
• JavaEE и сервера приложений. Речь идет прежде всего о том, какие задачи решают сервера приложений. Хорошо, если кандидат имеет опыт работы с конкретными промышленными серверами приложений, знает их сильные и слабые стороны. Может быть знает о проблемах в реализации той или иной технологии на конкретном сервере (например JPA на сервере приложений IBM WebSphere 7.0). Если человек говорит, что знает EJB и/или CDI, то задаем вопросы по этим технологиям. Веб-часть практически не трогаем.
  
  
• Интеграционные механизмы, веб-сервисы и JMS. Данные вопросы обусловлены уже конкретикой нашей работы. Мы готовы обучать человека разработке на сервисных шинах предприятия, если он обладает хотя бы базовым пониманием интеграционных механизмов. Спрашиваем в основном о SOAP, WSDL, MDB, просим написать несложный XPath-запрос.
  
  
• Вопросы по базам данных. Нам приходится обрабатывать большие объемы данных и решать проблемы с высокой нагрузкой на слой хранения. В идеале хочется, чтобы кандидат мог оптимизировать SQL-запросы, писать хранимые процедуры на PL/SQL, знал что такое индексы и какие они бывают, а так же как работают. Для меня было бы огромным плюсом, если человек осилил книгу Тома Кайта Oracle для профессионалов.

Конкретные вопросы зависят от заявленного опыта и уровня кандидата. Если человек не знает EJB, то и задавать соответствующие вопросы не за чем.

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

Специфика нашей работы требует людей, владеющих широким спектром технологий, т.к. заказчиков много и проекты весьма разные. Соответственно, важно определить не только текущий уровень знаний, но и потенциал кандидата. Для выявления потенциала мы спрашиваем у человека чему он научился за последний год, а так же какую последнюю книгу по программированию (или шире - IT) он прочитал. Результат надо сказать довольно удручающий: большинство из приходящих на собеседование книг не читают вообще, предпочитая Habrahabr. Чтож, это их выбор.

Да, мы задаем вопрос "кем вы видите себя через 5 лет". Нам это действительно важно.

А как вы собеседуете специалистов и на что в первую очередь обращаете внимание?

UPD: Иногда мы просим описать решение какой-нибудь практической задачи. Например, мы разрабатываем приложение на Java EE и нам нужно сделать следующее: пользователь заполняет форму и ее содержимое отправляется на почту. Здесь можно немного поговорить о юзабилити - а что если SMTP-сервер сильно нагружен или с ним плохая связь и письмо будет отправляться очень долго. Как правило становится понятно, что письмо нужно отправлять в другом потоке, нежели обрабатывается страница, ну или использовать асинхронные сервлеты, хотя на мой взгляд это избыточно. Далее можно поговорить и о многопоточности в целом, и об ограничениях при использовании потоков на сервере приложений (как минимум полезно спросить, понимает ли кандидат, почему не рекомендуется использовать new Thread() в управляемой среде). Если человек понимает, что здесь можно применить JMS или задействовать Work Manager'ы, то это просто замечательно. Как минимум на middle я бы его точно взял.

Понравилось сообщение - подпишитесь на блог