Что можно было улучшить на прошлом месте работы
Что проверяют
Умеете ли вы критиковать процесс, не переходя на людей и не сливая бывшего работодателя. Заодно смотрят, видите ли вы систему за своими задачами и приносите ли предложения, а не жалобы. По ответу прикидывают, что вы скажете о них самих через год.
Как отвечать
Выбрать одну конкретную вещь и разложить её: как было устроено, чем это мешало делу, что вы предложили, чем закончилось. Обобщения вроде «плохие процессы» не работают, нужен пример.
Для питониста выигрышные темы обычно такие:
- тесты: их не было или прогон был ручным, добавили pytest на критичный модуль и завели прогон в CI;
- воспроизводимость окружения: разъезжающиеся версии у разработчиков лечатся lock-файлом и общей сборкой;
- типизация и линтер: mypy и ruff в пайплайне снимают половину споров на ревью;
- миграции базы руками на проде, фоновые задачи без очереди и ретраев, отсутствие структурных логов и алертов;
- длинные функции, в которых перемешаны запросы к базе, бизнес-правила и форматирование ответа.
Если предложение не внедрили, сказать честно почему: приоритеты были у продуктовых задач, поддержки не нашлось. Это не минус, если видно, что вы понимали цену вопроса. Полезная концовка: чему это научило и что сделаете иначе здесь.
Где спотыкаются
Превращают ответ в жалобу на руководителя или коллег. Интервьюер слышит не проблему процесса, а готовый отзыв о будущей команде, и дальше вопрос считается проваленным независимо от того, справедлива критика или нет.
Отвечают, что всё было отлично и улучшать нечего. Читается как нежелание говорить или как отсутствие взгляда за пределы своих задач. У любой команды есть очевидное больное место, и назвать его не опасно.
Придумывают проценты: ускорил на сорок, удовлетворённость выросла, отказы упали. За цифрой сразу идёт вопрос, как её мерили, и выясняется, что на глаз. Надёжнее назвать проверяемый факт: прогон тестов вместо получаса стал занимать пару минут, релиз перестал требовать дежурного ночью.