Django Interview Questions and Answers for Experienced Developers

Django interviews for experienced roles test whether you can build and operate web applications—not recite admin registration steps from memory.

A Python developer loop may stay language-heavy: decorators, GIL, asyncio, general algorithms.

A Django developer loop assumes solid Python and adds framework production depth:

See Python developer interviews for language prep; return here for Django-specific depth.

Take-home tasks may ask for a small DRF API with tests, pagination, and a README explaining trade-offs.

Keep one reference Django project (blog, orders API, or internal tool) you can whiteboard.

Django follows MVT: Model–View–Template.

The confusing part is the word View.

In many MVC frameworks, the Controller handles the request. In Django, that controller-like responsibility is handled by the view.

Typical flow:

URL pattern
→ Django view
→ model/service/ORM
→ template or JSON response

Example:

# urls.py
urlpatterns = [
    path("orders/<int:pk>/", views.order_detail, name="order-detail"),
]

# views.py
def order_detail(request, pk):
    order = Order.objects.get(pk=pk)
    return render(request, "orders/detail.html", {"order": order})

For API-only Django apps, templates may not be used much. A Django REST Framework app may use serializers and Response objects instead of HTML templates, but the high-level pipeline is still request → URL → view → response.

Important interview nuance:

• Models should not become a dumping ground for all business logic
• Views should not become huge “God functions”
• Complex business workflows often belong in service/domain layers
• Templates should avoid heavy database work

A strong answer is:

“Django’s MVT maps closely to MVC, but Django’s view acts like the controller. Models represent data, views handle request logic, and templates render presentation. For APIs, serializers often replace templates as the output-shaping layer.”

A weak answer says “URL goes to a view.” A strong answer traces the full request path.

Typical Django request lifecycle:

1. Web server receives the HTTP request
2. WSGI or ASGI server passes it to Django
3. Request enters middleware in the order listed in settings.MIDDLEWARE
4. URL resolver matches the path using ROOT_URLCONF
5. Django calls the matched view
6. View runs application logic, ORM queries, services, permissions, or forms
7. View returns an HttpResponse, JsonResponse, redirect, or DRF Response
8. Response travels back through middleware in reverse order
9. Server sends the final HTTP response to the client

Flow:

Client
→ web server
→ WSGI/ASGI server
→ middleware request phase
→ URL resolver
→ view
→ response object
→ middleware response phase
→ client

Example URL route:

urlpatterns = [
    path("orders/<int:pk>/", OrderDetailView.as_view(), name="order-detail"),
]

Important middleware order example:

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",
]

Why order matters:

Debugging examples:

A strong answer is:

“A request enters Django through WSGI or ASGI, passes through middleware, gets routed by URLconf to a view, and the response unwinds through middleware in reverse order. Middleware order matters for sessions, auth, CSRF, security, and custom cross-cutting logic.”

Middleware is Django’s global request/response hook system.

Each middleware wraps the view layer. It can:

• Inspect or modify the request before the view runs
• Return a response early without calling the view
• Inspect or modify the response after the view runs
• Handle cross-cutting concerns consistently

Common built-in middleware:

Custom production middleware examples:

Simple middleware shape:

class RequestIDMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        request.request_id = generate_request_id()

        response = self.get_response(request)

        response["X-Request-ID"] = request.request_id
        return response

Middleware behaves like an onion:

middleware A request phase
  middleware B request phase
    view
  middleware B response phase
middleware A response phase

Common mistakes:

• Putting middleware in the wrong order
• Doing heavy database queries for every request
• Swallowing exceptions without logging
• Adding tenant/auth logic too late
• Using middleware for feature-specific business logic
• Forgetting async compatibility in ASGI-heavy apps

Middleware should be used for cross-cutting concerns, not normal view-specific logic.

A strong answer is:

“Middleware wraps Django’s request/response cycle. I use it for cross-cutting concerns like security, sessions, auth, tracing, metrics, tenant resolution, and request IDs, while keeping feature-specific business logic in views or services.”

