Работал ли ты с Django REST Framework

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

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

Как отвечать

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

• сериализаторы: ModelSerializer для типового CRUD, отдельные классы на чтение и запись, проверки в validate_<поле> и validate;
• вью: ModelViewSet для стандартных операций, @action для нестандартных, тяжёлая логика вынесена в сервисный слой;
• права: permission_classes на уровне вью плюс фильтрация get_queryset по текущему пользователю;
• обвязка прода: пагинация по умолчанию, фильтры, ограничение частоты запросов, схема OpenAPI.

Хорошо назвать, что делали руками: своё поле сериализатора, вложенную запись в одной транзакции, загрузку файлов, тесты через APIClient.

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

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

Ловят N+1 в сериализаторе. Вложенный сериализатор или поле-метод дёргает связанную таблицу на каждый объект страницы, лечится это select_related и prefetch_related в get_queryset.

Делают из сериализатора свалку бизнес-логики: письма, платежи, вызовы соседних сервисов прямо в create. Такой код нельзя переиспользовать вне HTTP и тяжело тестировать, логике место в отдельном слое, а сериализатору остаётся проверка и представление.