Поведенческое интервью и вопросы работодателю

Это не биография с детского сада, а «питч» на 1–2 минуты по схеме настоящее → прошлое → будущее: кто вы сейчас и над чем работаете, какой путь и ключевые достижения привели вас сюда, почему вас интересует эта позиция.

«Я Python-разработчик, последние полтора года делаю бэкенд для сервиса доставки на Django и PostgreSQL: отвечаю за модуль расчёта стоимости и интеграции с курьерскими службами. Из заметного — перевёл тяжёлые отчёты на фоновые задачи Celery, и таймауты в админке пропали. До этого закончил курсы и сделал пет-проект на FastAPI с тестами и CI. Сейчас хочу работать над высоконагруженным API и глубже погрузиться в асинхронный Python — поэтому ваша вакансия мне интересна».

Показывают: умеете ли вы спорить по существу, слушать и приходить к решению. Плохо: «конфликтов у меня не бывает» или история, где вы победили «глупого» коллегу.

S: Мы с коллегой разошлись в подходе к кешированию каталога: он хотел кешировать целые страницы, я — отдельные товары. T: Нужно было выбрать решение до релиза через неделю. A: Я предложил не спорить абстрактно, а договориться о критериях — частота обновления цен и нагрузка на базу. Мы за день сделали два прототипа и прогнали нагрузочный тест. Его вариант оказался быстрее, но давал устаревшие цены до 10 минут; мы объединили подходы: страницы кешируются, а при изменении цены инвалидируются по событию. R: Нагрузка на базу упала втрое, жалоб на цены не было. Я вынес, что спор о решениях лучше переводить в измеримые критерии.

Нужна реальная ошибка с последствиями. Важнее всего — что вы сделали после: исправили, сообщили, изменили процесс.

S: Я выкатил миграцию, которая переименовывала колонку, а старая версия приложения ещё обслуживала часть трафика. T: Минут десять часть запросов падала с ошибкой. A: Я сразу сообщил в канал инцидентов, откатил миграцию, затем переделал изменение в три шага: добавить новую колонку, писать в обе, переключить чтение и только потом удалить старую. Написал короткий постмортем и предложил проверку миграций на обратную совместимость в CI. R: Больше таких инцидентов в команде не было, а схему «расширить — переключить — сузить» мы описали в документации.

Ключевое: заранее предупредили, предложили варианты (урезать объём, перенести срок, привлечь помощь), а не молча работали ночами и сорвали срок.

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

«Спокойно — это бесплатное обучение. Например, на ревью мне указали, что мои функции по 80 строк сложно читать и тестировать. Я попросил примеры, как бы сделал ревьюер, и потом специально разбивал код на маленькие функции с понятными именами. Через пару месяцев замечаний по структуре почти не осталось, а сам я теперь так же внимательно смотрю на это в чужих PR».

Назовите настоящую, но не критичную для роли слабость и что вы с ней делаете. Не «я трудоголик».

«Раньше я долго не просил помощи — мог день разбираться сам, хотя коллега подсказал бы за 10 минут. Теперь у меня правило: если застрял больше чем на час, формулирую вопрос и пишу в чат команды. Это экономит время и мне, и проекту».

Подготовьтесь: продукт, стек, технический блог, новости компании. Связывайте свои цели с тем, что даёт вакансия. О прошлом работодателе — без негатива: говорите о том, к чему идёте, а не от чего бежите.

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

Покажите, что думаете о развитии и что это совместимо с компанией: «хочу стать сильным бэкенд-разработчиком, который может спроектировать сервис целиком и помогать новичкам; дальше — техлид или глубокая экспертиза, посмотрю, что ближе».