WSGI and ASGI are server interfaces used to run Django applications.

WSGI is enough for many Django apps because most traditional Django work is database-heavy and synchronous.

ASGI is useful when the app needs:

• Async views
• WebSockets
• Long-polling
• Server-sent events
• Many concurrent external API calls
• Django Channels
• Mixed HTTP and async protocols

Example async view:

async def health_check(request):
    data = await call_external_service()
    return JsonResponse({"status": data})

Important ORM warning:

Django supports async views, but you must be careful with synchronous ORM/database work inside async code.

Risky pattern:

async def user_detail(request, pk):
    user = User.objects.get(pk=pk)  # unsafe in async context
    return JsonResponse({"name": user.name})

Safer options:

• Keep ORM-heavy views synchronous
• Use async ORM methods where supported
• Use sync_to_async() carefully for sync ORM work
• Avoid wrapping huge DB-heavy code in async just for trendiness

Example bridge:

from asgiref.sync import sync_to_async

async def user_detail(request, pk):
    user = await sync_to_async(User.objects.get)(pk=pk)
    return JsonResponse({"name": user.name})

Interview nuance:

Do not say “ASGI is always faster.” It helps when you actually have non-blocking I/O. If your view mostly blocks on the synchronous ORM, async may add complexity without improving throughput.

A strong answer is:

“I use WSGI or sync views for typical ORM-heavy Django apps. I use ASGI when I need async I/O, WebSockets, or long-lived connections. I avoid calling blocking ORM code directly from async views unless I use the proper async APIs or bridging.”

Django models map Python classes to database tables, and the ORM lets you build SQL queries using Python objects.

A QuerySet is lazy. It represents a database query, but it usually does not hit the database until it is evaluated.

Example:

qs = Order.objects.filter(status="PAID").order_by("-created_at")

At this point, Django has built a query, but it has not necessarily executed SQL yet.

Common QuerySet evaluation triggers:

Example:

# Lazy
orders = Order.objects.filter(status="PAID")

# Evaluates
for order in orders:
    print(order.id)

QuerySets are chainable:

orders = (
    Order.objects
    .filter(status="PAID")
    .filter(total__gte=100)
    .select_related("customer")
)

Important caching behavior:

• The same evaluated QuerySet caches its results
• A new QuerySet clone runs a new query
• Calling .all() creates a new QuerySet
• Related manager calls can trigger extra queries
• Lazy evaluation can hide N+1 query bugs

Better count/existence patterns:

Order.objects.filter(status="PAID").count()
Order.objects.filter(status="PAID").exists()

Instead of:

len(Order.objects.filter(status="PAID"))
bool(Order.objects.filter(status="PAID"))

Interviewers like candidates who can connect QuerySet laziness to performance debugging.

Useful tools:

• Django Debug Toolbar
• connection.queries in development
• assertNumQueries() in tests
• Database logs
• QuerySet.explain() for query plans

A strong answer is:

“A QuerySet is a lazy, chainable SQL query description. It hits the database only when evaluated, so I pay attention to loops, serializers, templates, len(), bool(), and related-object access that can trigger hidden queries.”

null=True and blank=True work at different layers.

Example:

class Profile(models.Model):
    bio = models.TextField(blank=True)
    birth_date = models.DateField(null=True, blank=True)

Common patterns:

Why avoid null=True on strings?

Because you create two ways to represent “empty”:

NULL
""

That can complicate filters, uniqueness, validation, and API behavior.

Example problem:

Customer.objects.filter(nickname="")
Customer.objects.filter(nickname__isnull=True)

Now both may mean “no nickname.”

Use blank=True when form/admin/serializer validation should accept an empty value.

Use null=True when the database needs to represent missing value as SQL NULL.

Important nuance: Django REST Framework serializers have their own options such as allow_blank and allow_null, but the same idea applies: blank string and null are different states.

