Top 60 Django Interview Questions (2026)

Django is a high-level Python web framework that ships with an ORM, an admin site, authentication, forms, and security defaults built in. It handles the plumbing every web app needs so you write features instead of boilerplate.

It solves the repetitive parts of web development: mapping URLs to code, talking to a database without hand-writing SQL, rendering HTML, validating input, and blocking common attacks. That's why a small team can ship a real product fast.

MVT is Model, View, Template. The Model defines your data and talks to the database, the View holds the request-handling logic and decides what data to return, and the Template renders that data into HTML.

It's Django's take on MVC. The framework itself plays the controller role by routing incoming URLs to the right view, so you write models, views, and templates and let Django wire them together.

A project is the whole website: settings, the root URL config, and the collection of apps that make it up. An app is a self-contained module that does one thing, like a blog, a payments feature, or user accounts.

One project holds many apps, and a well-written app can be reused across projects. Keeping features in separate apps is how Django codebases stay organized as they grow.

The ORM (object-relational mapper) lets you work with the database using Python classes and objects instead of writing SQL. A model class maps to a table, an instance maps to a row, and methods like filter() and get() build the queries for you.

You use it because it's faster to write, portable across databases (SQLite, PostgreSQL, MySQL), and safe by default: queries are parameterized, so ordinary use won't expose you to SQL injection.

You subclass django.db.models.Model and declare each column as a class attribute using a field type: CharField for short text, TextField for long text, IntegerField, DateTimeField, ForeignKey for relations, and so on. Django reads those fields to build the table.

Each field takes options like max_length, null, blank, default, and unique. Once the model is defined, makemigrations and migrate create the matching table.

Migrations turn changes in your models into versioned, ordered database schema changes. They keep your Python models and the actual database structure in sync, and they're stored as files so the whole team applies the same changes.

makemigrations reads model changes and writes migration files; migrate applies pending migrations to the database. showmigrations lists what's applied, and sqlmigrate prints the SQL a migration will run.

A view is the code that takes a web request and returns a web response. Function-based views (FBVs) are plain functions that receive the request and return an HttpResponse. Class-based views (CBVs) are classes that map HTTP methods to methods like get() and post() and offer reusable generic views.

FBVs are explicit and easy to read for simple logic. CBVs shine when you want the built-in generic views (ListView, DetailView, CreateView) to remove repetitive create/read/update/delete code.

Django matches an incoming path against a list of URL patterns defined with path() or re_path() in a urls.py. The first pattern that matches wins, and Django calls the view attached to it, passing any captured parameters.

Projects usually keep a root urls.py that includes each app's urls.py with include(), so routing stays modular. Naming a pattern lets you reverse it with reverse() or the {% url %} template tag instead of hardcoding paths.

The Django template language (DTL) renders HTML from context data using {{ variables }}, {% tags %} for logic like loops and conditionals, and filters like {{ name|upper }} to transform values. It's deliberately limited so presentation logic stays in templates and real logic stays in Python.

Templates support inheritance: a base template defines blocks, and child templates override them, which keeps shared layout in one place.

The Django admin is an auto-generated web interface for managing your data. Register a model and you get create, read, update, and delete screens for it, with search, filters, and permissions, without writing any of that UI yourself.

It's genuinely useful for internal tools, content management, and early-stage debugging. You customize it with ModelAdmin classes to control which fields show, how they're filtered, and who can access them.

settings.py holds a project's configuration in one place: the database connection, INSTALLED_APPS, the MIDDLEWARE chain, template directories, static and media settings, the SECRET_KEY, the DEBUG flag, ALLOWED_HOSTS, and the time zone. Django reads it at startup to wire everything together.

In production you split or override settings per environment and pull secrets from environment variables, never hardcoding them. DEBUG must be False in production, and the SECRET_KEY must stay out of version control.

all() returns every row as a queryset. filter() returns a queryset of rows matching the conditions, which may be zero, one, or many. get() returns exactly one object and raises DoesNotExist if none match or MultipleObjectsReturned if more than one does.

Use get() when you expect a single, unique result (usually by primary key), and filter() when you expect a set. Wrapping get() in a try/except, or using get_object_or_404, is the safe pattern.

Static files are assets that ship with your code and don't change per user: CSS, JavaScript, images that are part of the design. Media files are user-uploaded content: profile pictures, document attachments, anything submitted at runtime.

Django serves them through different settings (STATIC_URL and STATICFILES for static, MEDIA_URL and MEDIA_ROOT for media). In production a web server or CDN serves static files, and media usually lives in object storage.

