Вопросы по Django на собеседовании: от основ до Highload

Введение: зачем готовиться к Django-интервью в 2026 году

Рынок разработки на Python в 2026 году стабилизировался после бума нейросетей. По данным опроса Python Developers Survey, Django остается самым популярным веб-фреймворком для корпоративного сектора, обгоняя FastAPI в сегменте сложных систем с разветвленной бизнес-логикой. Сегодня недостаточно просто знать, как создать модель или форму. Интервьюеры фокусируются на архитектурных паттернах, глубоком понимании работы баз данных и умении писать производительный асинхронный код.

Эта статья написана для тех, кто претендует на позиции Middle и Senior. Мы не будем тратить время на вопрос «как установить Django», а сразу перейдем к внутреннему устройству фреймворка. Подготовка по этому материалу займет у вас около 3-4 дней интенсивного повторения, но это позволит уверенно отвечать на вопросы, связанные с жизненным циклом запроса, транзакциями, кэшированием и масштабированием.

Для кого этот материал

В первую очередь, статья ориентирована на разработчиков с опытом от двух лет. Мы разберем кейсы, когда стандартные инструменты Django начинают «тормозить», и как это исправлять. Также материал будет полезен тимлидам для составления программы внутреннего обучения или формирования пула вопросов для найма сотрудников в свои команды. В 2026 году акцент сместился в сторону облачных решений и микросервисной архитектуры, поэтому Django часто рассматривается как ядро системы, взаимодействующее с десятками внешних API.

Что вы узнаете

Мы последовательно пройдем через 12 ключевых блоков: от глубокого погружения в ORM до вопросов безопасности и DevOps. Вы узнаете, как отвечать на вопросы про асинхронные вьюхи, почему Select Related не всегда спасает от N+1, и как правильно готовить Django к деплою в Kubernetes. В конце статьи приведен чек-лист для самопроверки, который поможет быстро освежить знания перед самым звонком с рекрутером.

1. Жизненный цикл запроса и Middleware

Понимание того, как HTTP-запрос превращается в HTTP-ответ в недрах Django — это базовый фильтр на любом собеседовании. В 2026 году важно разделять синхронный (WSGI) и асинхронный (ASGI) пути прохождения запроса. Когда пользователь отправляет запрос, он первым попадает на веб-сервер (Nginx/Envoy), затем через интерфейс шлюза передается в обработчик Django. Здесь начинается работа Middleware.

Middleware в Django — это легкие плагины, которые выполняются на уровне системы «запрос-ответ». Каждый слой Middleware имеет возможность либо передать запрос дальше, либо вернуть ответ самостоятельно (например, если пользователь не авторизован). В версии Django 5.x и выше поддержка асинхронных Middleware стала стандартом, и теперь разработчик должен четко понимать, как `sync_to_async` и `async_to_sync` влияют на производительность при прохождении через эти слои.

Порядок выполнения слоев

Запросы проходят через Middleware сверху вниз (как указано в настройках), а ответы — снизу вверх. Это критично для логики безопасности и кэширования. Например, `SecurityMiddleware` должен быть первым, чтобы отсечь вредоносные запросы до того, как они нагрузят базу данных. В то время как `GZipMiddleware` часто ставится выше, чтобы сжимать уже сформированный ответ перед отправкой клиенту.

Асинхронные Middleware в Django 5.1+

С выходом последних версий Django появилась возможность писать гибридные Middleware, которые поддерживают и синхронные, и асинхронные вызовы. На собеседовании могут спросить: «Что произойдет, если в цепочке асинхронных Middleware окажется одно синхронное?». Ответ: Django создаст отдельный поток для выполнения синхронного кода, что может привести к накладным расходам на переключение контекста. Поэтому в 2026 году хорошим тоном считается полная адаптация всех слоев под `async`.

2. Глубокое погружение в ORM: Оптимизация и N+1

