Как решать проблему с закрытым проприетарным инструментом и недостаточной документацией

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

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

Как отвечать

Стройте ответ на своём случае по STAR: что за инструмент, сколько было времени, чем закончилось, лучше с цифрой. Каркас действий фронтендера:

• сузить задачу: выписать, какие именно функции инструмента нужны. Разбираться во всём продукте незачем;
• ограничить время: день-два на исследование, после чего вы идёте к лиду с выводами и рисками, а не молча копаете дальше;
• выжать всё из поставки: файлы .d.ts в пакете часто точнее документации, рядом бывают source maps и примеры. Минифицированный код читается через pretty print в DevTools, а вкладка Network показывает, какие запросы делает SDK и что отвечает сервер;
• спросить поставщика: у платного продукта поддержка входит в то, за что заплачено, и вопрос с минимальным воспроизведением получает ответ быстрее. Параллельно поищите коллег, которые уже с ним работали;
• изолировать: обернуть инструмент в свой адаптер с понятным интерфейсом, закрепить точную версию в lock-файле и покрыть адаптер тестами на найденное поведение. Тогда обновление или замена затронут один модуль;
• записать: короткий README или ADR с найденными особенностями, чтобы следующий человек не проходил тот же путь.

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

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

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

Правят код поставщика прямо в node_modules или патчат его без согласования. Изменения слетят при переустановке, а лицензия может запрещать модификацию.

Не называют результат. Ответ без итога, будь то рабочая интеграция, документ для команды или обоснованный отказ от инструмента, звучит как пересказ процесса.