A strong answer is:

“null=True controls database NULL storage, while blank=True controls validation. I usually avoid null=True on string fields so I do not end up with both NULL and empty string representing the same thing.”

The N+1 problem happens when one query loads a list of objects and then one extra query runs for each object while accessing related data.

Example N+1:

orders = Order.objects.filter(status="PAID")

for order in orders:
    print(order.customer.name)  # extra query per order

If there are 100 orders, this can become:

1 query for orders
+ 100 queries for customers
= 101 queries

Use select_related() for single-valued relationships such as ForeignKey and OneToOneField.

orders = (
    Order.objects
    .filter(status="PAID")
    .select_related("customer")
)

select_related() uses SQL joins.

Use prefetch_related() for multi-valued relationships such as reverse ForeignKey and ManyToMany.

customers = Customer.objects.prefetch_related("orders")

prefetch_related() runs separate queries and joins the results in Python.

Filtered prefetch example:

from django.db.models import Prefetch

customers = Customer.objects.prefetch_related(
    Prefetch(
        "orders",
        queryset=Order.objects.filter(status="PAID"),
        to_attr="paid_orders",
    )
)

When not to prefetch blindly:

• Child relation is huge
• You only need a count
• You only need an aggregate
• You filter related objects differently later
• API pagination should happen before prefetching

Better alternatives in some cases:

Customer.objects.annotate(order_count=Count("orders"))

How to verify:

• Django Debug Toolbar
• assertNumQueries() in tests
• Database logs
• QuerySet.explain()

Common interview trap:

“Use select_related() everywhere.”

Wrong. It only works for single-valued relationships and can create huge joins if overused.

A strong answer is:

“N+1 happens when related objects are lazily loaded inside a loop. I use select_related() for FK/OneToOne joins, prefetch_related() for reverse and many-to-many relations, and verify with query counts instead of guessing.”

F() and Q() help push more logic into SQL instead of doing it in Python loops.

F() references a model field in the database.

Use it for:

• Atomic increments/decrements
• Comparing two columns
• Updating one field based on another
• Avoiding race-prone read-modify-write code

Example stock update:

from django.db.models import F

Product.objects.filter(pk=product_id, stock__gt=0).update(
    stock=F("stock") - 1
)

This is safer than:

product = Product.objects.get(pk=product_id)
product.stock -= 1
product.save()

The second version can lose updates under concurrency.

Q() builds complex boolean conditions.

Use it for:

• OR conditions
• NOT conditions
• Dynamic filters
• Combining optional search filters

Example:

from django.db.models import Q

orders = Order.objects.filter(
    Q(status="PAID") | Q(status="SHIPPED"),
    total__gte=100,
)

Negation:

Order.objects.filter(~Q(status="CANCELLED"))

Dynamic filter example:

query = Q()

if status:
    query &= Q(status=status)

if search:
    query &= Q(customer__name__icontains=search) | Q(reference__icontains=search)

orders = Order.objects.filter(query)

Comparison:

Important concurrency note:

F() helps avoid lost updates for simple field updates, but complex business transactions may still need transaction.atomic() and select_for_update().

A strong answer is:

“F() lets the database update or compare fields atomically without pulling values into Python. Q() lets me build OR, NOT, and dynamic filters cleanly. Both help keep filtering and updates in SQL.”

Transactions make multi-step database operations safe.

transaction.atomic() creates an all-or-nothing block:

from django.db import transaction

with transaction.atomic():
    order = Order.objects.create(customer=customer)
    Payment.objects.create(order=order, amount=order.total)

If an exception occurs inside the block, Django rolls back the transaction.

Use transactions for:

• Money transfer
• Inventory decrement + order creation
• Multi-table writes
• State transitions
• Operations that must not be partially saved

select_for_update() locks selected rows until the transaction finishes.

Example:

@transaction.atomic
def reserve_stock(product_id, quantity):
    product = (
        Product.objects
        .select_for_update()
        .get(pk=product_id)
    )

    if product.stock < quantity:
        raise OutOfStock()

    product.stock -= quantity
    product.save(update_fields=["stock"])

This prevents two requests from reading the same stock value and overselling.

transaction.on_commit() runs a callback only after the outer transaction successfully commits.

Use it for side effects:

• Send email
• Enqueue Celery task
• Invalidate cache
• Publish event
• Call external service

Example:

def create_order(request):
    with transaction.atomic():
        order = Order.objects.create(...)

        transaction.on_commit(
            lambda: send_receipt.delay(order.id)
        )

Why this matters:

If you enqueue a Celery task before commit, the worker may run before the row is committed and fail to find the object.

Bad pattern:

with transaction.atomic():
    order = Order.objects.create(...)
    send_receipt.delay(order.id)  # worker may run too early

Good pattern:

with transaction.atomic():
    order = Order.objects.create(...)
    transaction.on_commit(lambda: send_receipt.delay(order.id))

Important interview nuance:

• Keep transactions short
• Avoid slow network calls inside transactions
• Lock rows in a consistent order to reduce deadlocks
• Use database constraints too, not only application checks
• select_for_update() behavior depends on database support and isolation level
• Catch database exceptions outside the atomic block when possible

A strong answer is:

“I use atomic() for all-or-nothing writes, select_for_update() to lock rows when concurrent updates can race, and on_commit() for side effects like Celery tasks so workers only see committed data.”

Django migrations are versioned database schema changes.

They are generated from model changes and stored as Python files in each app’s migrations/ directory.

Common commands:

Example:

python manage.py makemigrations
python manage.py migrate
python manage.py showmigrations
python manage.py migrate --plan

Migrations are like version control for schema. They should be reviewed, tested, and deployed carefully.

Safe production migration principles:

Expand-contract example:

1. Add nullable column
2. Deploy code that writes both old and new fields
3. Backfill old rows in batches
4. Deploy code that reads new field
5. Add NOT NULL/unique constraint later
6. Remove old column after safe window

Risky migration examples:

• Add non-null field with default on huge table
• Rename column while old code still reads old name
• Drop column before all app versions stop using it
• Run large data migration in one transaction
• Add index during peak traffic
• Run migration without backup/rollback plan

Useful CI checks:

python manage.py makemigrations --check --dry-run
python manage.py migrate --plan
python manage.py test

Operational advice:

• Run migrations before or during deploy based on compatibility
• Make migrations safe for rolling deploys
• Coordinate app and worker releases
• Check migration duration in staging
• Monitor DB locks, errors, and latency
• Keep backups before risky schema changes

Common interview mistake:

“Just run migrate before deployment.”

For small apps, that may be fine. For large production tables, safe migration design matters more than the command.

A strong answer is:

“Django migrations are versioned schema changes. I deploy them safely with backward-compatible steps, expand-contract changes, batched backfills, lock-aware operations, and CI checks like makemigrations --check --dry-run and migrate --plan.”

Experienced guidance:

• FBV for one-off admin tools or complex branching
• CBV/ViewSets for consistent CRUD with permissions and pagination
• Keep views thin—move rules to services or selectors

class OrderListView(ListView):
    model = Order
    paginate_by = 25

A strong answer is:

I pick FBVs for clarity on small endpoints and DRF ViewSets for API resources, but business logic lives in services—not in view methods regardless of style.

ROOT_URLCONF points to your root urls.py. Patterns map paths to views:

from django.urls import path, include

urlpatterns = [
    path("api/v1/orders/", include("orders.urls", namespace="orders")),
    path("health/", health_check),
]

API versioning: URL prefix (/api/v1/), Accept header, or subdomain—pick one and document for clients.

A strong answer is:

URLs are explicit maps from paths to callables; I use include and namespaces so apps stay modular and reverse() stays stable when paths change.

