Что бы изменил в текущем проекте и почему

Что проверяют

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

Как отвечать

Взять одну или две конкретные вещи из своего проекта и провести их по схеме: что болит, как это обнаружили, что предлагается взамен, чего это стоит и почему до сих пор не сделано. Для Java-проекта честный список обычно такой:

• N+1 в JPA: ленивые связи в цикле, лечится join fetch или @EntityGraph, а найти помогает лог SQL со счётчиком запросов;
• границы @Transactional, растянутые на внешние вызовы, транзакция держит соединение из пула всё время похода в чужой сервис;
• схема базы без миграций или с миграциями «по памяти» вместо Flyway или Liquibase;
• бизнес-логика в контроллерах и тесты, которые ходят в общий стенд вместо Testcontainers;
• проглоченные исключения и общий RuntimeException там, где нужна доменная ошибка.

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

Где спотыкаются

Отвечают «переписал бы на микросервисы». Без названной причины это тревожный сигнал: слышно желание поработать с модной архитектурой, а не решить проблему. Тот же эффект даёт «переписал бы всё с нуля».

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

Третье: скатываются на личности, критикуют коллег, тимлида или заказчика. Спрашивают про систему, а не про людей, и интервьюер примеряет эту критику на свою будущую команду.