По каким протоколам взаимодействовали с бэкендом

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

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

Как отвечать

База это HTTP поверх TLS, чаще всего REST с JSON. Рассказывайте не про сам факт, а про обвязку: fetch с AbortController для отмены, разбор статусов, единый слой клиента, куда собраны базовый адрес, заголовки и обработка 401.

const res = await fetch(url, { signal });
if (!res.ok) throw new ApiError(res.status, await res.text());

Дальше вариант под задачу:

• GraphQL, когда экранов много и каждому нужен свой набор полей. Это язык запросов поверх того же HTTP, а не отдельный протокол;
• SSE, когда поток односторонний: лента, прогресс задачи, уведомления. Идёт по обычному HTTP и переподключается сам;
• WebSocket, когда обмен двусторонний и частый: чат, совместное редактирование, котировки;
• долгий опрос как запасной путь там, где прокси рвёт длинные соединения.

Отдельно упомяните CORS, выбор между куками с SameSite и токеном в заголовке, отправку файлов через FormData.

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

Считают, что fetch отклоняет промис на 404 и 500. Он отклоняется только на сетевой ошибке, код ответа надо проверять самому через res.ok. Отсюда интерфейс, который показывает страницу ошибки как обычные данные.

Второе: называют WebSocket ответом на любые обновления. Для одностороннего потока SSE проще, переживает разрывы сам и не требует отдельной инфраструктуры, а сокет придётся переподключать руками и досинхронизировать состояние после разрыва.

Третье: молчат про отмену. Пользователь печатает в поиске, ответы приходят вразнобой, и на экран попадает результат устаревшего запроса. Лечится отменой предыдущего запроса или проверкой актуальности пришедшего ответа.