Django templates use auto-escaping by default—HTML from variables is escaped unless marked safe.

XSS risk returns when you use |safe or mark_safe() on user content—interviewers want you to justify every safe mark.

For SPAs, templates matter less; DRF serializers become the presentation layer—validation and field exposure rules apply there instead.

A strong answer is:

Templates auto-escape output; I never mark user-controlled strings safe, and I keep presentation in templates or serializers—not mixed into ORM models.

As projects grow, fat views and fat models become hard to test. A service layer (or selectors for reads) centralizes business rules:

views.py      → HTTP, permissions, input/output
services.py   → business transactions, orchestration
selectors.py  → complex read queries (optional)
models.py     → fields, constraints, small methods

Benefits:

• One place for transaction.atomic() and domain rules
• Reuse from management commands, Celery tasks, and admin actions
• Unit test without HTTP request factory

Anti-pattern: hiding business logic in signals—hard to trace; prefer explicit service calls.

A strong answer is:

Views stay thin; services own transactions and domain rules so the same logic runs from APIs, tasks, and management commands with one test suite.

Deployment checklist:

python manage.py check --deploy

Must-know production settings:

• DEBUG=False
• Strong SECRET_KEY from environment
• SECURE_SSL_REDIRECT, HSTS when behind HTTPS
• Least-privilege database user

A strong answer is:

Django ships secure defaults, but I still run check --deploy, keep DEBUG off, configure ALLOWED_HOSTS, and never bypass ORM parameterization with string-concatenated raw SQL.

Session-cookie auth from a SPA requires CSRF awareness:

Also configure CORS (django-cors-headers) for allowed origins—see full stack interviews.

CSRF_TRUSTED_ORIGINS must include your frontend origin in Django 4+.

A strong answer is:

If the browser sends session cookies, I use CSRF tokens on unsafe methods; for token-in-header APIs I focus on CORS and never store JWTs in cookies without a CSRF strategy.

Split settings modules instead of one giant settings.py:

config/
  settings/
    base.py      # INSTALLED_APPS, middleware, shared config
    dev.py       # DEBUG=True, local DB
    staging.py
    production.py  # security flags, logging, caches

# manage.py or wsgi.py
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.settings.production")

A strong answer is:

I inherit from a base settings module and override per environment, loading secrets from the platform—not from git—and I keep DEBUG and ALLOWED_HOSTS strict in production.

Authentication answers who is the user (request.user).

Authorization answers what they may do—at URL level or per object.

Implement object checks in:

• DRF has_object_permission on custom permission classes
• Service layer guards before mutations
• QuerySet filtering — Order.objects.filter(owner=request.user) so unauthorized rows do not appear

Never rely on hiding UI alone—enforce on the server.

A strong answer is:

Authentication identifies the user; authorization filters QuerySets and checks object permissions before any update—defense in depth, not security by obscurity.

Avoid heavy DB work in middleware—it runs on every request including static and health checks.

A strong answer is:

Middleware is for global cross-cutting hooks; permissions and services handle authz and business rules closer to the domain.

Serializers convert between Django models/querysets and JSON (validation, nested relations, write paths).

Pitfalls:

class OrderSerializer(serializers.ModelSerializer):
    class Meta:
        model = Order
        fields = ["id", "status", "total", "customer_id"]
        read_only_fields = ["id"]

A strong answer is:

Serializers define API contracts and validation; I optimize queryset fetching for nested data and keep write paths thin by calling services inside create/update.

ViewSets bundle CRUD actions (list, retrieve, create, …). Routers register URL patterns automatically:

router = DefaultRouter()
router.register(r"orders", OrderViewSet, basename="order")

Use @action(detail=True, methods=["post"]) for sub-resource operations on a ViewSet.

A strong answer is:

ViewSets plus routers speed up consistent CRUD APIs; for odd endpoints I use APIView or @action rather than forcing everything into list/retrieve semantics.