ORM (Object-Relational Mapping) — это сердце Django и одновременно главный источник проблем с производительностью. Самый популярный вопрос: «Как обнаружить и устранить проблему N+1?». Это ситуация, когда для получения связанных данных Django делает по одному дополнительному запросу к БД для каждой записи в основном наборе данных. Если у вас 100 постов и вы хотите вывести имя автора каждого поста, без оптимизации вы получите 101 запрос к базе.

Для решения используются `select_related` и `prefetch_related`. `select_related` работает через SQL JOIN и идеально подходит для связей ForeignKey и OneToOne. `prefetch_related` делает отдельный запрос и выполняет «склейку» на стороне Python, что необходимо для ManyToMany связей или когда вы тянете данные из разных баз. В 2026 году также активно обсуждается использование `FilteredRelation` для сложных условий в JOIN.

Использование QuerySet.explain()

На уровне Senior разработчика ожидается умение пользоваться методом `.explain()`. Он позволяет увидеть план выполнения запроса в PostgreSQL или MySQL. Если вы видите `Seq Scan` на большой таблице — значит, не хватает индекса. В Django 5.x появились расширенные возможности для создания функциональных индексов прямо через мета-опции моделей, что позволяет индексировать даже результаты функций (например, перевод строки в нижний регистр).

# Пример оптимизации запроса
from django.db.models import Prefetch

# Получаем заказы с пользователями и их активными подписками в 2 запроса
orders = Order.objects.select_related('user').prefetch_related(
    Prefetch('user__subscriptions', queryset=Subscription.objects.filter(active=True))
)

Агрегации и аннотации

Часто на интервью просят посчитать количество связанных объектов без загрузки их в память. Здесь на помощь приходят `annotate()` и `aggregate()`. Важно понимать разницу: `aggregate` возвращает словарь с итоговым значением (например, средняя цена всех товаров), а `annotate` добавляет поле к каждому объекту в QuerySet. В современных версиях Django оптимизация этих методов позволяет избегать лишних подзапросов, используя оконные функции (Window functions) через `Window` и `F`-выражения.

3. Транзакции и блокировки в Django

Работа с данными в конкурентной среде требует понимания транзакций. По умолчанию Django работает в режиме `autocommit`, где каждый `save()` — это отдельная транзакция. Для бизнес-логики, где нужно выполнить несколько действий атомарно, используется декоратор или контекстный менеджер `transaction.atomic`. Но здесь кроется ловушка: слишком длинные транзакции блокируют таблицу и могут «положить» базу под нагрузкой.

Интервьюеры любят спрашивать про `select_for_update`. Это метод, который блокирует строки в БД до завершения текущей транзакции. Он критически важен в задачах типа «списание баланса» или «бронирование билета», где два одновременных запроса не должны обработать одну и ту же запись. В 2026 году стандартным ответом считается также упоминание параметра `nowait=True` или `skip_locked`, чтобы приложение не висело в ожидании освобождения строк, а сразу возвращало ошибку или переходило к следующей записи.

Уровни изоляции транзакций

Хотя Django позволяет настраивать уровни изоляции через настройки БД, разработчик должен знать, чем `Read Committed` отличается от `Repeatable Read`. В большинстве случаев Django работает с `Read Committed` (дефолт в PostgreSQL). Если на собеседовании спрашивают, как избежать «фантомного чтения», вы должны уметь объяснить, как выбрать правильный уровень изоляции или использовать блокировки на уровне приложения.

• atomic: гарантирует принцип «все или ничего».
• savepoints: позволяют откатывать часть транзакции.
• on_commit: хук для выполнения действий (например, отправка письма) только после успешной фиксации данных в БД.

4. Асинхронное программирование в Django 5.x

Если в 2022 году асинхронность в Django была экзотикой, то в 2026 — это обязательное требование. Django теперь поддерживает асинхронные View, Middleware, тесты и, что самое важное, асинхронный ORM. Вопрос на засыпку: «Станет ли Django быстрее, если просто сделать все вьюхи асинхронными?». Правильный ответ — нет. Асинхронность помогает масштабировать количество одновременных соединений (например, при долгоживущих HTTP-запросах или WebSockets), но не ускоряет вычисления внутри одного запроса.