Building a queryset runs no SQL. Django waits until you actually need the data, then evaluates the query. So you can chain filter().exclude().order_by() and only one query fires, when the result is consumed.

Evaluation happens when you iterate the queryset, call list() or len(), slice to a single index, or test it in a boolean context. Understanding this explains why chaining is cheap and why a stray len() can trigger an unwanted query.

Cross-site request forgery tricks a logged-in user's browser into sending a state-changing request to your site from a malicious page. Django's CsrfViewMiddleware defends against it by requiring a secret token on POST, PUT, PATCH, and DELETE requests.

In templates you add {% csrf_token %} inside forms; Django checks the submitted token against the one tied to the session. Requests without a valid token are rejected with a 403.

A Form class declares fields with their types and validation rules. Django renders those fields to HTML, and on submission it validates the data: form.is_valid() runs the checks and populates form.cleaned_data with typed, safe values.

ModelForm builds a form directly from a model, so you don't repeat field definitions and can call form.save() to write to the database. Forms centralize validation and protect against bad input.

null=True controls the database: it allows the column to store NULL. blank=True controls validation: it allows forms and the admin to accept an empty value. They live at different layers.

For text-based fields (CharField, TextField) the convention is to use blank=True but not null=True, because Django stores an empty string rather than NULL for missing text, which avoids two ways to represent no value.

WSGI and ASGI are the interfaces between a Django app and the server that runs it. WSGI is the older synchronous standard; ASGI is the newer one that also supports asynchronous views, WebSockets, and long-lived connections.

Django generates a wsgi.py and an asgi.py in every project. You run the app behind a server like Gunicorn (WSGI) or Uvicorn/Daphne (ASGI) in production; the built-in runserver is for development only.

The Django shell is an interactive Python session with your project's settings and models loaded. You start it with python manage.py shell, then import models and run queries, test ORM calls, or inspect data directly.

It's the fastest way to experiment with querysets, reproduce a bug, or check what SQL a query generates before you put it in code. shell_plus from django-extensions auto-imports your models to save typing.

ForeignKey models a many-to-one relation: many books belong to one author. ManyToManyField models a many-to-many relation: a book can have many tags and a tag many books, which Django backs with a join table. OneToOneField models a strict one-to-one link, often used to extend another model.

Pick the field that matches the real-world cardinality. A profile that extends a user is one-to-one; a book's author is many-to-one; a book's tags are many-to-many.

render() combines a template with a context dictionary and returns an HttpResponse containing the rendered HTML in one step, so you don't build the response by hand. redirect() returns an HTTP redirect response that sends the browser to another URL, a view name, or a model's absolute URL.

The pattern to remember is redirect after a successful POST, so a page refresh doesn't resubmit the form. Use render() to show a page and redirect() to move the user after an action.

Both cut down database queries when you access related objects, but they work differently. select_related follows single-valued relations (ForeignKey, OneToOne) with a SQL JOIN, pulling the related rows in one query. prefetch_related handles multi-valued relations (reverse ForeignKey, ManyToMany) by running a second query and joining the results in Python.

Reach for select_related on to-one relations and prefetch_related on to-many relations. Using neither on a loop that touches related objects is the classic N+1 query bug.

N+1 happens when you fetch a list of objects with one query, then trigger a separate query for each object's related data inside a loop. A page showing 100 books plus each author fires 1 query for the books and 100 for the authors: 101 queries where 1 or 2 would do.

The fix is to tell the ORM up front what you'll need: select_related for to-one relations, prefetch_related for to-many. Tools like Django Debug Toolbar or logging the queries reveal N+1 fast.

Middleware is an ordered chain of components that wrap the view. On the way in, each middleware can inspect or modify the request; on the way out, each can inspect or modify the response. Django's own auth, session, CSRF, and security features are middleware.

You write custom middleware for cross-cutting concerns that apply to many views: request timing, adding headers, tenant resolution, or rate limiting. Order in the MIDDLEWARE list matters because it defines the wrapping sequence.

Signals let one part of your code notify another when something happens, without the two being directly coupled. Built-in signals include pre_save, post_save, pre_delete, and post_delete on models, plus request-lifecycle signals.

Use them for genuinely decoupled side effects: creating a profile when a user is created, invalidating a cache when a record changes. The caution: signals hide control flow, so for logic tied to one place, an explicit call or a model save() override is clearer.

aggregate() collapses a whole queryset into a single dictionary of computed values: total count, average price, max date. annotate() adds a computed value to each row of the queryset, so each object carries its own aggregate.