Cursor pagination avoids expensive OFFSET on huge tables—aligns with SQL pagination guidance.

Always allowlist filter and order fields—prevent sorting by arbitrary columns (DoS vector).

A strong answer is:

I paginate every list endpoint, allowlist filters and ordering, and throttle public APIs to protect the database from scrape or abuse.

Production notes:

• Prefer short-lived access + refresh tokens for JWT
• Store refresh tokens securely; support revocation
• Combine with permission classes and object checks

A strong answer is:

I pick session auth for same-site apps and JWT for SPA/mobile APIs, always pairing authentication with permissions and object-level checks—not open endpoints after login.

Strategies:

Experienced practice:

• Deprecate with sunset headers and changelog
• Maintain serializers per version when shapes diverge
• Do not break v1 clients when adding v2—run both during migration

A strong answer is:

I version in the URL or Accept header, document deprecation timelines, and keep old serializers until clients migrate—never silently change field meaning.

Django recommends customizing early:

class User(AbstractUser):
    department = models.CharField(max_length=64, blank=True)

Set AUTH_USER_MODEL before first migrate—changing later is painful.

A strong answer is:

I use AbstractUser or AbstractBaseUser before the first migration and set AUTH_USER_MODEL so auth and foreign keys stay consistent.

Hybrid: session for admin, JWT for public API—justify operational cost.

A strong answer is:

Sessions give server-controlled logout for browser apps; JWT suits distributed APIs if I handle expiry, rotation, and revocation explicitly.

Admin is powerful for internal ops—not a public API.

Security: restrict admin URL, use staff flag + MFA, never expose admin on public internet without VPN/IP allowlist.

A strong answer is:

Admin is for trusted operators—I customize list views and permissions, lock it behind network controls, and never treat it as the customer-facing API.

Django's auth model provides permissions (app_label.action_modelname) and groups that bundle permissions.

Experienced teams often outgrow default perms and add role tables or external IAM—but know the built-ins for interview baselines.

A strong answer is:

Groups bundle model permissions for RBAC; for fine-grained APIs I combine Django permissions with object-level checks or a dedicated roles model.

pytest-django provides fixtures and database handling:

import pytest

@pytest.mark.django_db
def test_create_order(api_client, user):
    api_client.force_authenticate(user=user)
    response = api_client.post("/api/v1/orders/", {"sku": "A1"}, format="json")
    assert response.status_code == 201

Prefer fast tests: many unit/service tests, fewer full-stack; use pytest.mark.django_db(transaction=True) when testing on_commit.

A strong answer is:

I use pytest-django with factories for data, APIClient for HTTP contracts, and assertNumQueries on hot list endpoints to catch ORM regressions.

Most experienced loops want you to test service layer without HTTP when rules are complex—faster and clearer failures.

A strong answer is:

APIClient for HTTP integration, direct service tests for business rules, live server only for true E2E—keep the pyramid mostly fast unit and integration tests.

Invalidation is the hard part:

• Key by object version or TTL
• cache.delete on save signals—prefer explicit invalidation in services over scattered signals

from django.core.cache import cache

def get_dashboard_stats(user_id):
    key = f"dashboard:{user_id}"
    data = cache.get(key)
    if data is None:
        data = compute_stats(user_id)
        cache.set(key, data, timeout=300)
    return data

A strong answer is:

I cache expensive reads in Redis with explicit keys and TTLs, invalidate on writes in the service layer, and measure hit rate—not cache by default without profiling.

Signals (post_save, pre_delete, …) decouple side effects from save paths.

Problems signals cause:

• Implicit execution order
• Hard to test and trace
• Run inside same DB transaction—failures roll back saves unexpectedly

Prefer explicit service methods for critical workflows.

A strong answer is:

Signals are for loose coupling at framework boundaries; I avoid them for business logic and use services plus on_commit for side effects I need to reason about in tests.

