Сколько времени занял рефакторинг и каков был объем работы
Что проверяют
Умеете ли вы описывать объём работы понятно и безопасно ли вы её делаете. Вопрос про сроки, а слушают, чем вы мерили объём, как страховались от регресса и зачем вообще трогали работающий код.
Как отвечать
Начните с причины. Рефакторинг ради чистоты никого не убеждает, а вот «правка в этом модуле ломала соседний» или невозможность написать тест, не подняв весь сервер, это понятные поводы.
Дальше объём. Мерьте его не строками, а тем, что отражает риск:
- сколько маршрутов и обработчиков затронуто и какие из них в горячем пути;
- сколько внешних контрактов менялось: формат ответов API, схема событий в очереди, данные в базе;
- что было со страховкой: существовали ли тесты до начала или их пришлось написать первыми.
Про срок скажите честно, что он календарный и делится с продуктовыми задачами: крупное изменение почти всегда идёт кусками, а не сплошным блоком. Назовите своими словами типичные для Node сюжеты: развал разросшегося сервера на модули с явными зависимостями, перевод колбэков на промисы и async, вынос работы с базой из обработчиков, постепенная типизация, замена самописного слоя на библиотеку.
Отдельно опишите выкатку: небольшими частями за флагом, со сверкой поведения старого и нового пути, а не одним слиянием после месяца работы в стороне.
Где спотыкаются
Называют объём в строках кода. Тысяча строк переименований и тысяча строк в слое транзакций это несопоставимые работы, и такая мера сразу выдаёт, что рисками никто не управлял.
Второе: отчитываются процентом ускорения. Рефакторинг меняет структуру, а не алгоритм, и заметный прирост скорости обычно приходит от другого изменения, например от убранного лишнего похода в базу. Так и стоит формулировать: что конкретно стало дешевле и почему.
Третье: описывают ветку, которая месяц жила отдельно от основной. Слияние такой ветки это отдельный проект с конфликтами и регрессом, и рассказ о нём читается как опыт, который лучше не повторять.