Как происходит взаимодействие с вендорами

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

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

Как отвечать

У фронтендера вендоры это платёжные виджеты, аналитика, карты, чаты поддержки, headless CMS, сервисы авторизации, иногда подрядчик, который делает часть интерфейса. Опирайтесь на свой пример:

• выбор: вес в бандле и tree-shaking, типы для TypeScript, работа при SSR, лицензия, частота релизов, песочница, требования к CSP;
• изоляция: весь код вендора за одним модулем-адаптером. Компоненты зовут ваш интерфейс, а не SDK напрямую, и смена поставщика затрагивает один файл;
• загрузка: тяжёлый SDK подключается динамическим import() там, где нужен, сторонние скрипты идут с async или defer. Версию на CDN фиксируют, а для неизменного файла добавляют integrity;
• отказ: у виджета есть таймаут и запасной вариант, чтобы недоступная карта не роняла оформление заказа;
• тесты: ответы вендора мокают, например через MSW, иначе CI зависит от чужого стенда;
• коммуникация: тикет в поддержку с воспроизведением, версией SDK, браузером, HAR-файлом и ожидаемым поведением. Такой тикет закрывают быстро, «у вас не работает» висит неделями.

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

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

Вставляют скрипт аналитики синхронно в <head>, а потом ищут, почему просел LCP и вырос INP.

Размазывают вызовы SDK по десяткам компонентов. Мажорное обновление вендора превращается в недельный рефакторинг.

Забывают про данные пользователей: сторонний скрипт видит всё на странице, а передача персональных данных вендору требует согласования с юристами и учёта 152-ФЗ.