Django interview questions — where "it just works" stops being a good enough answer

Django's whole design philosophy is "batteries included, complexity hidden" — which makes it fast to build with and easy to interview badly for, because knowing the API surface and understanding what it's doing underneath are two different things. Django interviews are specifically built to find that gap.

The ORM question that reveals everything

What gets recited: the ORM lets you query the database using Python instead of raw SQL.

What actually gets tested: "Why is this view slow, and here's the code." Almost always, the answer is the N+1 query problem — a loop over a queryset that accesses a related object on each iteration, firing one extra query per row instead of one query total. for order in Order.objects.all(): print(order.customer.name) looks completely reasonable and is a performance bug waiting to happen at scale. The strong answer names select_related (for foreign keys, a SQL join) or prefetch_related (for reverse foreign keys and many-to-many, a second query plus Python-side joining) before being asked — and explains why each fits a different relationship type, not just that they exist.

Migrations — not "what," but "what happens when they conflict"

Everyone can say migrations track schema changes as version-controlled Python files. The follow-up worth being ready for: "two people create migrations on separate branches, both touching the same model — what happens when you merge?" The honest answer is that Django detects the conflict and generates a merge migration, but the deeper point interviewers are checking for is whether you understand migrations are applied in order and a bad merge can silently produce a broken migration graph — which is why running makemigrations and actually reviewing the generated file, rather than blindly trusting it, matters on a team.

Django's request/response cycle — the question behind "how does middleware work"

Middleware confuses people because it's simultaneously simple (a function that wraps the view) and easy to get backwards. The useful mental model: middleware forms a chain, each layer touches the request on the way in and the response on the way out, in a specific order defined by MIDDLEWARE in settings. The stronger answer to "why would you write custom middleware" names a real use case — logging request timing, adding a custom header, enforcing something project-wide without touching every view — rather than a generic "for cross-cutting concerns."

Class-based views vs function-based views — the debate that's really about tradeoffs

This isn't really "which is better" — it's checking whether you understand what each optimizes for. Function-based views are explicit and easy to trace top to bottom, which matters for a simple, unusual view. Class-based views (especially Django's generic views like ListView, CreateView) reduce boilerplate for standard CRUD patterns through inheritance and mixins, at the cost of having to know where in the class hierarchy a given piece of behavior actually lives when something needs to be customized. A strong answer picks based on the actual view's complexity, not a blanket preference.

Signals — the feature everyone uses and half-regrets

Django signals (post_save, pre_delete, and similar) let code react to model events without modifying the model itself, which sounds clean until a project has ten signal handlers scattered across different apps, silently firing when a save happens, and no single place shows you the full picture. The question worth having a real answer to: "when would you avoid using a signal?" The honest answer is usually "when the logic is specific enough to belong directly in the model's save() method or the view, where someone reading the code can actually find it" — signals are best reserved for genuinely decoupled, cross-app concerns.

---

If you want to practice Django and Python backend questions with real follow-ups instead of a static list, try role-specific mock interviews for Python/Backend — free to start.