Основная сложность — взаимодействие асинхронного кода с синхронным ORM. Хотя `async for` уже поддерживается, многие операции под капотом всё еще требуют потоков. Разработчик должен понимать, как работает `sync_to_async`. Это обертка, которая запускает синхронную функцию в отдельном потоке из пула, чтобы не блокировать основной цикл событий (Event Loop).

Когда использовать async в Django

Асинхронные вьюхи идеально подходят для задач, связанных с вводом-выводом (I/O): запросы к внешним микросервисам, работа с S3-хранилищем или ожидание ответа от чат-бота. Если ваша вьюха делает три запроса к разным API, в асинхронном режиме вы можете запустить их параллельно через `asyncio.gather`, что сократит время ответа в три раза.

5. Архитектура: Fat Models vs Services

Этот вопрос относится к области проектирования и не имеет одного «правильного» ответа, но интервьюер хочет услышать вашу аргументацию. Традиционный подход Django — «толстые модели», где бизнес-логика инкапсулируется в методы моделей. Это удобно для маленьких проектов, но в больших системах модели становятся перегруженными и труднотестируемыми. В 2026 году стандартом для крупных проектов стал сервисный слой (Service Layer).

Сервисный слой — это обычные Python-классы или функции, которые принимают данные, выполняют бизнес-логику и взаимодействуют с ORM. Это позволяет отделить логику приложения от деталей хранения данных. Также часто упоминаются селекторы (Selectors) — функции для получения данных, которые заменяют сложные QuerySet-ы в контроллерах. Такой подход упрощает unit-тестирование, так как вы можете тестировать логику без обращения к базе данных, используя моки.

Паттерн Repository в Django

Иногда заходит речь о паттерне Repository. Хотя ORM Django уже является реализацией этого паттерна, создание дополнительной абстракции поверх ORM часто считается избыточным (overengineering). Хороший кандидат должен уметь объяснить, где проходит граница между «чистой архитектурой» и здравым смыслом. В 2026 году популярно использование `pydantic` для валидации данных на входе в сервисы, что делает код более надежным и типизированным.

6. Django Rest Framework (DRF) и альтернативы

DRF остается стандартом для создания API на Django, но в 2026 году у него появились серьезные конкуренты, такие как Django Ninja. На собеседовании могут спросить: «В чем преимущество Django Ninja перед DRF?». Основные аргументы: использование типов Python (Pydantic), встроенная асинхронность и автоматическая генерация документации OpenAPI 3.1 без дополнительных плагинов.

Однако DRF всё еще лидирует по количеству готовых решений (SimpleJWT, FilterBackend, Permissions). Важно знать, как работают сериализаторы в DRF. Самая частая проблема — медленная сериализация больших списков объектов. Решение: использование `SerializerMethodField` с осторожностью (он очень медленный), предварительная выборка данных через `prefetch_related` и, в крайних случаях, переход на `values()` или кастомную сериализацию в JSON через `ujson` или `orjson`.

Аутентификация и права доступа

Вопросы по безопасности API всегда актуальны. Как работает JWT? Почему нельзя хранить JWT в LocalStorage (риск XSS)? Как реализовать Refresh Token rotation? В 2026 году в Django-сфере принято использовать `dj-rest-auth` или собственные реализации на базе `PyJWT`. Также стоит повторить разницу между `IsAuthenticated` и кастомными `BasePermission`, которые позволяют реализовывать сложную логику доступа (например, доступ только владельцу объекта или по подписке).

7. Кэширование: Стратегии и инвалидация

«Есть две сложные вещи в программировании: инвалидация кэша и именование переменных». На собеседовании вас обязательно спросят, как и что кэшировать в Django. Фреймворк поддерживает несколько уровней: кэширование всей страницы, кэширование вьюхи, фрагментарное кэширование в шаблонах и низкоуровневое кэширование через `cache.set/get`.

