В этой статье я хочу поделиться рецептом качественного собеседования продолжительностью 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
Совсем забыл упомянуть одно очень нежелательное качество соискателя – токсичность.
К сожалению, бывает так, что человек является хорошим спецом, но источает столько негатива, что вреда от его участия в проекте получается больше, чем пользы.
Распознать токсичного человека можно, например, по тому, как он описывает свой прежний опыт – он легко и с удовольствием скатывается в смакование негативных сторон, а позитивного вроде и не замечает.
Можно попросить кандидата описать самый примечательный опыт на текущем месте работы: как положительный, так и отрицательный. Относительно распространенный вопрос на интервью, ответ на который полезен сразу в двух смыслах.
Во-первых, это дает представление о том, насколько я с кандидатом одинаково понимаю «что такое хорошо и что такое плохо».
Во-вторых, невербальная составляющая ответа может показать уровень токсичности. Конечно, это требует от интервьюера достаточно развитого эмоционального интеллекта, что традиционно узкое место у айтишников. Но в общем случае большинство соискателей предпочтет не «выносить сор из избы» и отделается общими фразами про негативный опыт. Токсичный же не упустит случая «брызнуть ядом» – это будет и в мимике, и в интонациях.
Рассказ о положительном опыте полезен и тут – это некий эталон эмоциональности. Ведь есть просто эмоционально яркие люди, которые довольно феерично раскрасят весь свой рассказ
Комментарии (55)
VYudachev
06.11.2021 14:34+13то скорее всего получите ответ типа: «8-10 часов, но в выходные и отпуске, возможно, чуть меньше»
Не баян, а классика
Время — 18. 00, все сотрудники сидят трудятся. Один из сотрудников выключает компьютер, одевает пиджак, берет портфель и уходит. Все провожают его неодобрительным взглядом.
Следующий день. В 18. 00 тот же сотрудник выключает компьютер, одевает пиджак, берет портфель и уходит. Все продолжают работать и начинают недовольно шептаться.
Следующий день. В 18. 00 тот же сотрудник выключает компьютер, одевает пиджак, берет портфель и тут к нему подлетает коллега. — Вася, как тебе не стыдно, мы сидим работаем, конец квартала, столько работы, нам тоже хочется вовремя домой а ты такой единоличник... — Ребята, да я вообще в ОТПУСКЕ!!!
Сначала подумал, что какая-то опечатка, но если автор искренне считает, что насыщенная прочими интересами жизнь не совместима с программированием, то, видимо, нет.
Zheltov Автор
06.11.2021 14:59+3Видимо мне еще есть куда расти в софт-скилах - наверное не сумел подать идею достаточно прозрачно. Фокус как раз в том, что есть категория вопросов, на которые отвечают не то, что думают, а то, что считают правильным ответом. И тут нужно быть более изобретательным. По моему опыту проективные интервью - это очень полезная техника, которой нужно уметь владеть.
Что касается личного времени, то я очень дорожу своим и уважаю в каждом право ни личную жизнь, на хобби и т.п.
dopusteam
06.11.2021 15:11+13Здесь я подсветил слово «ручка» потому, что это сленг, незнание которого намекает на отсутствие реального опыта
Вообще, нет
По моему опыту, этот термин используется не так уж и часто, несмотря на 10+ лет опыта, встречал скорее в отдельных командах
Достаточно опрометчиво поступаете
VYudachev
06.11.2021 15:47+6Вот да, если злоупотреблять такими словечками, можно вообще скатиться в "Бревно на спутнике макаку чешет".
Zheltov Автор
06.11.2021 18:02-4@dopusteam, удовлетворите любопытство пожалуйста, а как Вы называете эндпоинты? Я имею в виду в повседневности, когда с коллегами что-то обсуждаете.
YourChief
06.11.2021 18:49+6Роут, эндпоинт. Ручкой обычно называют крутилку в настройках, опцию конфигурации или состояния, какой-то параметр - по аналогии с подстроечной ручкой на радиоаппаратуре. Но это сленговый термин, истинное значение которого, похоже, вам не знакомо. Из чего я делаю вывод, что у Вас отсутствует реальный опыт.
Zheltov Автор
06.11.2021 19:59-7Вот тут есть некоторое отличие в степени категоричности: для меня незнание сленга лишь "намекает", а Вы "делаете вывод". Если появились намеки, сигналы и сомнения, то можно задержаться на вопросе чуть дольше и прояснить.
KGeist
06.11.2021 20:06+9Мне, наоборот, использование термина "ручка" вместо более популярных аналогов намекает на то, что человек работал за всю карьеру примерно в одной компании (кто-то это рассматривает как "мало опыта") и поэтому даже не подозревает, что его могут не понять.
K36
07.11.2021 13:07Handler
Сначала подумал, что "ручка" это такой способ подловить кандидата на том, что он не знает, как правильно называть обработчики. Оказывается, вы реально так называете, ужас )
KGeist
06.11.2021 19:32+10Про "ручку" впервые услышал пару лет назад от представителей Яндекса, и до сих пор режет слух. По-моему, это пошло от них, но не распространено повсеместно (в комментариях с докладов Яндекса часто можно увидеть вопросы вроде "про какие ручки он говорит"?). Обычно же эндпойнт, роут, я сам предпочитаю называть API-метод или REST-метод.
KGeist
06.11.2021 19:50+2Вот пример непонимания: https://habr.com/ru/company/yandex/blog/489048/comments/#comment_21316610
Zheltov Автор
06.11.2021 20:00-11Роут - это про что-то типа Camel скорее. А термин "ручка" значительно более древний, чем пара лет. И по моему опыту он более распространен. Однако повторюсь, это всего лишь намек - ничего фатального из этого не следует.
KGeist
06.11.2021 20:20+1Не спорю, что термин более древний, чем пара лет -- просто я до этого особо не обращал внимание.
Вот ещё пример:
https://habr.com/ru/company/wrike/blog/475558/#comment_20878414
Опыт опыту рознь :)
Insolita
06.11.2021 23:38+6В первый раз услышала такое название endpoint. Ну я правда в Российских компаниях давно не работала. Так что очень сомнительный критерий
ChePeter
06.11.2021 17:59+2А как Вы тестируете тех, кто определяет, что «В REST сервис требуется добавить ручку" ?
dimskiy
07.11.2021 00:03Очень толково! Лично мне всегда нравились собесы, где интервьювер не занимается раздражающим допросом - и сам стараюсь практиковать именно такой стиль. Еще понравилась идея прерывателей и ранжирования техчасти по приоритетам, без «галопом по европам». В общем, нашел для себя над чем задуматься - спасибо вам за это!
trak
07.11.2021 00:10+8Здесь я подсветил слово «ручка» потому, что это сленг, незнание которого намекает на отсутствие реального опыта
тошнит от этих ручек и прочих вульгарностей. есть нормальный термин для этого.
andreyverbin
07.11.2021 11:01Какой? Я знаю кучу англицизмов, с которыми автокорректор телефона категорически не согласен, и ни одного нормального слова для обозначения API endpoint.
JustDont
07.11.2021 13:02+2От того, что вы замените англицизм взятым довольно таки "от балды" неанглицизмом — кому должно стать лучше, и почему?
KGeist
07.11.2021 16:52+2Всё-таки англицизм хорош тем, что при чтении литературы на английском проще, когда на обоих языках примерно один термин, проще ориентироваться.
andreyverbin
07.11.2021 18:38-1Мне станет лучше от того, что автокорректор телефона перестанет мне мешать. Мелочь, а приятно.
Zheltov Автор
07.11.2021 19:24Ну почему же "от балды"? Это слово обычно употребляется в словосочетании "дернуть ручку", а оно порождает довольно понятный ассоциативный ряд.
Endpoint - хороший вариант, но немного длинный и менее удобный для произношения. Впрочем это вкусовщина.
А вот роут мне для этого случая не нравится после apache camel - совершенно другие ассоциации.
Вариант хэндлера принять проще, но он уж больно общий: этим словом и message driven и event driven подходы можно окрестить. И даже exception handler - тоже хэндлер. Не передает оно специфики.
В этом плане замечание @YourChief понятно (про крутилку настроек). Ассоциация понятна. Но тут просто другой опыт.
JustDont
08.11.2021 01:55Ну потому что от балды. Думаю, вы сами понимаете, сколько других слов в словосочетании "дернуть X" вам даст приемлемо применимый к ситуации ассоциативный ряд.
Если мы говорим именно про код, обрабатывающий некий запрос к вебсерверу по некоторому адресу — то это таки эндпоинт. Это однозначно понимают и бэки, и фронты, и русскоязычные разработчики, и англоязычные. Сами по себе handlers (из чего пошла вами любимая русификация) — они в общем-то далеко не везде так называются.Zheltov Автор
08.11.2021 09:26Спасибо, @JustDont, за оживленную дискуссию по этому поводу.
Уж не знаю видна ли вам вся ироничность этого холивара, но в том же абзаце, который вызвал такой насыщенный отклик, есть фраза:
Но не только маркер, это проверка насколько мы с кандидатом говорим на одном языке.
Если Вам не нравится терминология на проекте, значит не стоит туда идти. И это отлично, что все прояснилось на собесе - меньше разочарований. А значит слово достигло своей цели: помогло принять решение (в данном случае кандидату)
Zheltov Автор
07.11.2021 17:49-1Какой неожиданно бурный отклик вызвало ничем непримечательное слово "ручка" :)
Спасибо за обратную связь, коллеги, пусть и на неожиданном месте!
gochaorg
07.11.2021 20:33+1А мне вот вообще кажется идея узнать за 60 минут порочна.
За это время в лучшем случае я за это время составить свое/субъективное мнение и не факт что оно будет верным, другой человек спросить кандидата другие вопросы и его мнение будет отличаться от моего... Кто тогда прав будет?
Т.е. первый вопрос, а как вы проверяете что ваши методики проверки знаний работают корректно?
Второй вопрос - стек: а что, вы действительно считаете что есть только Spring boot? И знание его ньюансов так важно? Ну вот в качестве примеров транзакции например почему не спросить, чем именно отличается уровень транзакции serializable от repeatable read, и как это реализовано в бд?
Так же про более базовые вещи, я например не вижу смысла спрашивать за rest api endpoint , если человек не знает разницу между UDP/TCP/HTTP
Т.е. у меня есть такое и убеждение (которое может быть не верно) что базовые знания важны, а фреймворки могут меняться со временем, базовые же реже меняются
Zheltov Автор
07.11.2021 21:14+1За 60 минут конечно ничего толком не понять, но большего мне не даст рынок труда! Будет понятно только если кандидат полный ноль. В остальных же случаях - это конечно только домыслы и предположения, основанные на своем опыте. Но разве это значит, что нужно сложить руки и положиться на удачу? На мой взгляд - нет. Есть способы, повышающие достоверность "кофейной гущи" и своим набором ингредиентов я тут поделился.
У кого-то принципиально иной опыт и набор ингредиентов будет другим. Все специфично.
Мне бы очень о многом хотелось поговорить с кандидатом, но у меня всего лишь час. А все последние проекты у меня сугубо прикладные. Поэтому я фокусируюсь на вопросах, которые позволят мне понять сможет ли он мне "с порога" начать запиливать мои реальные прикладные таски. Я и по java core конечно тоже спрашиваю, просто цепочку вопросов начинаю раскручивать не с этого.
Кстати, в статье были разные примеры. Создание иммутабельных объектов, например. А от спринговых бинов реквестового скоупа на ThreadLocal можно перейти. С синглтонов - на double check locking и на reordering в JMM. Главное вести беседу органично и вокруг того, что мне интересно от кандидата в работе.
Caraul
08.11.2021 21:42За последние 10 лет это время сократилось с 2-3 лет до 1 года даже для разработчиков высокой квалификации. Новички же и вовсе находятся в перманентном поиске новых карьерных и зарплатных возможностей.
Это, конечно, беда. Какая тут квалификация, если получаются уже не разработчики, а просто исполнители, причем четко поставленных задач. Проекта не знают (и не успеют узнать), свое предложить не могут - пришли, задание получили, выполнили, см. пункт 1. Точно ли имеют смысл какие-то софт-скиллы, если через год этого человека тут уже не будет? Не лучше ли делать упор на технические знания, чтобы новичок сразу садился и пилил? Мы тут сами с наймом мучаемся, уже не знаем толком, кого искать.
Zheltov Автор
09.11.2021 07:08+1Спасибо за вопрос, @Caraul! Вы мне им прекрасную идею для размышлений подкинули - почему люди с развитыми софт-скилами задерживаются все-таки подольше (ну или мне так показалось).
Из того, что требуется непосредственно в работе: допытаться от аналитиков, от бизнеса, от архитектуры чего же именно те хотят? Пинговать, пушить, задавать правильные вопросы, фиксировать уточнения постановки в трекере и т.д.
Далее, уметь отстоять свои интересы. Если что-то не удобно, то прийти на ретро и объяснить команде свою позицию и быть убедительным, чтобы тебя поняли и исправили процессы внутрикомандные (например, подход к ревью или написанию тестов). Если мало денег - прийти и убедить их повысить, а не сразу обновлять резюме.
Еще - уметь говорить нет. Например, когда тебе пишут в нерабочее время и просят срочно-срочно.
Словом, столько всяких кейсов на ум приходит, что тут на еще одну статью наберется... to be continued :)
BM_MacGregor
09.11.2021 16:59Зачем этот творческий поиск и эксперименты над людьми?
Все уже давно изучено и придумано профессионалами именно в сфере найма. Как искать, кого нанимать, как удержать или как уволить? Есть масса книг по данной тематике. Там все это разобрано. И про софт-скилы и хард-скилы и вообще про все. Даже небольшой труд снимет массу вопросов.
Сэкономите себе и другим огромную кучу времени.
ermadmi78
А я вот пришел к прямо противоположному подходу к собеседованиям. Я за свою карьеру видел взлет и падение J2EE. Видел взлет Spring'a. Но, уверен, что и спринг не вечен, рано или поздно найдется фреймворк, который сместит его с пьедестала. Помню лет 20 назад всех интересовал только Oracle. Сейчас PostgreSQL. Поэтому про тонкости использования того или иного фреймворка или СУБД я вообще не спрашиваю. Все эти знания недолговечны и гуглятся за 5 минут. Пробелы в знаниях новичка выявляются за 2-3 ревью и так же быстро устраняются.
Главное, что отличает хорошего разработчика от плохого - это развитое абстрактное мышление. Умение думать, проще говоря. И здесь ничего лучше life-coding'а я для себя не нашел. Высылаю кандидату заготовку проекта, прошу открыть его в любимой IDE и пошарить экран. А дальше начинается разговор двух умных людей... Задачки, которые я предлагаю кандидату, не требуют знания экзотических алгоритмов и использования каких либо фреймворков. Я прекрасно понимаю, что для кандидата собеседование это сильный стресс, поэтому задачки не олимпиадного уровня. Но вот как следует подумать, чтобы их решить, придется. Пока этот метод ни разу меня не подвел.
Zheltov Автор
Спасибо за отзыв, Дмитрий!
Я бы не сказал, что это противоположные взгляды - они вполне могут дополнять друг друга.
И посмотреть в реальном времени, как человек рассуждает и набирает код - тоже интересная практика. Благо даже специальные онлайн-сервисы для этого есть и даже Идея для этого не обязательна.
ermadmi78
Я предпочитаю, чтобы кандидат работал именно в любимой IDE. Прежде всего для того, чтобы уменьшить уровень стресса - чтобы человек судорожно не искал, как выполнить те или иные привычные для него действия. Это во первых. А во вторых, глядя на то, как именно кандидат работает в привычной для него IDE, я получаю очень много дополнительной информации, которая помогает мне принять правильное решение. Ну и в третьих, диалог сильно упрощается, если есть возможность скомпилировать, выполнить и подебажить код. Так разработчик попадает в привычную для себя среду, и раскрывает свои лучшие способности.
И еще... Я официально разрешаю пользоваться на собеседовании гуглом... Умному кандидату это поможет не засыпаться на незнании какой нибудь досадной мелочи. А не очень умному он все равно ничем не поможет - думать за человека гугл пока не научился.
datacompboy
Как быть когда работа на рабочем оборудовании, а на личном ничего нет, или открывались последний раз пять лет назад? :)
fougasse
Подход, несомненно, крутой, но есть недостаток, что не у всех на домашнем ПК(если он вообще есть) уcтановлена и настроена IDE. С позиции условного сишника или плюсовика - CLion платный, да и не все пилят опенсорс/студенты.
Конечно, позиция не брать таких людей тоже имеет право на жизнь, и я полность на вашей стороне, что нужно разговаривать, а не устраивать допрос по спецификациям фреймворка и порядку аругментов в функциях.
ermadmi78
Если нет возможности использовать профессиональную IDE, то используем онлайн сервисы. По статистике такие проблемы возникают примерно у 1 из 8 кандидатов. Но тут сам кандидат должен четко понимать одну вещь - он сам себя ставит в невыгодное положение. Ему объективно сложнее писать код в онлайн редакторе, соответственно у его конкурентов больше шансов на успех.
fougasse
Позиция ясна. Неясно, что же делать, если на домашнем ПК(если он есть) нет IDE и окружения? Я сомневаюсь, что ради вашей компании люди готовы покупать оборудование/лицензии, а невыгодное положение банально исключит компанию из списка. Собеседование — это ведь оценка с обеих сторон.
ermadmi78
Если нет IDE код пишется в online редакторе. Я написал об этом постом выше. Наверное я как то неясно выразился.
dimoff66
Почему "умение думать" не дать кандидату на дом, если вы понимаете что для него это сильный стресс? Лив кодингом вы проверите лишь способность кандидата решать примитивные задачки в условиях сильного стресса не оптимальным путем, оставив у него неприятное ощущение от собеседования, вместо того чтобы дать задачку должного уровня, над которой кандидату будет интересно спокойно подумать, что безусловно добавит еиу симпатии к вашей компании.
dopusteam
Может открыть курсы психологической помощи программистам, которых на собеседовании просят (кто бы мог подумать!?) написать немного кода?
Откуда вообще стресс берётся, Вас там бьют что ли?
К тому же, можно заранее предупредить о лайв кодинге, чтоб кандидат заблаговременно подготовил окружение
ermadmi78
На рынке труда острый дефицит разработчиков. Если я начну давать "задания на дом", то я потеряю бОльшую часть кандидатов. Причем в эту бОльшую часть скорее всего войдут самые сильные кандидаты.
Zheltov Автор
Полностью согласен! Когда со всех сторон 100500 приглашений, утруждаться решением тестовых заданий не каждый захочет. Только если уж оооочень интересна вакансия. Ну или из чисто спортивного интереса, если задачка любопытная.
Все надо постараться понять и принять решение за час собеседования. Про то и статья.
dimoff66
Странно, то есть все эти потерянные кандидаты говорят: "Нет, не хочу это делать в спокойной обстановке, хочу лив кодинг, чтобы на меня выжидающе смотрела пара глаз интервьюеров. Меня это ух как заводит!" ? Вы потеряете кандидатов только если будете давать скучные задания на 8 часов работы. Что-то интересное на час полтора - сильные не откажутся.
ermadmi78
Абсолютное большинство кандидатов отказываются делать домашние задания (в чем я их очень хорошо понимаю). Если не верите - проведите эксперимент, предложите домашнее задание вашим кандидатам.
dimoff66
Мне не нужно верить или не верить, я много раз искал разработчиков. Все дело в задании. Те задания, которые дают большинство компаний и вправду давать не стоит. Те задания которые давал я, люди делали с удовольствием, им было интересно.
ermadmi78
По моему опыту кандидаты отказываются ещё до того, как видят задание. Просто когда озвучиваешь сам факт того, что будет задание.
nox86
Не на злобу дня, мне права интересно что вы пытаетесь узнать и доказать заставляя кандидата писать код и думать как его лучше объяснить.
Почему все вдруг кинулись на некий суррогат в виде онлайн кодинга, почему не ревью, которое наш хлеб наш?
beDenz
Просто, что бы увидеть ход мыслей кандидата. Тут даже не столь важно решит он ее или нет. И никто никого не заставляет, об этом необходимо предупреждать заранее, а кандидат может отказаться. К примеру, я предпочту лайвкодинг на 30 минут, чем тестовое на пару часов.
Буквально этим летом, проходил собеседование в одну известную российскую контору. Они, не предупредив меня, вывалили мне алгоритмическую задачу, тупо скопированную с литкода. Так я у них прямо в лоб спросил пример того как знания и умения решать такие задачи применяется в их повседневной работе, в моем случае, на фронте. Естественно, они не смогли ответит на этот вопрос. Поэтому я не стал даже пытаться решить их задачу, попрощался и закончил встречу. Никто никому ничего не должен. Но видимо они обиделись и даже обратную связь не дали, хотя там еще была теоретическая часть.
nox86
Oбсолютно с вами согласен.
Но почему лайвкодинг а не ревью (когда кандидат рассматривает заранее подготовленный PR). Последнее гораздо часть нашей профессии.
Zheltov Автор
Если я правильно помню Доктора Хауса, слушать музыку и играть музыку - разные неврологические процессы и задействуют разные области мозга :)
Даже такая инженерная задача, как написание кода, все равно предполагает выбор из нескольких относительно равноправных вариантов решения и является более творческой, чем ревью.
nox86
Мне кажется что в ревью (после него) есть место на разговор, "а что бы можно было улучшить", "а как бы Вы подошли к задаче".
А вот "Доктор Хаус" отлично применим к лайфкодинг с его несколькими одновременными процессами презентации мысленного процесса и самого мысленного процесса. Возможно, Вам комфортнее работать с людьми с таким набором качеств.
Я хочу сказаць, что лайфкодинг имеет столько же общего с реальной работой как и алгоритмические задачки. Каждое задание в какой то мере покрывает определённый тип навыков, абсолютно игнорируя, или даже подавляя другие.