Приходилось ли взаимодействовать с фронтенд командой и писать эндпоинты

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

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

Как отвечать

Рассказывайте про порядок работы, а не про список путей. Сначала контракт: схема запроса и ответа согласуется до кода, фронтенд по ней сразу поднимает заглушку и не ждёт бэкенд. В FastAPI это получается почти бесплатно, модели pydantic дают описание OpenAPI, по которому фронтенд генерирует типы. В DRF ту же роль играют сериализаторы вместе с drf-spectacular.

Дальше про решения, которые фронтенд чувствует на себе:

• единый формат ошибки: код, читаемое сообщение, поле, к которому оно относится, и один и тот же вид у всех ручек;
• статусы по смыслу: 401 про «не знаем, кто ты», 403 про «знаем и не пускаем», 422 про непройденную валидацию;
• пагинация с самого начала, иначе растущий список однажды упрётся в таймаут;
• согласованные имена полей и даты в формате ISO 8601 с зоной.

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

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

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

Пересказывают набор путей вроде GET /api/users и на этом заканчивают. Вопрос был про взаимодействие, а не про четыре операции над таблицей, и без истории согласования ответ оказывается пустым.

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

Третье: ошибку отдают двухсотым ответом с полем error внутри, а в тело кладут текст исключения из ORM. Фронтенд вынужден проверять каждый ответ вручную, а наружу утекает структура базы.