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

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

У меня в арсенале есть несколько проверенных видов проведения технических интервью backend Java разработчиков:

1. Вопросы-ответы.

2. Задачи на рефакторинг.

3. Лайв кодинг.

4. Соискатель проводит интервью интервьюеру… (доступен только сеньорам, лидам, архитекторам).

Все 4 релевантны и раскрывают примерно одно и то же. Зачем такой выбор? Делать нечего Есть необходимость дать соискателю самый удобный вид прохождения интервью с целью максимального раскрытия его опыта, знаний, коммуникативных навыков (софт скилы проверяются минимально). Что оцениваю я: сколько нужно вложить в кандидата до его возможности выполнять наши задачи, что он может привнести в команду/проект и как впишется в команду. Что хочу донести: с кем соискателю нужно будет работать, с какими технологиями, какие задачи решать. Подчеркну, что плохих кандидатов и сотрудников не бывает! Бывает наверное совпадение по стеку, технологиям, команде… это точно проблемы микроскопа, если им забивают гвозди.

Немного расскажу про первые 3 вида интервью:

1. Очень давно я вычеркнул вопросы-ответы из используемых мной видов интервью, так как это скучно, неэффективно и вообще можно выучить все типичные вопросы. Где-то на гитхабе даже есть репозитории про вот эти ООП и паттерны. Ко всему этому очень часто мне самому приходилось проходить интервью в таком формате и зачастую было легкое ощущение (а иногда уверенность), что меня пытали… Ну прям такой допрос, не хватало только терморектальногокриптоанализатора и лампы в лицо. Когда это все происходит еще и кучкой из 6-ти человек, то с трудом вспоминаешь как HashMap уворачивается от алгоритмической атаки на хэштейбл или какое там дерево в TreeSet.  Так же меня не устраивало то, что интервьюеры не хотели вести диалог и отвечать на встречные вопросы, парируя, что времени не хватит (один фидбэк был: начал проводить интервью в обратную сторону, сбивал интервьюера с толку, эм, их было вообще-то 3, видать бумажка была одна). Через время я проходил интервью у Сергея и Антона из компании КазаньЭкспресс, на котором мы больше общались, но я заметил, как они задают вопросы, как слушают, ждут сами вопросов, вступают в обсуждение решений, и да, почувствовал, что вопросы из их продакшена, следовательно, таким образом они понимают: будет ли решать их задачи соискатель.

2. Рефакторинг я использую с разрешения Антона. Он не проводил мне полноценное интервью, просто скинул задачи, а вот кто-то юзает их без согласования с ним))). Задачи на ванильной Java, но с несколькими уровнями сложности и понимания, т.е. в каждой задаче есть несколько уровней проблем, которые в зависимости от опыта и знаний кандидата будут решены по-разному. Там и чистый код, и чистая архитектура, но на практике, а не “расскажи мне про L”. Правда, я добавляю данный подход еще вопросами по Spring, базам данных  и ряду других технологий из нашего стека, но уже совсем мало. Иногда подмешиваю в сам рефач что-то типа: а если у тебя есть Spring, то как?

3. Лайв кодинг спёр у Александра из одного банка (коллега пожелал остаться анонимом). Суть: решаем приближенную к практики бизнес задачу, интервьювер накидывает требования, смотрит, как соискатель решает её, как может мыслить локально в коде и архитектурно, как решает проблемы именно руками, то есть без разницы знает соискатель или нет названия микросервисных паттернов, главное как он мыслит и может решить возникающие проблемы. Конечно, вариативность тут немного меньше, чем при вопросах и ответах, но можно накидывать на разные уровни разные кейсы: где-то на паттерны, где-то на блокировки. Я немного приспособил такой подход под свои нужны и обязательно беру для разработки все тот же Spring, накидываю кейсы, которые можно решить с помощью его возможностей, но придерживаясь оригинального мейнлайна с сохранением идеи.

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

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

Как строится интервью:

1. Рассказ о компании.

2. Рассказ о стеке, с которым предстоит работать.

3. Какие бизнес задачи предстоит решать.

4. Рассказ соискателя о себе.

5. Непосредственно само интервью соискателем интервьювера.

6. Завершение интервью.

Скелет простой, но дьявол кроется в мелочах: на втором пункте соискатель понимает, с чем ему предстоит работать: какие версии фреймворков/хранилищ данных/оркестраторов (или без них) и так далее, то есть уже на этом этапе соискатель может примерно понять, какие вопросы лучше задавать, так сказать, какие вопросы ближе к теме.

Самая интересная часть, конечно же, - само интервью, и тут интервьюеру нужно:

1. Быть готовым к разным вопросам.

2. Задавать контр вопросы в тему вопроса соискателя.

3. Уметь признавать, что сам интервьюер не знает чего-то, и просить пояснения.

4. Пытаться плавно вывести в нужное русло интервью, если разговор пошел вообще не по теме.

Обычно первые вопросы соискателя - те, которые вызвали зуд и раздражение на прошлых интервью ему когда-то задавали на предыдущих интервью в других компаниях. Да, тут начинается и многопоточность, и сборка мусора, и различные пазлеры (типа: как без filter в стриме отфильтровать значения) …  

List.of(1,2,3,4,5,6,7,8).stream()
.flatMap(h -> h % 2 ==0 ? Stream.empty() : Stream.of(h))
.collect(Collectors.toList())

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

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

Далее вопросы по стеку могут закончиться, и соискатель начинает задавать вопросы вне стека технологий: про оркестрацию, администрирование линукс, бэкапы баз данных, как жить в современном eventual consistency мире, по софт-скилам и так далее. Этими вопросами соискатель показывает свой кругозор.

На этом вопросы могут закончиться, а могут продолжаться, но примерная классификация вопросов и что можно понять по ним о соискателе, думаю, ясна.

Главное - дополнительно подыгрывать соискателю и мотивировать его на объяснение интервьюеру, почему он ответил неверно, иначе можно уйти в вариант проведения интервью в режиме допроса или улететь в высшие материи. Также нужно следить за таймингом и максимально ясно и коротко отвечать на вопросы.

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

Конечно, можно возразить: как можно узнать, разбирается ли соискатель достаточно в том, что нужно будет для работы? Но возникает встречный вопрос: а раскрывает ли любое другое интервью все достаточно хорошо? Если все интервью прошло в решении задачи уравновешивания скобок разными способами, или потрындели об эфемерной архитектуре, а нам, допустим, нужен человек, чтобы бизнес задачи кодить, то в нашей команде, в позиции, на которую соискатель претендует, он может чувствовать себя не очень комфортно, либо он просто слабо разбирается в том, что используется у нас для работы. В любом случае это мисмэтч.

Можно спорить бесконечно, какой вариант проведения интервью самый лучший, но, конечно же, каждому свое, и серебряная пуля - она такая… точнее ее нет.

Возможно, данная статья поможет кому-то применить данный подход и найти отличного сотрудника. Я буду этому рад!