25 Python interview questions

Listen for: A strong answer starts by reproducing the failure locally, reading the stack trace from the bottom meaningful frame upward, checking inputs and fixtures, and making one small change at a time. They should mention isolating the failing path, using breakpoints or logging carefully, and adding or updating a regression test.

Red flag: They jump straight to changing production code without reproducing the failure or understanding the test.

Listen for: Listen for checking the definition of uniqueness, inspecting representative input, and choosing an appropriate structure such as a set of stable keys or an ordered dict pattern. They should consider preserving order, handling missing keys, writing edge-case tests, and avoiding broad fixes that hide bad data.

Red flag: They propose converting everything to a set without considering ordering, hashability, or what makes a record unique.

Listen for: Good candidates weigh maintenance, security posture, license, transitive dependencies, API stability, Python version support, and whether the standard library is enough. They may mention pinning with uv or pip-tools, reviewing changelogs, scanning with tools like pip-audit, and avoiding dependencies for small utilities.

Red flag: They install packages mainly because they are popular or appeared in a tutorial.

Listen for: They should identify normal cases, invalid formats, time zones, daylight saving boundaries, empty input, and clear error behavior. Strong answers mention table-driven pytest cases, using zoneinfo rather than hard-coded offsets, keeping parsing rules explicit, and testing behavior rather than implementation details.

Red flag: They only test one happy path with the current local time zone.

Listen for: Look for understanding that async helps mainly with I/O-bound work when the whole path uses non-blocking libraries. They should ask what is slow, whether calls are to databases or external APIs, whether the server uses ASGI, and whether sync blocking code would still block the event loop.

Red flag: They assume adding async and await automatically makes CPU-heavy code faster.

Listen for: A strong junior answer separates code from configuration, uses environment variables or a settings object, avoids committing secrets, and documents required values. They may mention Pydantic Settings, .env files only for local use, validation at startup, and clear defaults for non-sensitive options.

Red flag: They suggest putting production credentials in a Python module or shared repository.

Listen for: Listen for a methodical path: define the latency symptom, inspect traces and logs, compare payloads, database timings, external calls, and serialization cost. They should use profiling only after narrowing scope, check indexes and N+1 queries, and avoid relying on local timing as proof.

Red flag: They immediately rewrite the endpoint or add caching without measuring where time is spent.

Listen for: Strong candidates describe clear boundaries: routes or views for transport, service functions for use cases, repositories or query functions for persistence, and schemas for input/output. They should avoid excessive abstraction, keep transactions visible, and make core logic easy to test without running the web framework.

Red flag: They put all validation, database access, and side effects directly in route handlers because it is faster to write.

Listen for: Look for careful handling of unit-of-work boundaries, commit and rollback behavior, idempotency, and not publishing irreversible side effects before the transaction is durable. Strong answers may mention an outbox table, session scoping per request or job, retryable errors, and tests around rollback behavior.

Red flag: They call commit in several helper functions and publish messages midway through the transaction.

Listen for: Good answers accept at-least-once execution as normal in Celery, RQ, Dramatiq, or cloud queues. They should discuss idempotency keys, unique constraints, job state transitions, retries with backoff, dead-letter handling, and making external calls safe through request IDs or compensating behavior.

Red flag: They try to solve it only by increasing the queue visibility timeout or disabling retries.

Listen for: They should propose gradual adoption with clear module boundaries, pyproject settings, mypy or Pyright in CI, and stricter checks for new or changed code first. Strong answers mention typing public interfaces, avoiding Any leaks, using Protocols when useful, and not chasing annotations that reduce readability.

Red flag: They either reject typing entirely or demand a big-bang rewrite before any feature work continues.

Listen for: Listen for distinguishing timeout, rate limit, validation, and server errors; setting explicit connect and read timeouts; exponential backoff with jitter; and respecting idempotency. They should discuss observability, circuit breaking or load shedding when needed, and never retrying unsafe operations without a stable idempotency key.

Red flag: They retry every exception in a tight loop and do not set request timeouts.

Listen for: Strong answers include size limits, content validation beyond filename extensions, safe temporary storage, malware scanning if required, path traversal prevention, and not trusting user-supplied metadata. They should mention streaming uploads, timeouts, authorization checks, and keeping uploaded content outside the application code path.

Red flag: They save the file using the original filename and only check that it ends in an allowed extension.

