25 Django interview questions

Listen for: A strong junior candidate starts with reproducing the issue locally, checking the Django Debug Toolbar or query logs, and looking for N+1 queries. They should mention select_related for single-valued relationships, prefetch_related for many-valued relationships, limiting fields only when useful, and confirming the improvement with tests or query counts.

Red flag: They suggest adding caching first without checking the generated SQL or query count.

Listen for: Listen for safe incremental thinking: add the field with a default or nullable phase, backfill existing rows if needed, then tighten constraints once data is valid. They should understand Django migrations are code, know how to inspect generated migrations, and consider rollback, large tables, and coordination with deployed application code.

Red flag: They assume every migration can be run in one step because Django generated it.

Listen for: They should describe testing request validation, permissions, response status, database side effects, and email behavior using Django's test client, DRF APIClient, or pytest-django. Good answers avoid hitting real external services, use locmem email backend or mocks, and include both success and failure cases.

Red flag: They only test that the endpoint returns 200 and ignore permissions, validation, and side effects.

Listen for: Look for separation of concerns: field-level checks in form or serializer validation, model constraints for rules that must always hold, and database constraints for integrity. They should understand that client-side validation is only convenience and that validation needs clear error messages and tests around edge cases.

Red flag: They put all validation in the view because it feels simpler.

Listen for: A good answer covers permissions, list_display and search_fields for usability, query performance for changelists, readonly_fields for sensitive data, auditability, and avoiding unsafe custom actions. They should know Django admin is powerful but not automatically appropriate for every internal workflow.

Red flag: They treat staff access as equivalent to unrestricted production database access.

Listen for: They should ask what object is missing, inspect the URL parameters and query assumptions, reproduce with relevant data, and handle expected absence with get_object_or_404 or explicit error handling. Strong answers mention permissions, race conditions, deleted records, logging useful context, and adding a regression test.

Red flag: They wrap the whole view in a broad `except Exception` and return a generic success response.

Listen for: Strong candidates explain trade-offs rather than a rigid rule. They keep views thin, put persistence invariants near models and constraints, use managers/querysets for reusable database access, and use service functions for workflows that touch several models or external systems. They also mention testability and avoiding serializers becoming transaction scripts.

Red flag: They insist on one pattern for all logic regardless of complexity or team conventions.

Listen for: Listen for idempotency keys, database uniqueness constraints, state transitions, transaction.atomic, select_for_update where appropriate, and separating external calls from local commits carefully. They should discuss retries, timeouts, task acknowledgments, and storing provider response IDs so duplicate executions do not duplicate charges or corrupt invoice state.

Red flag: They say Celery tasks should never run twice, so duplicate handling is unnecessary.

Listen for: A strong answer checks whether the change actually reduces query time, memory, or serialization cost and whether it breaks model methods, deferred field access, or type expectations. They should compare with select_related, prefetch_related, annotations, indexes, and pagination, and ask for query plans or benchmarks when the path is hot.

Red flag: They assume `.only()` is always faster without considering deferred queries or maintainability.

Listen for: Look for tenant scoping at the queryset level, not just post-fetch checks. They should discuss DRF permission classes, filtering by organization membership, avoiding IDOR bugs, tests for cross-tenant access, database constraints, and possibly row-level security if the risk profile justifies it.

Red flag: They rely on hiding unauthorized objects in the frontend.

Listen for: They should mention locking, transaction size, batching, resumability, observability, and whether the backfill should run outside the schema migration. Good answers include deploying compatible code first, using RunPython carefully, avoiding model methods that may change later, and validating results before enforcing non-null or unique constraints.

Red flag: They put a long Python loop inside a single migration transaction with no batching or monitoring.

Listen for: Strong answers use environment-based configuration with typed parsing where useful, secret management outside source control, safe defaults, and explicit settings for allowed hosts, CSRF trusted origins, databases, caches, email, logging, and debug mode. They should mention tests that prevent unsafe production settings and clear local onboarding.

Red flag: They commit production secrets to `settings.py` or depend on developers manually editing files.

Listen for: They should profile serialization and database access separately, inspect query counts, use select_related/prefetch_related or Prefetch objects, add indexes where needed, and review pagination. They may consider denormalized read models, caching, or simpler serializers, but should validate the bottleneck before breaking API contracts.

