На чем был бэкенд в вашем проекте

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

Вопрос не про технологию бэкенда, а про то, насколько глубоко вы понимали систему за пределами своей части. Обычно следом идёт уточнение: как договаривались о контракте API и что делали, когда ручка не готова или отвечает не тем, что ожидалось.

Как отвечать

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

• стек: язык и фреймворк (Java со Spring Boot, Go, Python с FastAPI, Node.js с NestJS), монолит или набор сервисов, есть ли BFF или шлюз перед фронтендом;
• протокол: REST с JSON, GraphQL, gRPC-web. Говорите о том, что видели именно вы: формат ошибок, устройство пагинации, работа с датами и часовыми поясами, версионирование ручек;
• контракт: откуда брали описание (OpenAPI, схема GraphQL), генерировали типы через openapi-typescript и GraphQL Codegen или писали руками, как узнавали об изменении ответа;
• авторизация: сессионные куки или токены, где хранятся, как обновляются, кто перехватывает 401 и разлогинивает;
• живые данные: WebSocket, SSE, поллинг, очереди, и как задержки бэкенда отражались на интерфейсе;
• работа до готовности ручки: моки через MSW, фикстуры, отдельный стенд с тестовыми данными.

Самая сильная часть это конкретный эпизод взаимодействия: попросили собрать составной ответ, чтобы список не тянул пять запросов; договорились о поле total для пагинации; нашли расхождение в формате дат между двумя сервисами. Вспомните два таких случая заранее, они и есть настоящий ответ на вопрос.

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

Отвечают одним словом: «на Node». Разговор закончен, а вопрос был приглашением рассказать про систему.

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

Переходят к жалобам на бэкендеров. Спрашивали про архитектуру, а не про отношения. Если конфликт был, расскажите, чем он закончился и что вы поменяли в процессе, чтобы он не повторился.