Как я собеседую инженеров

Собеседование - это не экзамен

Сейчас я работаю в одной из крупнейших компаний России - Авито. Отбор к нам довольно строгий и состоит из нескольких этапов. Но когда я работал в средних компаниях, да и сейчас, когда я помогаю им в роли консультанта, у меня нет возможности проводить несколько этапов с разными интервьюерами. Хорошего человека за это время просто уведут даже на текущем рынке, потому что хайквалы все еще востребован. Поэтому я сформировал принцип: каждое собеседование должно проверять что-то конкретное. Не «уровень кандидата вообще», а конкретный навык, который ему понадобится с первого дня.

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

Вопросы с одобряемыми ответами

Сколько раз меня спрашивали про расшифровку SOLID и разницу между HashMap и TreeMap? Слишком много. И это просто проверка на знание правильного ответа.
Но ведь эти самые правильные ответы на типовые вопросы давно заучены. Кандидат без опыта зачастую отвечает не хуже сеньора с десятью годами опыта. На выходе ты не знаешь о человеке ничего, кроме того, что он умеет готовиться к собеседованиям.
А мне-то нужно выбрать того, кто будет работать.

Что я даю вместо этого

Мой любимый формат для инженеров - разбор плохого кода. У меня давно есть заготовленный кусочек на 100 строк, в котором намеренно зашиты проблемы: нарушение принципов проектирования, race condition, неудачными абстракциями, хардкодом. И я даю кандидату почитать этот код и прокомментировать его.
Это сразу показывает несколько вещей. Видит ли человек проблему вообще. Может ли он объяснить, почему это плохо. Предложит ли он, как это починить. Полезет ли в детали реализации или ограничится «ну переписать бы покрасивее».
Заучить такое нельзя, ведь это вопрос опыта.

Конечно, это не помогает при встрече с кандидатами, которые на удаленном собеседовании применяют AI-помощников. Здесь приходится смотреть за паттернами поведения.

- Чересчур ровные формулировки
- Пауза перед тем, как «подумать вслух»
- Глаза, которые читают текст, а не вспоминают.
- Плавающий темп - где-то моментально, где-то почему-то надо подумать минуту над банальностью.

Сам ответ при этом может быть и правильным. Но если по поведению видно, что отвечает не человек, а человек с подсказчиком. Здесь помогает также прием с вопросами вглубь темы. И если там будет помощник, то с каждым шагом это будет все виднее.

System Design

Долго считал, что секция System Design уместна только для сеньоров и выше. Но в качестве эксперимента я даю подобные задачи и мидлам.
Конечно, это не цель уровня «спроектируй Twitter». Можно разобрать что-то близкое к коду. Например, «у нас есть вот такой сервис, добавляется такая функция, как ты её встроишь». Локальная задача в реальном масштабе. Здесь уже видно, как человек думает: лезет ли он сразу в код или собирает требования. Понимает ли границы своей ответственности. Слышит ли встречные аргументы.

Итого

Если у меня есть один технический этап на час, я обычно отдаю предпочтение разбору кода. Если же есть чуть больше времени, то беру мини System Design. Из этих минут я выношу гораздо больше, чем из любого Leetcode-марафона.
Главное, что я понимаю по итогу: смогу ли я завтра отдать этому человеку реальную задачу из бэклога и спокойно лечь спать.

А как вы решаете, что кандидат подходит?

#собеседования #найм #процессы