Как ответить
Я оцениваю кандидата по трём блокам: техническая компетентность, совместимость с командой, и отношение к работе. Для middle-разработчика мне важно не просто знание синтаксиса, а умение принимать решения и аргументировать их.
Техническая часть — это не алгоритмы на доске, а реальный код. Я даю небольшое практическое задание прямо на собеседовании — например, написать метод для обработки коллекции или найти багу в простом куске кода. Смотрю, как человек рассуждает вслух, какие вопросы задаёт перед началом. Для middle критично не молчать, а прояснять требования и показывать хотя бы два варианта решения с пояснением плюсов и минусов. Если кандидат сразу пишет решение без уточнений — красный флаг.
Второй блок — коммуникация и работа в команде. У нас в проекте код-ревью обязательное. Я спрашиваю: «Расскажите о конфликте в код-ревью, что делали?». Хорошо, если кандидат говорит про поиск компромисса или обоснование технического решения, а не «я настоял на своём» или «уступил». Ещё спрашиваю про опыт онбординга: «Как вы вводили новичка в проект?» — это показывает зрелость.
Третий блок — мотивация и развитие. Для middle важно иметь зону роста. Я спрашиваю: «Что вы читали/изучали за последние полгода?». Если называют только документацию по текущему стеку — ок, но если упоминают смежные области (DevOps, архитектуру, тестирование) — плюс. Также смотрю на отношение к легаси — если говорит «всё переписать» без анализа стоимости — плохо.
- Тест на логику и чтение кода: даю 5-10 строк с багом, прошу найти и исправить.
- Оценка архитектурного мышления: как бы ты спроектировал модуль для оповещений? Какие альтернативы?
- Кейс по код-ревью: показываю кусок кода с типичными антипаттернами, спрашиваю, что бы исправил.
- Soft skills: прошу вспомнить ситуацию, когда дедлайн горел, и что делал.
Итог: для меня собеседование — это не экзамен, а диалог. Я даю кандидату шанс показать себя, поэтому создаю комфортную атмосферу. Главное — чтобы человек мог объяснить любое своё решение.