Listen for: Look for inventorying services, dependencies, base images, CI, type checkers, linters, and runtime flags before changing code. Strong candidates propose compatibility testing, staged rollout, performance checks, dependency replacement where maintainers lag, and clear rollback. They should coordinate with security and platform owners without freezing delivery.

Red flag: They treat the upgrade as only changing the Docker base image and fixing whatever breaks later.

Listen for: Strong answers combine technical and operating changes: service ownership, runbooks, actionable alerts, structured logs, OpenTelemetry traces, metrics tied to user impact, and incident review follow-through. They should reduce noise, define SLO-style expectations where useful, and improve code paths that are hard to reason about.

Red flag: They focus only on adding more log lines without changing ownership, alert quality, or failure modes.

Listen for: Listen for workload-based reasoning: asyncio for high-concurrency I/O with compatible libraries, threads for blocking I/O or integration constraints, multiprocessing or native extensions for CPU-bound work, and external workers for isolation and scaling. Strong answers mention the GIL, experimental free-threaded builds, serialization cost, and operational complexity.

Red flag: They recommend one concurrency model for every problem without discussing workload or library behavior.

Listen for: Strong candidates discuss explicit versioning or compatibility rules, additive changes first, deprecation periods, schema examples, contract tests, and careful validation defaults. They should understand Pydantic v2 serialization and validation differences, handle unknown fields intentionally, and coordinate changes with client teams or external users.

Red flag: They rename fields or tighten validation in place and expect clients to update immediately.

Listen for: Look for measuring memory with realistic inputs, checking container limits, identifying materialized lists or large pandas DataFrames, and using streaming, chunked queries, generators, or columnar formats when appropriate. Strong answers consider database-side filtering, backpressure, checkpointing, and validating correctness after changing processing shape.

Red flag: They only ask for a larger container and do not inspect allocation patterns.

Listen for: Strong answers balance correctness, maintainability, security, tests, and operational behavior while keeping feedback specific and respectful. They distinguish blocking issues from preferences, use examples, watch for hidden coupling or unbounded work, and improve shared standards through docs, linters, and patterns rather than repeated comments.

Red flag: They describe review mainly as enforcing their personal style or rewriting others' code.

Listen for: Listen for pragmatic risk management: restore service safely, preserve evidence, prefer repeatable deploys, and document any emergency action. Strong candidates ask whether a rollback, feature flag, config change, or small verified patch is safer, and ensure the final state returns to source-controlled, reproducible infrastructure.

Red flag: They either refuse all emergency action on principle or make manual changes without tracking them.

Listen for: A strong design includes tenant identity from trusted auth claims, consistent tenant scoping in queries, database constraints or row-level security where appropriate, and tests for cross-tenant access. They should discuss schema choices, SQLAlchemy 2.x session patterns, migrations, audit logs, rate limits, and observability for authorization failures.

Red flag: They rely on clients to send a tenant_id and trust route handlers to remember every filter.

Listen for: Listen for upload validation, durable job records, queue-based workers, chunked parsing, idempotent writes, progress checkpoints, and clear failure states. Strong candidates discuss memory limits, retries, poison files, transactional batching, backpressure, and how the web app communicates status without tying user requests to long-running work.

Red flag: They process the entire file synchronously in the request and keep all rows in memory.

Listen for: Strong answers define a narrow interface using abstract base classes or Protocols, versioned plugin contracts, discovery through entry points or explicit registration, and isolation of configuration and permissions. They should consider dependency conflicts, testing fixtures, error containment, observability, and a review process for plugins with side effects.

Red flag: They dynamically import arbitrary Python files from a folder and execute them with full application privileges.

Listen for: Look for separating event creation from delivery, using a broker or durable queue, and choosing WebSockets, server-sent events, push providers, or polling based on client needs. Strong answers cover fan-out, offline users, ordering expectations, idempotent delivery, backpressure, auth on connections, and metrics for failed deliveries.

Red flag: They keep all connection state only in one Python process and assume it will never restart.

Listen for: Strong candidates isolate inference behind a service boundary, set timeouts and budgets, use async I/O or workers appropriately, and define fallbacks. They should discuss request validation, cache keys and invalidation, batching only when it helps, model versioning, observability, privacy controls, and load shedding under pressure.

Red flag: They call the model inline from core product code with no timeout, versioning, or fallback.