В качестве бэкенда для кэша в 2026 году повсеместно используется Redis 7+. Важно понимать разницу между стратегиями `Write-through` (записываем в кэш при обновлении БД) и `Cache-aside` (записываем в кэш при первом чтении). Самый сложный момент — инвалидация. Хороший ответ включает упоминание сигналов (`post_save`, `post_delete`) для очистки ключей кэша или использование версионирования ключей.

Redis как больше чем просто кэш

Современный Django-разработчик использует Redis не только для кэша, но и как брокер сообщений для Celery, хранилище сессий и даже для Rate Limiting (ограничение количества запросов). На интервью могут спросить про механизмы вытеснения данных в Redis (LRU, LFU). Вы должны понимать, что произойдет, если память Redis заполнится: какие данные удалятся первыми и как это повлияет на работу Django.

8. Фоновые задачи: Celery и Task Queues

Django — это синхронный фреймворк по своей природе (в контексте обработки одного HTTP-запроса), поэтому тяжелые задачи (отправка писем, генерация PDF, обработка видео) должны выноситься в фон. Celery — мощный, но сложный инструмент. Вопросы могут касаться настройки `CELERY_BEAT` для периодических задач, мониторинга через Flower и обработки ошибок (retries).

Важный нюанс: «Как избежать race condition при выполнении фоновой задачи?». Например, задача запустилась до того, как транзакция в основной БД была зафиксирована (commit). Решение: использовать `transaction.on_commit(task.delay)` или передавать в задачу только ID объекта, а не сам объект, чтобы в воркере загрузить актуальные данные из базы.

Альтернативы Celery в 2026 году

Для простых задач всё чаще используют `RQ` (Redis Queue) или встроенные в современные облачные платформы механизмы. Также стоит упомянуть `Dramatiq` как более современную и надежную альтернативу Celery с меньшим количеством «магических» настроек. На Senior-позициях могут спросить про шардирование очередей и приоритизацию задач (например, уведомления об оплате должны уходить быстрее, чем маркетинговая рассылка).

9. Тестирование в Django: Pytest vs Unittest

В 2026 году `pytest-django` де-факто стал стандартом. На собеседовании важно показать, что вы пишете тесты не «для галочки», а понимаете их ценность. Разница между `TestCase` и `TransactionTestCase` — классический вопрос. Первый оборачивает каждый тест в транзакцию и откатывает её (это быстро), второй очищает базу данных полностью (это медленно, но нужно для тестов, проверяющих поведение транзакций).

Использование фикстур (fixtures) в pytest позволяет создавать воспроизводимую среду для тестов. Также стоит упомянуть библиотеку `factory_boy` для генерации тестовых данных вместо использования хрупких фикстур в формате JSON (fixtures.json). Хороший разработчик знает, как измерить покрытие кода тестами (coverage) и почему 100% покрытие не гарантирует отсутствие багов.

Интеграционное и Unit-тестирование

Вы должны уметь объяснить разницу: Unit-тесты проверяют отдельную функцию или метод (с использованием Mock для внешних зависимостей), а интеграционные тесты проверяют взаимодействие нескольких компонентов (например, View + ORM + Database). В 2026 году также актуально тестирование асинхронного кода с помощью `pytest.mark.asyncio`, что требует особого подхода к управлению циклом событий в тестах.

10. Безопасность: OWASP Top 10 в контексте Django

Django славится своей безопасностью «из коробки», но её легко испортить. Как работает защита от SQL-инъекций в ORM? (Использование параметризованных запросов). Что такое CSRF-токен и почему он обязателен для POST-запросов? Как Django защищает от XSS? (Автоматическое экранирование в шаблонах).

В 2026 году особое внимание уделяется безопасности заголовков (HSTS, Content Security Policy) и защите сессий. Вопрос: «Как безопасно хранить пароли?». Ответ: Django использует PBKDF2 с хешированием SHA256 по умолчанию, но можно переключиться на Argon2, который более устойчив к перебору на GPU. Также важно знать настройки `SECURE_SSL_REDIRECT` и `SESSION_COOKIE_SECURE` для работы через HTTPS.

