🧠 Идеальное интервью для кандидата или как я провожу техническое собеседование

За последние годы я провёл довольно много технических собеседований. И выработал для себя формат, который помогает максимально эффективно понять кандидата: как он думает, как решает задачи, какие паттерны знает и насколько он senior не по тайтлу, а по сути.

Вот из чего состоит моё интервью 👇
это не все, но это вектор.

1️⃣ Глубинный разбор опыта

Фокус на последние 1.5–2 года. Это наиболее актуальный и релевантный опыт. Я не просто спрашиваю: "С чем работал?" - мне важно:
- Какие проблемы решал и в каком контексте?
- Как принимал технические решения?
- Что предлагал, что внедрял, за что брал ответственность?

Если человек говорит, что работал с Kafka или с микросервисной архитектурой - я не спрашиваю про internals.
Я жду, что он знает, как её применять в реальных задачах. Знает такие паттерны как:
- Transaction Outbox
- Message Relay
- Message Deduplication
- At-Least-Once / Exactly-Once semantics
- И чем отличаются Kafka, SQS, RabbitMQ по задачам.

Потому что инструменты можно поменять. А инженерное мышление и знание устойчивых паттернов - остаётся.

Еще люблю спросить, почему выбрали микросервисную архитектуру? Вопрос со звездочкой 😜

2️⃣ Оптимизация и мышление через алгоритмы (но не те, что спрашивают в Яндекс)

Я даю кейс: есть проблема с производительностью. Что ты будешь делать?

Если человек сразу кидает 3 способа оптимизации - это минус. Значит, гадает.

🧩 Мне важен алгоритм мышления:
- Как он ставит гипотезы?
- Умеет ли строить pipeline поиска проблемы?
- Понимает ли, какие метрики смотреть, какие инструменты использовать?
- Понимает ли что нужно изменить в конкретных случаях и как анализировать результаты?

Я не требую знания названий всех техник, важно - чтобы умел думать как инженер, а не просто "помнить готовые ответы" и стрелять рандомными гипотезами, которые не подкреплены данными.

3️⃣ Чтение и анализ кода

Это важнейшая часть.
Я стараюсь не касаться в теоритической части интервью вопроса кода, так этот этап все прекрасно показывает. Я много раз сталкивался когда слышал верные красивые определения SOLID, но на практике было все грустно.

Я даю кусок кода. Один файл, единственный. Типичный кейс для code review.

И тут открывается самое интересное.

Что я смотрю?

✅ Понимает ли человек SOLID-принципы:
- Где SRP нарушен? Делает ли метод слишком много?
- Нарушен ли OCP - легко ли расширять код?
- Видит ли проблемы наследования / полиморфизма?

✅ Указывает ли на отсутствие тестов - ведь это единственный файл, и если не спросить про покрытие, то… ну, как бы 🤷‍♂️

✅ Обращает ли внимание на типы и эффективность:
- dict vs list на in
- Явная типизация
- Контракты функций и стабильность интерфейсов

✅ Видит ли уязвимости и недочёты:
- SQL-inj? Отсутствие экранирования?
- Потенциальные None и краши?
- Место, где забыли закрыть файл или соединение?
- Расширяемость и безопасность API?

✅ Умеет ли мыслить выше линтинга.

❌ Если кандидат тратит 15 минут из 30 на то, чтобы рассказать, где нужно пробел поставить и как переименовать переменную - сразу нет.

📌 Я ожидаю: заметил → предложил решение (линтер, форматтер, SAST) → пошёл дальше.
Хочу слышать не "назовём функцию по-другому", а:
- "Этот код не тестируем, потому что... Надо так..."
- "Нарушена инкапсуляция, потому что... Надо так..."
- "Вот тут возможен race condition, потому что... Надо так..."
- "Здесь не хватает валидации... Надо так..."
- "Этот вызов не проверяется на авторизацию... Надо так..."

Вот так и раскрывается опыт и уровень ИНЖЕНЕРА.

🟡 Итог

🎯 Идеальное интервью - это не экзамен. Это проверка инженерного мышления.

Если после интервью я слышу (а это бывает не редко):

"Спасибо, за собеседование, я много нового узнал"
то… скорее всего, это будет отказ. Но это не значит, что нужно благодарить за интервью 😉

Потому что я узнал о кандидате меньше, чем он от меня. А должно быть наоборот.

🛠 P.S. Уважаю кандидатов, которые умеют думать, спорить, аргументировать и признавать границы своей экспертизы.
Потому что даже если не подойдёт позиция сейчас - я таких точно запомню.