Как работали с техническим долгом?

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

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

Как отвечать

Нужна история из вашего проекта с собственными цифрами. Каркас:

• что за долг: для фронтенда это Create React App, который в 2025 году официально объявлен устаревшим, webpack-конфиг, который никто не понимает, moment.js в бандле, классовые компоненты вперемешку с хуками, any по всему коду, тесты на Enzyme, у которого нет официального адаптера для React 18;
• как заметили: не «код плохой», а измеримые симптомы. Сборка идёт 4 минуты, бандл вырос вдвое, каждая правка формы ломает соседнюю, релиз задерживается из-за ручной проверки;
• как приоритизировали: реестр долга в трекере, сравнение стоимости исправления со стоимостью жизни с проблемой, сначала то, что лежит на пути ближайших фич;
• как погашали: постепенно, а не отдельным «спринтом рефакторинга». Правило бойскаута, фиксированная доля задач в каждом спринте, миграция по одному модулю, кодмоды для массовых замен, правило ESLint, которое запрещает старый паттерн в новом коде;
• что получилось: время сборки, размер бандла, число регрессий. Только те цифры, которые вы реально видели.

Если такого опыта не было, расскажите, как бы действовали, и приведите мелкий пример: обновили зависимость с уязвимостью, вынесли дублирующийся компонент, включили strict в tsconfig.json.

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

Предлагают «переписать всё с нуля». Для интервьюера это сигнал, что вы не считаете риск и не представляете, как бизнес будет жить полгода без новых фич.

Говорят о долге только как о проблеме кода. Продукту важны последствия: скорость выпуска фич, баги у пользователей, время онбординга новичков.

Называют результат вроде «разработка ускорилась на 30%» без способа измерения. Лучше скромная, но проверяемая цифра.