Management commands (python manage.py my_command) run admin tasks:

Structure with BaseCommand, add_arguments, and idempotent design. Long jobs: log progress, support --dry-run, wrap in transaction.atomic() per batch.

A strong answer is:

Management commands are my tool for batch ops and cron—they are idempotent, log clearly, and batch database work instead of loading everything into memory.

Celery runs async tasks in worker processes—broker (Redis/RabbitMQ) holds the queue.

@shared_task(bind=True, max_retries=3)
def send_receipt(self, order_id):
    try:
        order = Order.objects.get(pk=order_id)
        mail.send(order)
    except Exception as exc:
        raise self.retry(exc=exc, countdown=60)

Monitor queue depth, worker memory, and task failure rates.

A strong answer is:

Celery handles async side effects—I enqueue by ID after commit, cap retries with backoff, and monitor queues so email or report jobs never block web workers.

Never serve user uploads from Django workers at scale—use object storage + signed URLs.

collectstatic in CI/CD before deploy; cache-bust with hashed filenames (ManifestStaticFilesStorage).

A strong answer is:

Static assets go to CDN or Whitenoise after collectstatic; user media lives in object storage with signed URLs—not on app server disks.

Django 5.x continues improving async ORM methods (aget, acreate, async for), but the ORM is not fully non-blocking:

Use sync views + gunicorn workers unless profiling proves async I/O wins.

A strong answer is:

Async views help for external I/O; ORM-heavy endpoints stay sync or use sync_to_async deliberately—I profile before adopting ASGI for CRUD APIs.

Typical container layout:

# Simplified pattern
CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000", "--workers", "4"]

Health check endpoint (not admin)—wire to load balancer. Run check --deploy in CI.

Pair with Git interview questions for release workflow stories.

A strong answer is:

I containerize web and worker processes separately, run migrations as a deploy step, put Gunicorn behind a reverse proxy, and expose a health check for the load balancer.

Common root causes: N+1, missing index, unbounded queryset, synchronous external HTTP in serializer.

A strong answer is:

I measure query count and SQL time first, fix ORM fetching and pagination, then cache or denormalize only after profiling proves the bottleneck.

Options (often combined):

updated = Product.objects.filter(pk=sku, stock__gt=0).update(stock=F("stock") - 1)
if updated == 0:
    raise OutOfStock()

Avoid application-level read-then-write without locking under concurrency.

A strong answer is:

I use atomic updates with F() or row locks, enforce non-negative stock in the database, and return clear errors when the update count is zero.

Common mature layout:

project/
  config/           # settings, urls, wsgi
  apps/
    orders/
      models.py
      services.py
      selectors.py
      api/
        serializers.py
        views.py
        urls.py
      tests/
    users/
  common/           # shared utilities, exceptions

Principles:

• Apps by bounded context—not by technical layer only
• api/ package per app for DRF surface
• Avoid circular imports—services call repositories/selectors, not views
• Shared exception handler for consistent API errors

A strong answer is:

I split by domain apps with services and API packages inside each, keep settings and URLs centralized, and enforce boundaries so imports flow inward—not views importing across domains chaotically.

Checklist:

• Draw request lifecycle with middleware order
• Explain N+1 fix on a real serializer with prefetch_related
• Walk through transaction.atomic + on_commit + Celery
• Recite security checklist — CSRF, XSS, DEBUG, ALLOWED_HOSTS, check --deploy
• DRF story — pagination, auth, object permissions, versioning
• One migration war story — backward compatible rollout
• One performance win — query count before/after
• Python fundamentals refresh — decorators, GIL, asyncio limits
• SQL — indexes and EXPLAIN

Behavioral: STAR story for production incident (runaway query, failed task queue, bad deploy).

A strong answer is:

I rehearse one Django system end to end—ORM, DRF, workers, deploy—and tie every answer to production experience with metrics, not tutorial definitions.