Red flag: They immediately remove fields from the API without measuring or considering compatibility.

Listen for: Look for incremental strategy: map domains, stabilize tests, define conventions, isolate high-change areas, improve observability, and pay down painful coupling as part of feature work. Strong candidates discuss architectural seams, migration plans, team alignment, and when extracting services is justified versus when a modular monolith is better.

Red flag: They propose rewriting the application into microservices before understanding domain boundaries and failure modes.

Listen for: They should describe expand-and-contract migrations, backwards-compatible code, avoiding long locks, adding nullable columns before enforcing constraints, concurrent index creation for PostgreSQL, feature flags, and deploy ordering. Strong answers include rollback limitations, migration observability, and coordination between application instances during rolling deploys.

Red flag: They assume running `manage.py migrate` during deploy is always safe and instantly reversible.

Listen for: Strong candidates ask what is cached, key design, TTLs, invalidation paths, transaction timing, and whether replicas or async tasks are involved. They discuss cache-aside versus write-through, versioned keys, selective invalidation, dogpile protection, and when correctness should favor database reads over cache hits.

Red flag: They only lower the TTL and consider the issue solved.

Listen for: They should know signals can decouple simple local reactions but often hide control flow, complicate transactions, and surprise tests. Good answers compare explicit service orchestration, domain events, outbox patterns, and Celery tasks. They also mention using transaction.on_commit when side effects depend on committed data.

Red flag: They use signals for every side effect because it keeps views and models short.

Listen for: Listen for reading release notes and deprecation timelines, upgrading dependencies first, running tests with warnings treated seriously, checking middleware, async behavior, templates, database backends, and authentication changes. Strong answers use CI matrices, incremental pull requests, staging verification, and clear rollback plans.

Red flag: They change the version pin and fix failures only after production breaks.

Listen for: They should capture the SQL, use EXPLAIN ANALYZE, inspect indexes, row estimates, joins, sort operations, and generated subqueries. Strong answers compare ORM readability against raw SQL or database views, consider materialized data for hot paths, and verify improvements with realistic data rather than small fixtures.

Red flag: They keep adding indexes randomly without looking at the query plan.

Listen for: A senior answer separates representation, validation, filtering, and query planning. They watch for serializers triggering hidden queries, filters exposing expensive operations, and duplicated authorization logic. They may introduce explicit read serializers, service/query modules, schema documentation, and compatibility policies without over-engineering simple endpoints.

Red flag: They let each endpoint evolve independently with no shared permission, filtering, or response conventions.

Listen for: Strong answers compare shared-schema tenant keys, schema-per-tenant, and database-per-tenant approaches. They should cover tenant scoping in managers/querysets, middleware, permissions, unique constraints including tenant IDs, background tasks, admin safety, tests for cross-tenant access, and optional PostgreSQL row-level security for defense in depth.

Red flag: They rely on passing `organization_id` from the client and trusting it throughout the stack.

Listen for: Look for direct-to-object-storage uploads or streamed handling, model state transitions, Celery or a managed queue, chunked parsing, idempotent tasks, progress tracking, error reporting, and transaction boundaries. Strong answers discuss file type validation, size limits, antivirus or content scanning if required, and not blocking web workers.

Red flag: They parse the whole file synchronously inside the request and store it in memory.

Listen for: They should capture actor, timestamp, source, object identity, before/after values where appropriate, request correlation ID, and reason fields for sensitive actions. Strong answers discuss immutable append-only storage, privacy concerns, admin actions, bulk updates, service-level logging, and querying audit records without coupling every model too tightly.

Red flag: They only enable default application logs and assume that is an audit trail.

Listen for: Strong answers separate transactional writes from reporting reads when needed, using optimized ORM queries, indexes, denormalized summary tables, materialized views, or a warehouse export depending on freshness needs. They cover permissions, pagination, asynchronous exports, query timeouts, and preventing arbitrary filters from hurting the primary database.

Red flag: They build one unrestricted admin-style query endpoint directly against production tables.

Listen for: Listen for a notification model, user preferences, event generation after transaction commit, channel-specific delivery workers, idempotency, retry handling, and unread state. Strong candidates compare Django Channels/WebSockets, Server-Sent Events, polling, and external push providers, and avoid coupling notification delivery to request latency.

Red flag: They send every notification synchronously from the view before returning the response.