Use aggregate() for one summary number over the set, and annotate() when you need a per-object figure, like each author with their book count. annotate() commonly pairs with values() and group-by behavior.

Q objects build complex query conditions with OR, AND, and NOT, which plain keyword filters can't express because keyword arguments only combine with AND. You wrap conditions in Q() and join them with | and &.

F expressions reference a model field's value inside a query or update, so the database does the arithmetic without loading the value into Python. That makes field-to-field comparisons and atomic increments possible.

By default each query autocommits. To group operations so they succeed or fail together, wrap them in transaction.atomic() as a context manager or decorator: if any operation inside raises, the whole block rolls back.

You can also set ATOMIC_REQUESTS to wrap each request in a transaction. For long operations, use select_for_update() to lock rows and avoid lost updates under concurrency.

Authentication verifies who a user is: Django's auth system handles login, logout, password hashing (PBKDF2 by default), and sessions, exposing request.user. Authorization decides what that user can do: the permissions and groups framework, plus checks like login_required and permission_required.

You extend the default User model when you need extra fields, using a custom user model set early via AUTH_USER_MODEL. For APIs, Django REST Framework layers token, session, or JWT authentication on top.

Django stores a session ID in a cookie on the client and keeps the actual session data server-side, keyed by that ID. By default the data lives in the database, but you can back sessions with the cache, files, or signed cookies.

You read and write session data through request.session, which behaves like a dict. Sessions carry things like the logged-in user and short-lived flags across requests without exposing the data to the browser.

A manager is the interface through which models run queries; objects is the default one. A custom manager lets you add reusable query methods or change the default queryset, so common filters live in one place instead of being repeated across views.

A frequent use is a manager that returns only published or active records, so callers write Article.published.all() instead of remembering the filter every time.

Django has a layered cache framework. The per-site and per-view caches store whole responses; the low-level cache API (cache.get, cache.set) stores arbitrary values; and template fragment caching stores parts of a page. Backends include Redis, Memcached, the database, and local memory.

The rule is cache the expensive and stable, and invalidate deliberately. Cache keys, timeouts, and a plan for busting stale entries matter more than the backend choice.

Django REST Framework (DRF) is the standard toolkit for building web APIs on top of Django. It adds serializers, viewsets, routers, authentication classes, and a browsable API. A serializer converts model instances and querysets into JSON for responses and validates and converts incoming JSON back into Python objects.

ModelSerializer generates fields directly from a model, similar to how ModelForm works. It handles both directions: serialization out and validated deserialization in.

A viewset groups the logic for a set of related endpoints (list, retrieve, create, update, destroy) into one class, so you don't write a separate view per action. ModelViewSet gives you all of CRUD from a queryset and a serializer.

A router then generates the URL patterns for a viewset automatically, wiring the standard REST routes. Together they cut a lot of boilerplate for resource-style APIs.

A context processor is a function that injects variables into the context of every template automatically, so you don't pass the same data from each view. Django ships several: request, auth (which adds user), and messages.

You write your own for site-wide values like a company name, feature flags, or a cart count. It returns a dict that gets merged into every template's context. Keep it cheap, since it runs on every render.

The inner Meta class holds model-level options that aren't fields: ordering for a default sort, db_table to override the table name, unique_together or constraints for multi-column uniqueness, verbose_name for display, and indexes for database indexes.

It's how you tune behavior and performance without adding columns. Adding an index on a frequently filtered field, or a default ordering, are common Meta uses.

get_object_or_404 runs a get() and, instead of raising DoesNotExist, raises Http404 when nothing matches, so Django returns a clean 404 page. get_list_or_404 does the same for a filter that returns an empty list.

They remove the repetitive try/except around lookups in views and turn a missing record into the correct HTTP response automatically.

related_name sets the attribute you use to access the reverse relation, from the referenced object back to the objects pointing at it. Without it, Django defaults to modelname_set. With it, you get a readable accessor.

It also matters when two foreign keys point at the same model, where Django forces you to The reverses to avoid a clash.

on_delete tells Django what to do to rows that reference a record when that record is deleted. CASCADE deletes them too, PROTECT blocks the delete and raises, SET_NULL sets the reference to NULL (requires null=True), SET_DEFAULT uses the field's default, and DO_NOTHING leaves it to the database.

The choice is a data-integrity decision. CASCADE for owned children, PROTECT for references you don't want silently destroyed, SET_NULL when the link is optional.

