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

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

Как вы договариваетесь с бэкендом и другими фронтендерами: о контракте API, о сроках, о спорных местах в коде. Интервьюер хочет услышать конкретные механизмы, а не «мы общались в Slack». Следом почти всегда просят пример разногласия и чем оно закончилось.

Как отвечать

Возьмите реальный проект и пройдите по точкам взаимодействия:

• контракт с бэкендом: формат ответа, ошибки, пагинацию, даты и часовые пояса обсуждают до начала работы. Удобно, когда контракт описан в OpenAPI и из него генерируются типы, например через openapi-typescript: расхождение ловит компилятор;
• работа без готового API: пока бэкенд пишется, фронтенд живёт на моках, например через MSW. Это снимает ситуацию «жду эндпоинт две недели»;
• ревью: небольшие PR с описанием, что и зачем изменено. Споры о стиле закрывают ESLint и Prettier в CI, чтобы на ревью обсуждать логику;
• общие компоненты: договорённость, кто владеет UI-китом и как в него вносят правки, иначе появляются три одинаковые кнопки;
• блокеры: о проблеме говорят, как только видно, что срок сдвигается, а не в день демо;
• дизайнер и QA: состояния загрузки, ошибки и пустого экрана уточняют до вёрстки, а не после.

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

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

Перечисляют ритуалы: стендапы, Jira, Slack. Это инструменты, а вопрос про то, как вы договариваетесь.

Ругают бэкенд. Даже если коллеги действительно срывали сроки, рассказ должен быть про то, как вы это решали.

Не имеют примера конфликта. «У нас всё было гладко» звучит как отсутствие опыта, лучше расскажите про реальное разногласие и компромисс.