Есть ли вещи в проекте, которые вы хотели бы исправить?

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

Умеете ли вы видеть проблемы трезво: без обиды на предшественников и без «у нас всё идеально». Интервьюеру важно, отличаете ли вы вкусовщину от того, что реально мешает пользователям и команде. Следом спросят: «Почему это до сих пор не исправили и что вы сделали сами?»

Как отвечать

Возьмите одну-две вещи из текущего проекта и разложите каждую по схеме:

• что не так: конкретно, а не «легаси». Например, бандл без разделения на чанки, смесь Redux и контекстов без правил, половина кода на JavaScript без типов, флаки e2e-тесты, нет дизайн-системы и одна и та же кнопка сделана пятью способами;
• чем это мешает: пользователям (LCP, INP и CLS из Core Web Vitals, ошибки в Sentry) или команде (время сборки, число регрессий, долгий онбординг);
• как вы это измерили: Lighthouse, панель Performance в Chrome DevTools, webpack-bundle-analyzer или rollup-plugin-visualizer, полевые метрики реальных пользователей;
• что вы предложили или сделали: постепенный переход на TypeScript через allowJs, React.lazy и динамический импорт для тяжёлых экранов, стабилизация тестов;
• почему не всё сделано: приоритеты продукта, цена изменения. Это показывает, что вы понимаете бизнес, а не только код.

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

Если вопрос про их проект, например после тестового задания или демо, говорите аккуратно и с оговоркой: «Я видел только снаружи, но заметил вот это. Это осознанный компромисс?»

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

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

Отвечают «исправить нечего». Это читается как отсутствие собственного взгляда на продукт.

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