Django's test framework builds on unittest and adds a TestCase that wraps each test in a transaction rolled back afterward, plus a test client that simulates requests. You get a fresh test database, fixtures or factories for data, and assertions like assertContains and assertRedirects.

Many teams run tests with pytest and pytest-django for its fixtures and cleaner syntax. Test models, views, and API endpoints, and mock external services so tests stay fast and deterministic.

bulk_create() inserts many objects in one query instead of one INSERT per object, and update() on a queryset writes a change to every matching row in a single UPDATE. Both are far faster than looping and calling save() per instance.

The catch that trips people: neither calls the model's save() method or fires pre_save and post_save signals, because they bypass the per-instance path. Logic living in save() or a signal won't run, so side effects you rely on silently don't happen.

A request hits the server (Gunicorn or Uvicorn), which calls Django through WSGI or ASGI. Django builds an HttpRequest, then runs it down the middleware chain. URL resolution matches the path to a view. The view runs, usually touching the ORM and rendering a template or serializing data, and returns an HttpResponse.

The response travels back up the middleware chain, where components can modify it, and Django hands it to the server to send. Knowing where middleware, URL resolution, and the view sit in that order is what this question checks.

Scale in layers. At the database, add indexes, fix N+1 queries, use read replicas, and add connection pooling. At the application, run multiple stateless worker processes behind a load balancer and keep sessions in a shared store. Add caching (Redis) for hot reads, and move slow work off the request into a task queue like Celery.

The order matters: profile to find the real bottleneck first, then apply the cheapest fix that moves it. Most Django scaling problems are database problems wearing an application costume.

For work that shouldn't block the request, offload it to a task queue. Celery with a broker like Redis or RabbitMQ is the common choice: the view enqueues a task and returns immediately, and a separate worker process runs it. Use it for emails, report generation, image processing, and third-party API calls.

For scheduled jobs, Celery Beat or a cron-driven management command works. Django's own async views and ASGI help with concurrent I/O within a request, but they don't replace a queue for durable, retryable background work.

Set AUTH_USER_MODEL to your model and subclass AbstractUser (to extend the default) or AbstractBaseUser (to build from scratch, defining the auth fields yourself). Do it at the very start of a project, before the first migration.

Adding it late is painful because the initial migrations already reference the built-in User with foreign keys and permissions. Migrating an existing user table to a new model means data migrations and untangling those references, which is why the advice is always to set the custom user model on day one.

When a query is complex enough that the ORM makes it awkward or inefficient: heavy window functions, recursive CTEs, database-specific features, or a hand-tuned query that outperforms what the ORM generates. Django gives you Manager.raw() for model-mapped raw queries and connection.cursor() for arbitrary SQL.

The discipline: still parameterize (pass params, never format strings) to stay safe from injection, and keep raw SQL rare and documented. Most of the time extra_related, annotate, and Subquery keep you inside the ORM.

Out of the box Django parameterizes ORM queries (SQL injection), auto-escapes template output (XSS), requires CSRF tokens on unsafe methods, hashes passwords with a strong algorithm, and offers clickjacking protection via X-Frame-Options middleware.

What's on you: set DEBUG=False and a real ALLOWED_HOSTS in production, keep the SECRET_KEY out of the repo, run over HTTPS with SECURE_SSL_REDIRECT and HSTS, set secure and httponly cookie flags, and validate file uploads. The framework gives defaults; production hardening is your job.

Measure first: Django Debug Toolbar or query logging shows the SQL, counts, and timings for a page. Look for N+1 loops, missing indexes on filtered or ordered columns, queries pulling more columns or rows than needed, and duplicate queries that caching could remove.

Then fix in order of impact: add select_related/prefetch_related, add indexes, use only() or values() to trim columns, paginate large result sets, and cache expensive stable reads. Confirm each fix with the same measurement.

Override save() when the logic is intrinsic to that model and should run wherever it's saved: normalizing a field, computing a derived value. It's explicit and easy to find. Use a signal when the reacting code lives in a different app or shouldn't know about the sender, so the two stay decoupled.

The trade-off is clarity versus coupling. save() keeps behavior visible on the model; signals scatter it but let unrelated apps hook in. Note that bulk operations like bulk_create and queryset update() skip both save() and per-instance signals, which surprises people.

Two main tools. select_for_update() locks the selected rows inside a transaction so another transaction can't modify them until yours commits, which prevents lost updates on read-modify-write patterns. F expressions push the update into the database as one atomic operation, avoiding the read entirely.

For uniqueness under concurrency, rely on a database unique constraint and handle IntegrityError rather than checking-then-inserting, because the check-then-act window is exactly where the race lives.

