В первой части статьи мы рассказали, из каких четырёх критериев состоит идеальное собеседование в бэкенд, сколько оно должно длиться, чтобы кандидату и интервьюеру было комфортно, а также немного разобрали практику, теорию и форму для фидбэка.
Во второй части подробнее рассмотрим практическую и теоретическую секции, а также то, как мы оцениваем каждую из них. Ещё покажем, какие задания даём кандидатам и как выглядит форма фидбэка. А в конце выясним, что на собеседовании может пойти не так, какие ошибки допускают интервьюеры и как кандидату себя вести, чтобы повысить свои шансы.
Итак, мы уже разобрали составляющие собеседования:
Практика — основной инструмент собеседования.
Теория — дополнительный.
Собеседование частично структурировано.
Помним про тайминг: время ограничено, кандидаты не готовы собеседоваться по восемь часов.
Должна быть единая форма фидбека.
Практическая секция проходит в онлайне, состоит из трёх этапов и длится чуть больше часа
Так выглядит реальное задание для кандидата:
Чтобы максимально сохранить рабочую обстановку для кандидата, мы не приглашаем его в офис — во время собеседования он подключается к нам в Zoom и выполняет задание, сидя в своем любимом кресле за компьютером. Работает он в привычной среде разработки — это, скорее всего, IntelliJ IDEA. У кандидата есть интервьюер, который готов помочь ему и ответить на вопросы по заданию.
Практическая секция проходит в онлайн-формате, потому что мы хотим, чтобы собеседование было валидным. Ведь если дать кандидату задание и он уйдёт делать его в офлайне, а потом пришлёт результат, будет непонятно, выполнил он его сам, попросил кого-то ещё или вообще использовал ChatGPT.
Практическая секция состоит из трёх этапов:
На первом мы проверяем, что кандидат умеет программировать, и даём ему простое задание.
На втором этапе смотрим, как он выполняет основную часть задания.
А на третьем обсуждаем результаты того, что сделал кандидат.
По времени все этапы занимают примерно час и 15 минут.
Поскольку собеседование проходит в онлайн-формате, мы можем следить и за процессом, и за результатом. Если бы кандидат взял задание на дом, мы бы увидели только результат — качество кода. А так мы понимаем, как соискатель работает со средой разработки, как уточняет требования, использует ли рефакторинги, чтобы быстрее управиться. Всё это позволяет оценить, какого уровня специалист перед нами.
Как мы оцениваем практику во время собеседования
Практика состоит из таких рубрик:
Процесс:
техническая коммуникация,
декомпозиция задачи,
работа с требованиями,
знание IDE.
Результат:
стилистика кода,
структура кода,
защитное программирование,
обработка ошибок,
рефакторинг,
результат выполнения.
Разберём два примера из процессной и результативной частей: защитное программирование и декомпозицию задач.
В первом случае нам нужно понять, знает ли кандидат, что такое защитное программирование, и как использует эту методику. Чтобы оценить навыки соискателя, у нас есть простая трёхбалльная градация: плохо, смешанно или хорошо. Может быть три варианта развития событий:
Кандидат не использует защитное программирование и не знает о нём.
Использует, но бессистемно или с ошибками.
Использует осмысленно, и критических замечаний у нас нет.
Теперь про декомпозицию задач. На собеседовании мы смотрим, как кандидат приступает к выполнению задания:
Сразу бросается его делать, при этом отвлекается на другие дела и работает несистемно.
Разбивает сложную задачу на части, но делает это не до конца. Занимается второстепенными задачами вместо важных.
Разбивает сложную задачу на подзадачи, умеет отделять главное от второстепенного и планирует работу заранее.
Третий вариант говорит о хорошем уровне подготовки программиста.
После практической части интервьюеры оценивают компетенции кандидата в специальной форме для фидбэка.
Теоретическая секция длится около получаса, содержит базовые и дополнительные рубрики
Теория состоит из трёх видов вопросов:
Вопросы на знания. Бывают закрытыми («Какие виды коллекций тебе известны?») и открытыми («Как работает ConcurrentHashMap?»). Я не очень люблю вопросы на знания, поскольку ответы можно заучить, особенно если речь про закрытые вопросы. Открытые в этом плане лучше — можно увидеть, как человек объясняет свой ответ. Но даже такие вопросы не проверяют практических навыков кандидата.
Поведенческие вопросы. Например, «Как ты предпочитаешь работать с коллекциями: в императивном или функциональном стиле? И почему?». Такие вопросы позволяют понять, какими соображениями руководствуется кандидат в своей работе. Но обычно ответ основан на прошлом опыте соискателя, а в новой ситуации он не найдёт паттерны, которые может к ней применить. Как раз для этого есть ситуационные вопросы.
Ситуационные вопросы. Например, «Какую коллекцию ты выберешь, если требуется…, и почему?». Такие вопросы позволяют проверить кандидата в ситуации, когда есть рабочая задача и нужно её решить. Эти вопросы — лучшие, но их сложнее всего придумать. Плюс, чтобы обсуждать с кандидатом такие вопросы, интервьюер должен быть высококвалифицированным.
У теоретической части есть свои особенности
У нас есть набор заранее подготовленных тем и вопросов.
Мы подстраиваемся под уровень кандидата и ход собеседования — не задаём специалистам уровня Junior вопросов для Senior и наоборот.
Если начинаем с кандидатом о чём-то говорить, развиваем эту тему и плавно переходим к другим.
Рубрики по теории у нас стандартные: базовые и дополнительные.
Базовые мы спрашиваем у всех:
Java: Objects & Types.
Java: Collections.
Java: Stream API.
Databases: Transactions.
Databases: Indexes.
Databases: SQL Queries.
Дополнительные — только для кандидатов уровня Middle и выше:
Java: Memory.
Java: Concurrency.
Network.
Architecture.
Java у нас проверяется практическим заданием, но базы данных — нет, поэтому по ним мы спрашиваем обязательно.
Как мы оцениваем теорию во время собеседования
Градация по теории одна для всех рубрик и складывается вокруг глубины понимания темы:
Ответа либо нет, либо он не релевантен. У кандидата нет понимания, как применять технологию, и он не знает базовых принципов её работы. Делает много ошибок.
Есть базовое понимание устройства технологии на уровне, позволяющем её использовать, но нет структуры в ответе.
Объяснения кандидата ясные и логичные, он знает принципы работы. При определении области применимости кандидат опирается на понимание внутреннего устройства технологии.
В конце собеседования интервьюеры, которые в нём участвовали, приходят к решению коллегиально. Это делается в форме фидбэка. Фидбэк по теории такой же, как и по практической части: есть рубрики, оценка и комментарии.
Решение мы принимаем оперативно, потому что у нас есть вся необходимая информация. После двух часов собеседования, если решение положительное, мы сразу оформляем кандидату оффер.
Что может пойти не так во время собеседования
Есть человеческий фактор и разные виды искажений:
Эффект контраста. Когда приходят сначала сильные кандидаты, потом немного слабее, и последние кажутся нам откровенно слабыми.
Эффект ореола. Когда интервьюер задаёт вопрос по архитектурной секции, кандидат начинает отвечать и забалтывает собеседника, ничего не сказав по сути. Но интервьюер не замечает этого и ставит хорошую оценку за архитектуру, хотя должен был поставить её за навыки общения.
Акцент на негативе. Если кандидат не отвечает на первые три вопроса, мы цепляемся за это, а правильные ответы на остальные вопросы не замечаем. Поэтому итоговая оценка смещается в отрицательную сторону.
Какие у нас требования к интервьюерам и какие они могут допускать ошибки
В ЮMoney есть разные интервьюеры: кто-то построже, кто-то помягче, а кто-то боится обидеть кандидата и ставит среднюю оценку. Но нам надо оценивать профессиональные качества соискателя, и если он не проявил какую-то компетенцию во время интервью, то это не всегда значит, что он чего-то не знает. Возможно, он просто не проявил её именно в этот момент.
Иногда возникают ошибки в предпочтениях, когда мы полагаемся на первое впечатление: задаём кандидату вопрос, он ошибается, и мы решаем, что он нам не подходит. Сюда же можно отнести принцип предпочтения похожих. Например, у меня есть склонность выбирать кандидатов с профильным образованием, хотя я понимаю, что нужно оценивать только знания и навыки соискателя.
Сыграть с интервьюером злую шутку может также ошибка предвзятости. Например, на собеседование приходит кандидат с синими волосами, и интервьюер думает, что он легкомысленный. Но это неправильно, мы стараемся подмечать такие моменты и бороться с ними.
Советы кандидатам, которые собираются на собеседование в ЮMoney
Когда на интервью вы получаете задачу, обязательно уточните требования или условия. Поймите, чего от вас хотят. Если вы поймёте это не сразу, то сделаете не то, что нужно, и потеряете время. А время ограничено.
Когда разбираете задачу, обязательно показывайте альтернативные решения. Можно просто упомянуть другие варианты и пояснить, почему выбрали этот. Аргументируйте свой выбор сразу, это даст вам преимущество перед другими кандидатами.
Фокусируйтесь на задаче или вопросе. Я часто вижу, что кандидаты отвлекаются или долго не могут приступить к заданию. Пересильте себя и постарайтесь сразу перейти к сути, начать можно с уточняющих вопросов.
Проявляйте самостоятельность. Никто не будет водить вас за руку, разве что во время адаптационного периода. Я много раз видел, как на собеседовании кандидат ждёт, что интервьюер даст ему подсказку или сам раскроет детали вопроса. Это не лучшая позиция.
Будьте открытыми. По моим наблюдениям, если кандидаты не знают ответа на вопрос, они пытаются что-то придумать. Но лучше просто сказать, что вы не знаете, и попытаться порассуждать. Интервьюер с удовольствием с вами пообщается, если у него будет время.
Найм — это непросто, причём как для кандидатов, так и для интервьюеров. Надеемся, эта статья пригодится и тем, и другим.
Пишите в комментариях, что думаете, и задавайте вопросы о собеседованиях в бэкенд ЮMoney. Ответим всем.
Комментарии (2)
Scott_Leopold
18.01.2024 16:18+1Наконец-то годная статья про найм. А то или стенания "джунов миллион а найти подходящего два года не можем", или снобистские рассуждения "все лохи, только мы в нашей конторе крутые".
stavrolia
Спасибо за статью! На ваш взгляд блок во время довольно короткого собеседования про декомпозицию задач действительно позволяет определить научился ли человек приоритизации? Не бывало ли такого, что на собеседовании человек попадает в третий пункт, у него все по полочкам и структурированно, а потом на работе оказывается, что когда задача становится больше собеседовательной, у человека уже не получается самому дробить и нормально планировать? Мне показалось, что это немного про разное.