26 Python Backend Interview Questions and Answers

What's the difference between a list and a tuple, and when would you use each?

A list is mutable and a tuple is immutable. Use a list when the collection changes; use a tuple for fixed data, as a dictionary key, or to signal intent that it shouldn't change. Immutability also makes tuples slightly lighter and safe to share.

What they're testing: mutability and its practical consequences

How do Python dictionaries work under the hood, and why are lookups fast?

A dict is a hash table: keys are hashed to compute where their value is stored, so lookups are on average constant time rather than scanning every item. That's why membership tests and key access are fast even for large dicts.

What they're testing: hashing intuition — a quick depth-check

What's the difference between `is` and `==`?

`==` compares values (are these equal?), while `is` compares identity (are these the exact same object in memory?). You use `==` for equality and reserve `is` for singletons like `None`.

What they're testing: identity versus equality

What does REST mean, and what do the main HTTP methods do?

REST is a style for APIs built around resources and standard HTTP methods: GET reads, POST creates, PUT/PATCH update, and DELETE removes. It's stateless and uses meaningful URLs and status codes, so the protocol itself carries much of the semantics.

What they're testing: the model you'll build on daily

What's the difference between authentication and authorization?

Authentication is verifying who you are; authorization is deciding what you're allowed to do. You authenticate first (login), then authorization checks whether that identity has permission for a given action.

What they're testing: a commonly confused pair

What's the difference between a 200, 400, and 500 status code?

200 means success; 4xx means the client did something wrong (bad input, unauthorized); 5xx means the server failed. Returning the right class matters because clients and monitoring rely on it to react correctly.

What they're testing: correct signaling of success versus client versus server errors

What is the GIL, and how does it affect concurrency?

The Global Interpreter Lock lets only one thread execute Python bytecode at a time, so threads don't give true parallelism for CPU-bound work. Threads still help for I/O-bound work (waiting on network or disk), while CPU-bound work needs multiple processes instead.

What they're testing: threads versus processes for backend work

Explain decorators and give a real use case.

A decorator is a function that wraps another to add behavior without changing its code. Common uses are logging, timing, caching, access control, or registering functions — anywhere you want to layer cross-cutting behavior cleanly around a function.

What they're testing: genuine language fluency

What is an ORM, and what are its trade-offs?

An ORM maps database rows to objects so you write Python instead of raw SQL. It speeds development and handles a lot safely, but it can hide inefficient queries — the classic N+1 problem — and sometimes you still need raw SQL for complex or performance-critical queries.

What they're testing: convenience versus control, and the N+1 problem

Walk me through designing an API endpoint that creates a resource.

It accepts a POST, validates the input and rejects bad data with a 400, checks authorization, performs the create inside a transaction, and returns 201 with the created resource or its ID. I'd also make it handle duplicate submissions safely.

What they're testing: request, validation, data access, response, status

What's the difference between synchronous and asynchronous code in Python?

Synchronous code runs one thing at a time, blocking while it waits. Async lets a single thread handle many waiting operations concurrently by yielding during I/O. Async shines for high-I/O workloads like many concurrent network calls; it doesn't speed up CPU-bound work.

What they're testing: when async actually helps

How do you handle errors and exceptions cleanly in a web app?

Catch exceptions where you can do something meaningful, return sensible HTTP status codes and messages, log the details server-side, and avoid leaking internals to the client. The goal is failing loudly in your logs but gracefully to the user.

What they're testing: failing loudly internally and gracefully to users

What is a database index, and when would you add one?

An index is a data structure that speeds up lookups on a column, at the cost of extra storage and slower writes. Add one for columns you frequently filter, join, or sort on — but not indiscriminately, since every index slows down inserts and updates.

What they're testing: performance intuition and the cost of over-indexing

What's the difference between PUT and PATCH?

PUT replaces the entire resource with what you send; PATCH updates only the fields you provide. Use PUT for a full replacement and PATCH for a partial update.

What they're testing: full replace versus partial update semantics

How do you paginate a large collection in an API?

Either offset-based (page and size), which is simple but slow and inconsistent on deep pages, or cursor-based (a pointer to the last item), which is stable and scales better for large or changing datasets. Cursor pagination is preferred at scale.

What they're testing: offset versus cursor and their trade-offs

How do you keep credentials and secrets out of your codebase?

Read them from environment variables or a secrets manager, load them via config at runtime, and keep the actual values out of version control. Never hard-code secrets in source, since anyone with the repo then has them.

What they're testing: environment configuration and basic security hygiene

An endpoint is suddenly slow. How do you find and fix the cause?

I'd measure first — profile the request, check the database queries it runs, and look for N+1 patterns, missing indexes, or a slow external call. Once I've located the real bottleneck from data, I fix that specific thing: add an index, batch queries, or cache, rather than guessing.

What they're testing: profiling, query plans, N+1, caching — a real process

How would you handle a long-running task triggered by an API request?

Don't block the request — accept it, hand the work to a background job or queue, and return quickly with a 202 and a way to check status. The client polls or gets notified when it's done. This keeps the API responsive under slow work.

What they're testing: background jobs, queues, and status polling

How do you keep an operation safe when the same request might arrive twice?

Make it idempotent — often with an idempotency key or by checking whether the operation already completed before doing it again. That way a retry or double-click doesn't create duplicate records or double-charge.

What they're testing: idempotency — a maturity signal

Explain database transactions and isolation levels.

A transaction groups operations so they all succeed or all roll back, keeping data consistent. Isolation levels control how much concurrent transactions can see each other's uncommitted work, trading strict correctness against performance — most apps use 'read committed' as a sensible default.

What they're testing: consistency under concurrent access

How would you validate and sanitize untrusted input reaching your backend?

Treat all client input as untrusted: validate types, ranges, and formats, reject anything unexpected, and use parameterized queries so input can never be executed as code. Validation happens server-side regardless of any client-side checks.

What they're testing: treating input as untrusted, not trusting the client

How do you prevent and detect a race condition in request handling?

Use database transactions, atomic operations, or locks so concurrent requests can't corrupt shared state, and design operations to be idempotent. Detection comes from noticing inconsistent data under load and reproducing the concurrent access that caused it.

What they're testing: concurrency correctness and locking/atomicity

Design a URL shortener. Walk me through it.

You need a mapping from a short code to the original URL. Generate a unique short code (a base-62 encoded ID or a hash), store the mapping, and on lookup redirect. I'd discuss handling collisions, scaling reads (caching hot URLs), and analytics — the interviewer wants to see the data model and trade-offs.

What they're testing: data model, scale, and trade-offs

Design the backend for a feature that processes uploaded files with AI.

Validate the upload by content (not just extension) and size, store it safely, then process asynchronously in a background task since AI calls are slow — returning a 202 and letting the client poll for status. I'd cover reliability, retries, and keeping the request cycle fast.

What they're testing: validation, async processing, storage, reliability

Scale this API from 100 to 100,000 requests per minute. What changes?

Make the app stateless so it scales horizontally behind a load balancer, add caching for hot reads, optimize and possibly replicate the database, and move slow work off the request path. I'd find the real bottleneck first rather than scaling blindly.

What they're testing: caching, database, statelessness, horizontal scaling

Design an idempotent payment endpoint that never double-charges.

The client sends an idempotency key with the request; the server records it and, if it sees the same key again, returns the original result instead of charging twice. Combined with a transaction around the charge, this makes retries safe even over an unreliable network.

What they're testing: exactly-once semantics and safe retries