Дисклеймер: в данной статье много воды, отражены мысли и опыт воспаленного мозга, потому заранее предупреждаю, что можете потерять просто свое время зря. Из java тут вообще мало и в основном все избито.
Какие виды интервью вы проходили или организовывали? Думаю, никто не будет спорить, что ни одно интервью не дает полного представления, как будет работать соискатель, потому тут я постараюсь передать идею одного из своих подходов к техническому интервью. Если интересно, велком под кат.
У меня в арсенале есть несколько проверенных видов проведения технических интервью backend Java разработчиков:
Вопросы-ответы.
Задачи на рефакторинг.
Лайв кодинг.
Соискатель проводит интервью интервьюеру… (доступен только сеньорам, лидам, архитекторам).
Все 4 релевантны и раскрывают примерно одно и то же. Зачем такой выбор? Делать нечего Есть необходимость дать соискателю самый удобный вид прохождения интервью с целью максимального раскрытия его опыта, знаний, коммуникативных навыков (софт скилы проверяются минимально). Что оцениваю я: сколько нужно вложить в кандидата до его возможности выполнять наши задачи, что он может привнести в команду/проект и как впишется в команду. Что хочу донести: с кем соискателю нужно будет работать, с какими технологиями, какие задачи решать. Подчеркну, что плохих кандидатов и сотрудников не бывает! Бывает наверное совпадение по стеку, технологиям, команде… это точно проблемы микроскопа, если им забивают гвозди.
Немного расскажу про первые 3 вида интервью:
Очень давно я вычеркнул вопросы-ответы из используемых мной видов интервью, так как это скучно, неэффективно и вообще можно выучить все типичные вопросы. Где-то на гитхабе даже есть репозитории про вот эти ООП и паттерны. Ко всему этому очень часто мне самому приходилось проходить интервью в таком формате и зачастую было легкое ощущение (а иногда уверенность), что меня пытали… Ну прям такой допрос, не хватало только терморектальногокриптоанализатора и лампы в лицо. Когда это все происходит еще и кучкой из 6-ти человек, то с трудом вспоминаешь как HashMap уворачивается от алгоритмической атаки на хэштейбл или какое там дерево в TreeSet. Так же меня не устраивало то, что интервьюеры не хотели вести диалог и отвечать на встречные вопросы, парируя, что времени не хватит (один фидбэк был: начал проводить интервью в обратную сторону, сбивал интервьюера с толку, эм, их было вообще-то 3, видать бумажка была одна). Через время я проходил интервью у Сергея и Антона из компании КазаньЭкспресс, на котором мы больше общались, но я заметил, как они задают вопросы, как слушают, ждут сами вопросов, вступают в обсуждение решений, и да, почувствовал, что вопросы из их продакшена, следовательно, таким образом они понимают: будет ли решать их задачи соискатель.
Рефакторинг я использую с разрешения Антона. Он не проводил мне полноценное интервью, просто скинул задачи, а вот кто-то юзает их без согласования с ним))). Задачи на ванильной Java, но с несколькими уровнями сложности и понимания, т.е. в каждой задаче есть несколько уровней проблем, которые в зависимости от опыта и знаний кандидата будут решены по-разному. Там и чистый код, и чистая архитектура, но на практике, а не “расскажи мне про L”. Правда, я добавляю данный подход еще вопросами по Spring, базам данных и ряду других технологий из нашего стека, но уже совсем мало. Иногда подмешиваю в сам рефач что-то типа: а если у тебя есть Spring, то как?
Лайв кодинг спёр у Александра из одного банка (коллега пожелал остаться анонимом). Суть: решаем приближенную к практики бизнес задачу, интервьювер накидывает требования, смотрит, как соискатель решает её, как может мыслить локально в коде и архитектурно, как решает проблемы именно руками, то есть без разницы знает соискатель или нет названия микросервисных паттернов, главное как он мыслит и может решить возникающие проблемы. Конечно, вариативность тут немного меньше, чем при вопросах и ответах, но можно накидывать на разные уровни разные кейсы: где-то на паттерны, где-то на блокировки. Я немного приспособил такой подход под свои нужны и обязательно беру для разработки все тот же Spring, накидываю кейсы, которые можно решить с помощью его возможностей, но придерживаясь оригинального мейнлайна с сохранением идеи.
В принципе, можно было бы и остановиться на этом, но рано или поздно мне, как ленивому казаху, надоело проводить интервью самому, но я решил, что возможно соискателям сильного уровня будет интересно меня прособеседовать, а то, кто я такой вообще, чтобы вопросы на интервью задавать?! Так и родилась идея перевернуть интервью.
Конечно, даже сильные соискатели зачастую выбирают вопросы-ответы, реже рефакторинг, еще реже лайв кодинг, ну и только несколько выбрало самый странный вариант.
Как строится интервью:
Рассказ о компании.
Рассказ о стеке, с которым предстоит работать.
Какие бизнес задачи предстоит решать.
Рассказ соискателя о себе.
Непосредственно само интервью соискателем интервьювера.
Завершение интервью.
Скелет простой, но дьявол кроется в мелочах: на втором пункте соискатель понимает, с чем ему предстоит работать: какие версии фреймворков/хранилищ данных/оркестраторов (или без них) и так далее, то есть уже на этом этапе соискатель может примерно понять, какие вопросы лучше задавать, так сказать, какие вопросы ближе к теме.
Самая интересная часть, конечно же, - само интервью, и тут интервьюеру нужно:
Быть готовым к разным вопросам.
Задавать контр вопросы в тему вопроса соискателя.
Уметь признавать, что сам интервьюер не знает чего-то, и просить пояснения.
Пытаться плавно вывести в нужное русло интервью, если разговор пошел вообще не по теме.
Обычно первые вопросы соискателя - те, которые вызвали зуд и раздражение на прошлых интервью ему когда-то задавали на предыдущих интервью в других компаниях. Да, тут начинается и многопоточность, и сборка мусора, и различные пазлеры (типа: как без 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 мире, по софт-скилам и так далее. Этими вопросами соискатель показывает свой кругозор.
На этом вопросы могут закончиться, а могут продолжаться, но примерная классификация вопросов и что можно понять по ним о соискателе, думаю, ясна.
Главное - дополнительно подыгрывать соискателю и мотивировать его на объяснение интервьюеру, почему он ответил неверно, иначе можно уйти в вариант проведения интервью в режиме допроса или улететь в высшие материи. Также нужно следить за таймингом и максимально ясно и коротко отвечать на вопросы.
Естественно, я сам могу не знать многого или вообще ничего из того, что будет спрашивать соискатель, но это и круто. Ведь если соискатель выше меня уровня и готов работать со мной, то он даст многое компании, вопрос только в том, захочет ли он сам работать с таким коллегой.
Конечно, можно возразить: как можно узнать, разбирается ли соискатель достаточно в том, что нужно будет для работы? Но возникает встречный вопрос: а раскрывает ли любое другое интервью все достаточно хорошо? Если все интервью прошло в решении задачи уравновешивания скобок разными способами, или потрындели об эфемерной архитектуре, а нам, допустим, нужен человек, чтобы бизнес задачи кодить, то в нашей команде, в позиции, на которую соискатель претендует, он может чувствовать себя не очень комфортно, либо он просто слабо разбирается в том, что используется у нас для работы. В любом случае это мисмэтч.
Можно спорить бесконечно, какой вариант проведения интервью самый лучший, но, конечно же, каждому свое, и серебряная пуля - она такая… точнее ее нет.
Возможно, данная статья поможет кому-то применить данный подход и найти отличного сотрудника. Я буду этому рад!