Split settings into a base module plus per-environment overrides (base, dev, production), selected by DJANGO_SETTINGS_MODULE, or use one file that reads environment variables. Deployment-specific values (database URL, allowed hosts, debug) come from the environment, and secrets come from the platform's secret manager, never the repo.

The anti-patterns to name: a single settings.py with hardcoded credentials, DEBUG left True, and the SECRET_KEY committed to git. Reading config once at startup into validated values, rather than scattered os.environ reads, keeps it testable.

You define connections in the DATABASES setting and write a database router class that tells Django which connection to use for reads, writes, and migrations of a given model. A common setup routes writes to a primary and reads to replicas to spread load.

You can also force a specific database per query with using(). The catch is that cross-database relations and transactions don't span connections, so the router design has to respect where related data lives.

The contenttypes framework keeps a registry of every model in the project, so code can refer to a model generically at runtime. Generic relations build on it to let one model relate to any other model, using a ContentType foreign key plus an object id.

Use it for cross-cutting features that attach to many models: comments, tags, likes, or an audit log that can reference any record. The trade-off is that generic foreign keys can't be joined as cleanly as real foreign keys, so use them where the flexibility genuinely pays off.

Django supports asynchronous views, middleware, and an async ORM interface, running under ASGI. Async views help when a request waits on multiple slow I/O operations you can run concurrently, like several external API calls.

The limits worth stating: parts of the stack are still synchronous, mixing sync and async carries overhead, and a blocking call inside an async view stalls the event loop. For most CPU work or durable background jobs, a task queue still beats async views.

Treat schema changes as a deployment concern. Make them backward-compatible so old and new code can run together during a rolling deploy: add columns as nullable or with defaults first, deploy code that writes them, backfill data in a separate step, then enforce constraints in a later migration.

Watch for locks: adding an index or a NOT NULL column can lock a large table. Use techniques like creating indexes concurrently on PostgreSQL, run heavy data migrations in batches off the request path, and always have a rollback plan.

Middleware for behavior that applies to every request or a broad set of them: security headers, request logging, tenant resolution. A decorator for per-view opt-in behavior on function-based views: login_required, cache_page, rate limiting one endpoint. A mixin for shared behavior across class-based views, like a permission check baked into several views.

The choice is about scope and granularity. Middleware is global and ordered, decorators and mixins are targeted. Putting endpoint-specific logic in middleware, or global concerns in a decorator repeated everywhere, is the smell to avoid.

A typical stack runs Django under an application server (Gunicorn for WSGI, Uvicorn or Daphne for ASGI) with several worker processes, behind a reverse proxy like Nginx that serves static files and terminates TLS. A CDN fronts static and media assets, PostgreSQL is the database, and Redis handles cache and the Celery broker.

The app runs statelessly so you can scale workers horizontally, with sessions and cache in shared stores. Configuration comes from environment variables, secrets from a manager, and the whole thing is usually packaged as a container image deployed behind a load balancer.

A handful recur. Mutable defaults and mutating querysets in place; queryset laziness causing a query to fire at an unexpected moment; N+1 loops hidden behind template attribute access; bulk_create and update() skipping save() and signals; changing AUTH_USER_MODEL after migrations; and DEBUG left True in production leaking data.

Also: comparing a queryset's truthiness runs a query, timezone-naive datetimes when USE_TZ is on, and relying on signal side effects that don't run for bulk operations. Knowing these is the difference between writing Django and debugging it at 2am.

DRF separates authentication (who you are) from permissions (what you can do). Authentication classes identify the request: SessionAuthentication for browser clients, TokenAuthentication for a stored token, and JWT via a package like SimpleJWT for stateless tokens. Permission classes then gate access: IsAuthenticated, IsAdminUser, or a custom class checking object ownership.

You set defaults globally in REST_FRAMEWORK and override per view. For stateless mobile or single-page clients, JWT is common; for server-rendered sessions, session auth reuses Django's login. Object-level permissions handle 'you can edit only your own records'.

Session auth stores state server-side and sends a session cookie, so you can revoke a session instantly by deleting it, and it pairs naturally with Django's CSRF protection for browser clients. JWT is stateless: the token carries claims and the server verifies a signature without a lookup, which scales across services but makes instant revocation harder.

Choose sessions for first-party web apps where the cookie and CSRF story is simplest, and JWT for mobile clients, third-party API consumers, or multi-service setups where stateless verification matters. The revocation trade-off is the deciding factor to name.