воскресенье, 27 апреля 2014 г.

Собеседование 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 я бы его точно взял.

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

17 комментариев:

maratische комментирует...

часто собеседую Джуниуров (ну DEV2 по нашему), приходится начинать с вопроса, что такое класс, объект и в чем между ними разница, после этого часто прощаюсь :(
студент пошел совсем плохой

Pavel Samolisov комментирует...

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

З.Ы. А может человек долго программировал на JavaScript и гуру ООП на прототипах? :)

chiffa комментирует...

Возможно не на Java-программистов, а скорее на архитекторов задаю вопросы - применение тех самых интеграционных механизмов, но последовательно, с наращиванием дополнительных условий, ограничений, функциональности. Позволяет оценить, насколько человек "некостыльно" мыслит, какую закладывает вариативность и гибкость решения.
Один из хороших вопросов - предложить методику сайзинга для SOA\BPM Suite. Тут вскрывается и знание общих механизмов, и знание платформы.
Всегда стараюсь дать вопрос вообще не по профилю - если человек занимается ETL, то вопрос, например, про особенности финансового софта. Или если занимается автоматизацией бизнес-процессов, то про серверные платформы - по разному.

В любом случае, первым смотрю на процесс рассуждения.

None none комментирует...

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

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

Pavel Samolisov комментирует...

@chiffa Спасибо за очень полезный комментарий. Дать подумать над какой-то практической задачей и посмотреть как человек ее решает (конечно делая скидку на стресс при собеседовании и тот факт, что и самим то нам такое решение пришло далеко не сразу), это на мой взгляд лучший вариант. Но перед этим все же полезно поговорить с человеком, бывает и так становится все понятно.

Вопросом про сайзинг вы меня заинтриговали. Не можете намекнуть хотя бы направление мысли, которое ожидаете от кандидата? Мы с вопросами сайзинга SOA Suite всегда обращаемся непосредственно в Oracle, у них есть программа, подбирающая параметры оборудования. Для OSB такого нет, здесь приходится разбираться самим, благо есть наработки.

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

@None none Справедливости ради, нынешние синьоры-помидоры тоже не за границей в массе своей учились. Претензии к качеству образования есть, но я бы не сказал, что оно на столько уж катастрофически низкое. Сейчас знания, полученные мною в университете, реально помогают строить сервисные шины довольно крупных предприятий. Без лишней скромности скажу, что на фоне коллег, не имеющих профильного образования, разница в уровне заметна. Свой диплом я бы точно не выбросил.

Роман Комаров комментирует...

Ну, вот, прочитал и сразу захотел у вас работать :)

Pavel Samolisov комментирует...

Если это серьезно, то напишите мне на psamolysov собака at-consulting.ru Буду благодарен, если приложите резюме.

zpetrovich комментирует...

Спасибо за статью! В Java более 8 лет. Большинство ответов на озвученные вопросы я не знаю (некогда исследованиями заниматься, постоянно работаю :( ) Очень интересно было бы увидеть список книг, в которых можно найти ответы на все эти вопросы. Заранее благодарен!!!

Pavel Samolisov комментирует...

Дал ответ на ваш вопрос.

chiffa комментирует...

@Pavel Samolisov, по сайзингу - это дело такое же, что и известный термин - "экспертное мнение". Интересен любой ход рассуждений. Конечно, хотелось бы услышать в первую очередь встречные вопросы от человека: что за система, какая модель функционирования, какие компоненты есть и как они взаимодействуют. Потом интересный момент - что человек возьмет за базис нагрузки и как остальные параметры выведет через коэффициенты, и насколько они будут обоснованы. В итоге - если человек сможет прямо на собеседовании сформировать и рассказать модель процессной или интеграционной системы - на мой взгляд, круто. Если при этом расскажет про тесты SPEC, TPC - то очень круто. Если спросит еще про профиль нагрузки, пики, сервисное окно, часовые пояса, процедуры сопровождения - даже не знаю, брать надо :-)

Но есть нюанс - это бекграунд человека. Замечал, что чем человек занимался ближе всего или в чем самый сильный скилл, туду его и ведет:
- ADF - в действия пользователей и UI
- ODI\BI - сайзинг базы, и расчет через нее. Де факто только tpc оценивается тем или иным образом.
- BPM - количество процессов
- SOA - количество интеграционных сценариев.
- Java - тут обычно широкий взгляд.

Ну и в конце, всегда можно пообщаться про детали в платформе - оптимизацию внутренних вызовов, потокобезопасность BPM в multiinstance, оптимизация XSLT\XQ итд.

Про толерантность - можно ходить на собеседования вдвоем :-) и учитывать те самые стрессы. Плюс собеседование, все-таки, это идеальная "бумажное" окружение, без ограничений реальности.

Прошу прощения за многословность.

Pavel Samolisov комментирует...

@chiffa огромное спасибо за ответ и наблюдения! Думаю, я бы так подробно про масштабирование рассказать не смог, есть чему поучиться.

ilyas комментирует...

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

Pavel Samolisov комментирует...

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

ilyas комментирует...

Просто часто бывает, что человек все знает, но потом работает плохо.

Pavel Samolisov комментирует...

Да, как говорится надо не только убедиться, что человек может работать, но и что он будет это делать.

Dmitry Verejnikov комментирует...

Привет:) Я снимаю ролики про вопросы на собеседовании. Надеюсь будет кому полезно.
https://www.youtube.com/watch?v=Z0JMABjXnww - HashMap
https://www.youtube.com/watch?v=IyPaSUFrhaM - ArrayList LinkedList

Pavel Samolisov комментирует...

Я пропускаю эти ссылки, но в принципе ссылочный спам в моем блоге не приветствую.

Отправить комментарий

Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!