Аудит зависимостей

Безопасность — это не только код, но и библиотеки. На Senior-интервью могут спросить, как вы проверяете свой проект на уязвимости. Упоминание инструментов типа `safety` или `pip-audit` в CI/CD пайплайне будет большим плюсом. Также стоит знать про `Django Check Framework`, который проверяет настройки проекта на соответствие рекомендациям безопасности перед деплоем.

11. Базы данных за пределами PostgreSQL

Хотя PostgreSQL — «супруг» Django по умолчанию, современные системы часто используют полиглотное хранение (Polyglot Persistence). Как интегрировать MongoDB или Elasticsearch с Django? В 2026 году популярно расширение `django-elasticsearch-dsl` для полнотекстового поиска. Также часто обсуждается использование векторных баз данных (типа Pinecone или pgvector) для реализации RAG-систем (Retrieval-Augmented Generation) в связке с AI.

Разработчик должен понимать, как работают миграции в Django. Что делать, если миграция «зависла» на большой таблице (миллионы строк)? Ответ: использовать инструменты типа `django-pg-zero-downtime-migrations` или выполнять миграции вручную через `ALGORITHM=CONCURRENTLY` в PostgreSQL, чтобы не блокировать таблицу на чтение/запись.

Репликация и Database Routing

Для высоконагруженных систем используется разделение на Master (запись) и Slave (чтение) базы. Вы должны знать, как настроить `DATABASE_ROUTERS` в Django, чтобы автоматически направлять тяжелые `SELECT`-запросы на реплики, разгружая основную базу. Это стандартный вопрос для тех, кто претендует на роль архитектора или ведущего разработчика.

12. Деплой и инфраструктура (DevOps для Django)

В 2026 году грань между разработчиком и DevOps размыта. Как упаковать Django в Docker? Почему нельзя использовать `runserver` в продакшене (однопоточность, отсутствие безопасности)? Стандартная связка: Gunicorn/Uvicorn + Nginx. Вы должны понимать роль каждого компонента: Nginx отдает статику и терминирует SSL, Gunicorn управляет воркерами Python.

Вопросы по Twelve-Factor App: как хранить секреты (переменные окружения, HashiCorp Vault), как логировать (в stdout, чтобы Docker мог их собрать). В 2026 году Django часто запускается в Kubernetes, поэтому знание того, как работают `Liveness` и `Readiness` пробы для Django-приложения (например, через `django-health-check`), будет преимуществом.

Мониторинг и Observability

Как вы узнаете, что ваш сайт упал или тормозит? Упоминание Sentry для сбора ошибок, Prometheus и Grafana для метрик (время ответа, количество 5xx ошибок), и OpenTelemetry для трассировки запросов между микросервисами — это то, что отличает опытного инженера. Вы должны уметь объяснить, какие метрики наиболее важны для Django-приложения в продакшене.

Заключение: чек-лист подготовки

Подготовка к собеседованию по Django — это не зазубривание документации, а понимание принципов работы веб-технологий. В 2026 году ценится умение выбирать правильный инструмент под задачу: когда использовать асинхронность, когда выносить логику в микросервис, а когда достаточно стандартного монолита на Django.

Ваш план действий перед интервью:

• Повторите SQL и работу индексов — ORM не спасет без базовых знаний БД.
• Разберитесь с асинхронностью: напишите небольшое приложение на Django 5.1 с использованием `httpx` и `asyncio`.
• Просмотрите OWASP Top 10 и соотнесите каждый пункт с механизмами защиты Django.
• Освежите знания по смежным технологиям: Redis, Celery, Docker, PostgreSQL.
• Подготовьте пару кейсов из практики, где вы решали проблемы производительности или сложной архитектуры.

Мир Django продолжает развиваться, оставаясь надежным фундаментом для самых разных проектов. Удачи на собеседовании!