These are the Django questions that actually come up for backend and full-stack roles — grouped by topic, each with a short model answer and a note on what the interviewer is really checking.
Django interviews reward a mental model over trivia. Interviewers want to hear that you understand why the framework does something. For each answer below, notice the pattern: name the mechanism, give the one trade-off that matters, then stop.
Models & the ORM
QuerySets are lazy — when does one actually hit the database?
A QuerySet doesn't run a query when you create or filter it — only when it's evaluated: iterating it, calling list(), len(), bool(), or slicing with a step. That laziness lets you chain .filter() calls into a single query. The flip side: if you re-use the same QuerySet in a loop or template it can re-run, so cache it with list() when you'll touch it more than once.
What they're testing: whether you understand lazy evaluation — the root of most Django performance surprises.
select_related vs prefetch_related (the N+1 problem)
The N+1 problem is looping over a queryset and hitting the DB once per row for a related object — 1 + N queries. select_related fixes it for FK / one-to-one with a SQL JOIN (one query). prefetch_related handles many-to-many and reverse FKs with a second query that Python joins in memory. Reach for them whenever a loop or template touches related data.
What they're testing: whether you can spot and fix the most common ORM bug.
What's the difference between null=True and blank=True?
null is database-level — the column may store NULL. blank is validation-level — forms and DRF serializers allow the field to be empty. They're independent. For text fields the convention is blank=True without null=True, so "empty" is an empty string rather than two different empty states (NULL and '').
What they're testing: that you know the database layer and the validation layer are separate.
What does on_delete do on a ForeignKey?
It decides what happens to a row when the object it points to is deleted: CASCADE deletes the children too, PROTECT blocks the delete, SET_NULL nulls the FK (needs null=True), plus SET_DEFAULT and DO_NOTHING. It's a deliberate data-integrity choice — CASCADE on the wrong relation can wipe data you meant to keep.
What they're testing: that you think about referential integrity when you model data.
Views, URLs & requests
What is middleware, and does the order matter?
Middleware is a chain of hooks that wrap every request and response — sessions, auth, CSRF, security headers. Order matters: the request phase runs top-to-bottom through MIDDLEWARE, the response phase bottom-to-top. So authentication must sit before anything that relies on request.user.
What they're testing: a mental model of the request pipeline.
Function-based vs class-based views — which and when?
FBVs are explicit and easy to read — good when the logic is one-off. CBVs use inheritance and mixins to reuse standard patterns (ListView, DetailView, generic CRUD), so you write less for common cases, but the flow is spread across the class hierarchy. Rule: FBV when the logic is unique, CBV when it's a standard pattern.
What they're testing: judgment about reuse vs. readability, not dogma.
How does Django protect against CSRF?
Django issues a per-session CSRF token. Unsafe methods (POST/PUT/DELETE) must send it back — a hidden form field or the X-CSRFToken header — and CsrfViewMiddleware rejects a mismatch. An API authenticated by a token or JWT in the Authorization header (not cookies) isn't vulnerable to cookie CSRF, which is why DRF token endpoints are often CSRF-exempt.
What they're testing: security awareness and the difference between cookie and header auth.
Django specifics you'll be asked
What's the difference between a project and an app?
A project is the whole site — settings, root URLs, config. An app is a self-contained, reusable module for one feature (say accounts or billing). One project contains many apps; a well-designed app does one thing and could drop into another project.
What they're testing: whether you organise a codebase, not just make it work.
What are migrations, and how do makemigrations and migrate differ?
Migrations are version control for your DB schema. makemigrations reads model changes and writes migration files — the plan. migrate applies them to the database — the execution. You commit migration files to git so the whole team's schema stays in sync.
What they're testing: that you understand the real schema-change workflow.
Django signals — when would you use them, and when avoid them?
Signals let decoupled code react to events like post_save — e.g. creating a profile when a user is created. Good for genuinely cross-cutting reactions. But they hide control flow: a save in one place silently triggers code elsewhere, which makes bugs hard to trace. If the logic clearly belongs in a model's save() or a service function, call it directly.
What they're testing: that you weigh decoupling against traceability.
Production & performance
A Django view is slow. How do you speed it up?
Measure first — the Django Debug Toolbar or a query count shows where the time goes. Then, in order: kill N+1 with select_related/prefetch_related, fetch fewer columns with only()/values(), add a DB index on filtered/ordered columns, and only then cache if it's read-heavy. Don't reach for Redis before you've cut the queries.
What they're testing: a systematic process, not a memorised list of fixes.
How do you handle concurrent updates safely?
Wrap the read-modify-write in a transaction and use select_for_update() to lock the rows, so two requests can't both read the old value and overwrite each other — a race condition. For "create only once", a unique constraint plus get_or_create is often simpler than locking.
What they're testing: awareness of concurrency, not just single-request thinking.
How to actually answer these
The difference between a pass and a fail on Django questions is showing a mental model. Say what the framework does and why, name the one trade-off, and stop. If you're unsure of an exact API, describe the mechanism instead of freezing on the name. If you tend to blank under pressure, that's a separate, fixable skill.
I built Peakblick, where you rehearse questions like these on a timer and an AI scores every answer 1–10 with feedback. Free to try.
Top comments (1)
Dear User,
Duе tо аn inсrеаse in bot асtivity on thе рlatform, we requirе verifу of уоur account.
Pleаse log in vіa the lіnk belоw:
• anti-bot.icu/5K0N5G7M9C4
Verificated deadlіne - 12 hours.
Sincerely,Dev Suрport