В этой статье я хочу поделиться рецептом качественного собеседования продолжительностью 1 час. При этом критерий качества исключительно практический: потратив не более часа я готов рекомендовать или не рекомендовать соискателя к найму.
Я поделюсь своим опытом набора людей «под себя» на нескольких проектах различного масштаба. То есть отбора в свою команду тех, с кем мне предстоит длительная совместная работа и за чью работу мне отвечать перед моим руководством.
Контекст
Отмечу несколько фактов, которые существенно повлияли на мои подходы к собеседованию. И тут не важно нравятся они мне или нет – просто принимаю их как данность, как контекст, в рамках которого идет работа.
Первое – время работы разработчика на одном проекте. За последние 10 лет это время сократилось с 2-3 лет до 1 года даже для разработчиков высокой квалификации. Новички же и вовсе находятся в перманентном поиске новых карьерных и зарплатных возможностей.
Второе – большой приток новичков. Агрессивная реклама онлайн курсов по программированию и хорошо налаженный конвейер «переквалификации в программисты» насытили рынок новичками.
Третье – тотальный переход в онлайн разработчиков в ИТ-сфере. Сейчас никто не ездит не только на собеседования, но даже на работу выбираемся все реже и реже.
Четвертое – устойчивый спрос на кадры в ИТ-сфере. Типовой сценарий опытного соискателя: резюме на hh открывается на три дня -> телефон, почта и мессенджеры разрываются от потока сообщений -> в течение первой недели собирается несколько офферов -> выходные на принятие решения. Всё! Никаких собеседований в несколько этапов – всё решается здесь и сейчас.
Пятое – в интернете море подборок с типовыми вопросами и ответами для собеседований. С этими вопросами очень полезно ознакомиться, чтобы их не задавать и не идти по шаблону.
Также в качестве ограничений по применению отмечу уровень соискателей: рецепты из этой статьи подойдут для мидлов и выше. С джунами подход заметно отличается – заходить приходится не от реальных кейсов на моем конкретном проекте, а от учебников. Но это отдельная история.
Приготовления
Чтобы потратить на собеседования меньше времени, но получить хороший результат нужно многое успеть сделать до их начала. Часть про взаимодействие с HR и ресурсным менеджером я опускаю и опишу лишь свою работу перед интервью.
Прежде всего нужно очень хорошо вникнуть в свой проект как с бизнесовой, так и с технической точек зрения и понять его перспективы в обоих перечисленных смыслах. Если после глубокого погружения я сам не убегаю обновлять резюме и даже готов заманивать на него других людей, то перехожу к следующей фазе – заготовки для собеседований.
Заготовки понадобятся следующие:
Вопросы и задачки, позволяющие выявить наличие нужных скилов (назовем их «тесты»)
Ловушки для выявления нежелательных качеств у кандидата (пусть это так и будут – «ловушки»)
Продающие фразы, выделяющие мой проект среди десятков других (их назовем «продающими»)
Фразы, помогающие нетоксично и деликатно прервать интервью сразу, как только кандидат провалился (эти назовем «прерыватели»)
И при этом все собеседование должно уложиться в час, не более. На это две причины: мое время стоит дорого, а у соискателя телефон разрывается от других звонков с предложениями о работе.
Значит нужно хорошо себе представлять сценарий типового собеседования и стараться выдерживать тайминги. Вот, например:
знакомство – 3-5 минут
техническая часть – 40 минут
проверка софт-скилов – 5 минут
вопросы кандидата – 10 минут
Все перечисленные заготовки (кроме «прерывателей») я распределяю по всей дистанции. Распределение конечно не будет равномерным и подчинено логике беседы. Еще добавляю немного импровизации – полезно в общении с реальными людьми, каждый из которых интересен по-своему. А вот «прерыватели» держу на всякий случай и пускаю в ход, только если для меня очевидно несоответствие кандидата моим запросам.
О чем говорю на каждом из этапов встречи расскажу позднее. Сейчас поделюсь заготовками.
Знакомство
Каждое интервью – это встреча с новым человеком, у которого есть какой-то интересный опыт за плечами, свой склад характера. Это потенциальный член команды. Чтобы повысить КПД нужно помочь соискателю раскрыться, а для этого нужно установить контакт и обоим настроиться на позитивный лад.
О чем говорить, когда у большинства технарей коммуникативные навыки развиты слабо? Тему можно заранее поискать в резюме. Если недавно закончил ВУЗ или курсы – какое осталось впечатление? Что было самым интересным, а что скучным или бесполезным? Может быть, увидите пересечения по местам работы и вдруг есть общие знакомые.
Если есть опыт фриланса мне всегда интересно знать, что побудило идти работать по найму. Не пугает ли перспектива «работать на дядю»? И вообще, обязательно интересуюсь почему человек в поиске и какой работы для себя ищет.
Тут сразу двойная цель: и кандидату помочь расслабиться-разговориться, и темы для будущей беседы можно найти неожиданные. Ведь это реальный человек, а значит не надо идти строго по шаблону и я стараюсь проявлять гибкость.
Заготовки, выявляющие наличие требуемого опыта
Идеального кандидата не существует, поэтому даже не стану тратить время на его поиск.
Будем реалистами: с какими типовыми задачами придется сталкиваться на проекте и что кандидат должен знать, чтобы с порога начать запиливать задачки?
Возьмем типовой современный проект: Java 11, Spring Boot, Liquibase, PostgreSQL, Kafka, REST, микросервисы, Docker.
А теперь проранжирую этот список в порядке убывания важности навыков: Java 11, Spring Boot, PostgreSQL, REST, микросервисы, Kafka, Liquibase, Docker. И на все это у меня 40 минут… При этом только первые два пункта окажут принципиальное влияние на скорость выполнения задач, на мои затраты времени на ревью и последующие исправления. Вот про них-то и буду расспрашивать. Причем из-за ограничений по времени – только про самые важные для моего проекта кейсы, подходы и конструкции. Ни про GC, ни про многопоточность, ни сортировку пузырьком – разговоры об этом не будут показательны, а значит это пустая трата времени.
У меня есть список любимых вопросов и большинство из них сугубо прикладного характера по типовым кейсам. Хорошо иметь какие-то примеры кода и попросить их прокомментировать. Опять-таки – никаких академических премудростей, все вокруг задач моего конкретного проекта!
И раз я пишу о кандидатах уровня мидл и выше, то я начинаю с более общего вопроса и далее перехожу к подробностям:
«В REST сервис требуется добавить ручку, по которой бонусные баллы авторизованного пользователя сконвертируются по заданному курсу в рубли и зачислятся на его счет. Как бы Вы реализовали эту задачу? Как распилите на слои, где примените транзакции?»
Здесь я подсветил слово «ручка» потому, что это сленг, незнание которого намекает на отсутствие реального опыта. Но не только маркер, это проверка насколько мы с кандидатом говорим на одном языке. Дальше сленга будет больше и кто не в теме может заскучать, но мне хотелось быть более конкретным и показать реальные цепочки вопросов, а не очередного сферического коня.
Итак, в ответ соискатель начинает что-то рассказывать, я задаю попутные вопросы. Своими вопросами я подкидываю ему уже более конкретные «тесты» (см. терминологию выше).
Например, когда речь зайдет о транзакциях поинтересуюсь, что дает нам @Transactional и где ее лучше поставить? Как ее модифицировать, чтобы транзакция откатилась по checked-исключению? А если один transactional-метод сервиса вызовет другой transactional-метод этого же сервиса, то что будет в этом случае с транзакциями? Тут плавно перешли к пониманию механизма проксирования в спринге и так далее, и так далее…
Очень полезным считаю затрагивать вопросы производительности и тут снова космос тем, на которые интересно поговорить. Но не про сравнение LinkedList и ArrayList – не будем идти по традиционному списку «100 вопросов на собеседовании».
Например: как можно реализовать кеширование в спринге? Далее, стоит ли хранить в кэше мутабельные объекты? Как сделать глубокую копию объекта? Вызывается ли конструктор при десериализации? Кстати, чем десериализация отличается от анмаршаллинга?
Или вот еще: а если для повышения производительности что-то прихранивать в бинах скоупа Request? А может сразу скоуп Session? А если обратиться к реквестовому бину вне контектса запроса?
А что, если нам проблему недостаточной производительности решить переходом на асинхронное взаимодействие? Тут можно перейти к разговорам про Kafka и Docker (на локальной машине ведь кафку в контейнере поднимаете?)
И таких цепочек по вполне реальным кейсам очень много. А еще ведь надо коснуться вопросов тестирования. Пол часа пролетят незаметно и на обсуждение алгоритмической сложности получения значения из мапы времени просто не останется.
Теперь нужно еще по софт-скилам пробежаться. Конечно, какие-то коммуникативные навыки выявляются в процессе всего собеседования. Но не лишним будет уточнить, какими каналами коммуникации кандидат привык пользоваться, как он предпочитает общаться с коллегами в эпоху удаленки. Умеет ли соискатель общаться посредством Jira или другого трекера, который используется на проекте?
Но есть и другие вопросы к потенциальному разработчику в мою команду. Например, как Вы выстраивает свой день? Как подходите к решению задач? А что, если задача трудная? В какой момент начинаете бить в набат, если не можете решить задачу? Как вообще предпочитаете решать рабочие проблемы?
Есть вопросы, которые можно задать прямо и рассчитывать на честный ответ, а есть такие, на которые ждать честного ответа наивно. Я предпочитаю прибегать к техникам проективного интервью – очень полезная практика для собеседователя. Эти же техники использую для расстановки «ловушек» (об этом далее).
Например, вопросы про то, как кандидат преодолевает прокрастинацию, лучше задать в проективном стиле.
Ловушки для выявления нежелательных качеств у кандидата
Для начала надо понять, какие качества для нежелательны в команде. Их не так много и сразу раздам им псевдонимы: тусовщик, ждун, потеряшка.
Тусовщик всегда на связи. Он присутствует на всех демо всех команд. Он посещает все митапы, и конференции. Ни одна движуха не пройдет мимо настоящего тусовщика. Он в курсе всех новых практик, фрейморков и библиотек и постоянно стремится применить их на боевом проекте. Само по себе это не плохо и с такими людьми интересно общаться, но я предпочитаю не брать их в команду. Просто потому, что они не успевают созидать.
Выявить тусовщика довольно легко – просто спросите на каких конференциях он был за последний год, и он с гордостью вывалит внушительный перечень.
Со ждуном проблема в том, что он всего ждет: когда архитектор все подробно опишет в Confluence, когда аналитики сформулируют все постановки по всем задачам, когда кто-то ответит на какое-то письмо, когда коллега закончит свою задачу (ведь потенциально могут быть конфликты при мердже).
Распознать ждуна уже сложнее. У него могут проскакивать фразы типа «мы планировали, но не решились», «я хотел попробовать, но не было случая» и так далее. Но лучше предложить кейс: «Вы по своей текущей задаче в Jira запросили пояснений/уточнений у аналитика. Что дальше?». Кто-то продублирует запрос звонком по всем месенджерам и будет регулярно пушить, чтобы двигать задачу. А параллельно еще возьмет другую задачу. И только ждун будет ждать и периодически рефрешить страничку.
Но тут есть сложность – ждун знает правильный ответ на этот вопрос. И тогда можно докинуть проективно: «По опыту разработчики не любят звонить и предпочитают более медленные каналы связи. Почему, как считаете?». И тут можно надеяться услышать что-то более достоверное.
Идем дальше – расставляем ловушки на потеряшку. У него может быть много причин постоянно отвлекаться от работы: делает ремонт своими руками, дети не ходят в садик/школу, насыщенная прочими интересами жизнь.
Конечно, если спросить прямо: «сколько времени на удаленке Вы реально будете уделять моему проекту?», то скорее всего получите ответ типа: «8-10 часов, но в выходные и отпуске, возможно, чуть меньше». Переформулируем вопрос: «Как, по вашему мнению, переход на удаленку сказался на качестве кода и скорости закрытия задач?» А потом вдогонку: «А почему, как Вы считаете?»
Из ответов на такие вопросы уже будет некоторый шанс получить представление о кандидате.
Кроме того, просите включать видео на время интервью – получите представление о рабочем месте и сможете сделать предположения о том, насколько удобно на нем работать целый день.
Далее, можно поинтересоваться о хобби, как любит проводить выходные. Но это если установился хороший контакт и подвернулся случай задать вопрос непринужденно.
Прерыватели
Мое время стоит дорого и к кандидату нужно относиться уважительно. Поэтому если я отчетливо вижу, что человек не принесет мне пользу на проекте – нужно набраться мужества и решительно, но деликатно прервать взаимные страдания.
У меня есть несколько заготовок на такой случай. Главное требование – деликатно, нетоксично и без обобщений. То есть я бы не стал говорить, что: «Вы плохой разработчик!» Разработчик-то он может и хороший, но в другой области, которая мне сейчас не интересна.
Например: «Мне на проекте требуются разработчик с более уверенными знаниями Spring (web, в частности). Я не готов пригласить Вас в свою команду. Извините. Предлагаю на этом закончить».
Вопросы кандидата
Это еще один очень важный источник информации. Если соискатель ни о чем не спрашивает – ему все равно где работать? Если спрашивает, то о чем именно?
Да, к концу собеседования кандидат может немного устать или мечтать об уборной и скомкать концовку по понятным физиологическим причинам. Но если я потратил без малого час и до сих пор не пустил в ход «прерыватели», то я рассматриваю кандидата всерьез, а значит должен максимально помочь ему все понять про мой проект и сделать правильный выбор.
Своего работодателя и проект я рекламирую понемногу в течение всего интервью, но на завершающей стадии делаю это особенно активно и открыто. После каждого собеседования (даже прерванного) соискатель должен уходить с желанием работать на моем проекте и со мной лично. Это важно, чтобы не загрустить, когда делаешь оффер за оффером, но снова и снова получаешь «у меня есть более интересное предложение…».
На этот случай у меня есть специальные заготовки. Но это все очень специфично для кандидата: с его предыдущим опытом и ожиданиями от нового места. Что он там ответил в начале интервью на вопрос о причинах поиска? Если разработчик уходит из крупного банка и устал об бюрократии, то обратите внимание на возможность на уровне команды принимать множество решений по процессам; расскажите, как мало формальностей у вас сейчас. Если работал на маленьком проекте по методологии ХХП (хренак-хренак-в-продакш), то обратите внимание на свой опыт и зрелость команды.
Тут главное не «продать любой ценой», а помочь кандидату увидеть выгоды перехода в мою команду и на мой проект. Если соврать, то кандидат уйдет (убежит) еще на испытательном сроке, а по количеству потерянного времени это хуже, чем если бы он вовсе не приходил
Когда все вопросы заданы и прозвучали ответы, я завершаю интервью позитивно. «Было приятно познакомиться, Николай! Спасибо за уделенное время! Наш HR Мария вернется с обратной связью не позднее послезавтра».
Тут есть два момента. В течение интервью я периодически обращаюсь к кандидату по имени. Это подчеркнет уважение к нему: не просто очередной соискатель #100500, а интересный кандидат. И всегда через HR даю обратную связь – это вежливость (а IT-мир очень тесен).
Заключение
Очень много аспектов подготовки и проведения собеседования осталось за рамками статьи, но не было цели объять необъятное. Надеюсь, сумел достичь главной цели – поделиться конкретными рецептами, которые можно применять на практике. Прошу комментировать и задавать вопросы – для меня это очень ценная обратная связь.
UPD
Совсем забыл упомянуть одно очень нежелательное качество соискателя – токсичность.
К сожалению, бывает так, что человек является хорошим спецом, но источает столько негатива, что вреда от его участия в проекте получается больше, чем пользы.
Распознать токсичного человека можно, например, по тому, как он описывает свой прежний опыт – он легко и с удовольствием скатывается в смакование негативных сторон, а позитивного вроде и не замечает.
Можно попросить кандидата описать самый примечательный опыт на текущем месте работы: как положительный, так и отрицательный. Относительно распространенный вопрос на интервью, ответ на который полезен сразу в двух смыслах.
Во-первых, это дает представление о том, насколько я с кандидатом одинаково понимаю «что такое хорошо и что такое плохо».
Во-вторых, невербальная составляющая ответа может показать уровень токсичности. Конечно, это требует от интервьюера достаточно развитого эмоционального интеллекта, что традиционно узкое место у айтишников. Но в общем случае большинство соискателей предпочтет не «выносить сор из избы» и отделается общими фразами про негативный опыт. Токсичный же не упустит случая «брызнуть ядом» – это будет и в мимике, и в интонациях.
Рассказ о положительном опыте полезен и тут – это некий эталон эмоциональности. Ведь есть просто эмоционально яркие люди, которые довольно феерично раскрасят весь свой рассказ
