Python backend interviews cover language internals, async programming, Django or FastAPI, and database access patterns. Below are the most common questions with model answers. Senior: architecture, trade-offs, mentoring, and decision-making.
Roughly: move the work off the request into a queue, parallelise with processes rather than threads, push the hot loop into C or Rust via an extension, or change the algorithm. The last is usually the cheapest and the one people skip. Multiprocessing costs you serialisation of everything crossing the boundary; an extension costs you build complexity and a second language in the repo.
In stages that are each backward compatible: add the new column as nullable, write to both old and new, backfill in batches, switch reads, then drop the old one in a later release. The reason is that during a rolling deploy two versions of the code run against one database. The most common failure is a migration that locks a large table — on Postgres, adding an index needs CONCURRENTLY.
Start with what changed, then narrow by layer rather than guessing: is it slow for all users or a subset, is the time in the database, in Python, or in an external call. APM traces or a profiler on the hot path answer that in minutes. Only then optimise. The common trap is profiling locally against a small dataset, where the N+1 that dominates production is invisible.
Django when the service is content and admin heavy, or when the ORM, migrations, auth and admin save you months. FastAPI when it is a thin API, when async I/O dominates, or when the schema-first typed contract matters. Neither choice is about speed benchmarks. The question worth asking is which one your team can operate at three in the morning.
As close to the expensive thing as possible and no closer — caching a whole rendered page hides which part was actually slow. Invalidation by explicit key on write is correct but easy to miss; a short TTL is wrong but self-healing, and for most read-heavy data it is the better trade. The failure to plan for is the stampede when a hot key expires and every request rebuilds it at once.
They buy a checker that catches whole classes of mistakes before runtime, editor completion, and documentation that cannot drift from the code. They do not buy runtime enforcement — nothing validates a hint unless you add pydantic or similar. On a large codebase the value comes from being strict at the boundaries and pragmatic inside; hinting every local variable costs more than it returns.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Senior Python Backend interview →