Python Developer Interview Questions

Python source is compiled to bytecode (.pyc) and that bytecode is then run by the Python Virtual Machine, so it's technically both, but in practice you never see a separate compile step the way you do with C or Java, which is why it's called an interpreted language.

Python 3 made print a function instead of a statement, changed integer division (/ returns a float, // does floor division), made strings Unicode by default, and reorganized parts of the standard library. Python 2 reached end of life in 2020, so this mostly comes up to check you know current Python, not to test Python 2 trivia.

PEP 8 is Python's official style guide, covering naming conventions, indentation, line length, and import ordering. It matters in practice because most teams enforce it with linters (flake8, ruff) as part of CI, so code that violates it fails a build before a human ever reviews it.

A syntax error is caught before any code runs, e.g. a missing colon after an if statement. A runtime error only surfaces while the code is executing, e.g. dividing by zero or accessing a key that doesn't exist in a dictionary, which is why Python code can pass a syntax check and still crash in production.

The core built-in types are int, float, complex, str, bool, list, tuple, dict, set, and frozenset, plus NoneType for the absence of a value. Everything in Python, including functions and classes, is an object, which is a distinction that becomes important once you start asking about mutability.

Lists are mutable and use square brackets. Tuples are immutable and use parentheses. Use a tuple when the data shouldn't change after creation, like a fixed coordinate pair, and because tuples are hashable, they can be used as dictionary keys, unlike lists.

A list preserves order and allows duplicates. A set is unordered, only stores unique elements, and gives O(1) average-time membership checks versus O(n) for a list, which matters if you're doing repeated 'is this value already in here' checks on large data.

A dictionary is a hash table: each key is hashed to determine where its value is stored, which is why key lookup is O(1) on average regardless of dictionary size. Since Python 3.7, insertion-order preservation is written into the language spec itself, not left up to whichever implementation you happen to be running.

Implicit conversion happens automatically, like Python promoting an int to a float when you add 1 + 2.5. Explicit conversion means you call a function yourself, like int('42') or str(42), which you need whenever Python won't guess the conversion for you, such as concatenating a number into a string.

Mutable objects can be changed after creation without changing their identity, like lists, dicts, and sets. Immutable objects, like int, float, str, and tuple, can't be changed in place. Any 'modification' actually creates a new object. This matters because passing a mutable object into a function lets that function change it in place, which can surprise people who expect pass-by-value behavior.

== compares whether two objects have equal values, while is checks whether both references point to the exact same object in memory. Use == for value comparison and use is mainly for singleton checks such as value is None.

in and not in are membership operators, checking whether a value exists in a sequence, e.g. 3 in [1,2,3]. is and is not are identity operators, checking whether two references point to the same object rather than comparing values.

break exits a loop entirely. continue skips the rest of the current iteration and moves to the next one. pass does nothing at all. It's a placeholder used when a statement is syntactically required but you have no logic to put there yet, like an empty function body during scaffolding.

The idiomatic way is slicing: my_string[::-1]. You could also use ''.join(reversed(my_string)), but the slice notation is what's expected as a quick, correct answer in an interview.

find() returns -1 if the substring isn't found, so it never raises an exception. index() raises a ValueError in the same situation. Use find() when a missing substring is a normal case you'll handle, and index() when a missing substring means something has actually gone wrong.

Use str.isdigit() for digits-only and str.isalpha() for letters-only. Both return False for an empty string, and neither handles things like decimal points or negative signs, so validating a full numeric string usually needs a try/except around float() instead.

A parameter is the variable name listed in a function's definition, like def greet(name):. An argument is the actual value you pass in when calling the function, like greet('Ben'), where 'Ben' is the argument bound to the name parameter.

Default arguments let a parameter take a preset value if the caller doesn't supply one, like def f(x=5):. The classic mistake is using a mutable default, like def f(items=[]):, because that list is created once at function definition time and shared across every call that doesn't pass its own list, silently accumulating state between unrelated calls.

A function is a standalone block of reusable code, defined independently. A method is a function that belongs to a class or object and is called on an instance, like my_list.append(5), where append is a method of the list object.

self refers to the specific instance a method is being called on and lets the method access that instance's attributes and other methods. It's a strong convention, not a reserved keyword. You could technically call it anything else, but every other Python developer reading your code would stop and wonder why.

A class variable is shared across every instance of the class, defined directly in the class body. An instance variable is specific to one object, usually set inside __init__ using self. Changing a class variable through the class affects all instances, but assigning to it through one instance just creates a new instance variable that shadows the class variable for that object alone.

__init__ is the constructor method, automatically called when a new object is created from a class, used to initialize the object's attributes. Object allocation actually happens in __new__, not __init__, but for almost all practical purposes __init__ is where you set up instance state.

list(dict.fromkeys(my_list)) removes duplicates and keeps the first occurrence's order, since dictionaries preserve insertion order in modern Python. Converting to a set and back (list(set(my_list))) removes duplicates too, but does not preserve order, which is a common mistake.

Track two variables, first and second, both initialized to negative infinity, then loop through the list once: if a number is greater than first, shift first into second and update first. Else if it's greater than second, update second. This runs in O(n) versus O(n log n) for sorting, which is the kind of trade-off interviewers want you to notice.

append() adds its argument as a single element, so my_list.append([1,2]) adds one item that is itself a list. extend() adds each element of the argument individually, so my_list.extend([1,2]) adds two separate items. Mixing these up is a very common bug.

In Python 3.9+, dict1 | dict2 merges them, with dict2's values winning on key conflicts. Before 3.9, {**dict1, **dict2} does the same thing via unpacking. .update() also merges, but it mutates the first dictionary in place rather than returning a new one.

A list comprehension builds a list in a single expression, like [x*2 for x in range(10) if x % 2 == 0]. It's generally faster than an equivalent for-loop with .append() because the looping happens at the C level inside the interpreter, and it's more readable for simple transformations, though a nested comprehension can quickly become harder to read than the loop it replaced.

Code in try runs first. If it raises an exception, the matching except block runs. else runs only if no exception was raised, and finally always runs regardless of whether an exception occurred, typically used for cleanup like closing a file or a connection.

Catching a specific exception, like except ValueError:, only handles that error and lets anything else propagate, which is almost always what you want, since it fails loudly on bugs you didn't anticipate. Catching the broad Exception class silently swallows errors you didn't expect, including ones that indicate a real bug, which makes debugging much harder later.

Define a class that inherits from Exception (or a more specific built-in exception), then raise it with raise MyCustomError('message'). Custom exceptions are useful when you want calling code to catch a specific, named failure mode rather than a generic ValueError or RuntimeError.

with opens a context manager that guarantees cleanup code runs even if an exception occurs inside the block, for example with open('file.txt') as f: automatically closes the file when the block exits, whether it finished normally or raised an error. Without it, you'd need a manual try/finally to guarantee the file gets closed.

read() loads the entire file into one string. readline() reads a single line at a time, useful for processing large files without loading them fully into memory. readlines() returns a list of all lines, which is convenient but, like read(), loads everything into memory at once.

Python's own bytecode execution is slower than a compiled language for raw CPU loops, but most real-world Python code spends its time waiting on I/O (network, disk, database) or calling into fast C-implemented libraries (NumPy, the standard library), where Python's own loop speed barely matters. 'Python is slow' is true for tight numeric loops in pure Python and mostly irrelevant for typical web or scripting workloads.

type(x) returns the exact class of an object. isinstance(x, SomeClass) checks whether an object is that class or any subclass of it, which is almost always what you actually want, since it correctly handles inheritance, whereas type(x) == SomeClass would incorrectly reject a valid subclass instance.

For a plain list, my_list[:] and list(my_list) both create a new outer list, which behaves the same as copy.copy() for that case. The distinction only matters for nested structures or custom objects, where copy.copy() calls an object's own __copy__ logic if defined, and plain slicing wouldn't.

MRO is the order Python searches through a class hierarchy to find a method or attribute, computed using the C3 linearization algorithm, viewable via ClassName.__mro__. It matters with multiple inheritance because two parent classes might define the same method, and MRO determines which one actually gets called, which is a frequent source of subtle bugs in deep hierarchies.

A staticmethod doesn't receive the instance or the class automatically, it behaves like a plain function that's just namespaced inside the class. A classmethod receives the class itself (cls) as its first argument, commonly used for alternative constructors, like a from_json() method that builds an instance from parsed data.

Dunder methods let your objects hook into Python's built-in syntax: __init__ for construction, __str__ and __repr__ for how an object prints, __eq__ for == comparisons, __len__ so len(obj) works, and __iter__ to make an object usable in a for loop. Implementing __repr__ well is genuinely underrated. A good repr saves hours of debugging.

Inheritance models an 'is-a' relationship and reuses behavior by extending a base class. Composition models a 'has-a' relationship, building objects out of other objects instead. In practice, composition is usually favored when behavior needs to change at runtime or when the inheritance hierarchy would get deep and fragile, since deep inheritance chains make it hard to reason about which class actually defines a given behavior.

A closure is a function that remembers variables from its enclosing scope even after that outer function has returned. It requires a nested function that references a variable from the outer function, and the outer function returning the inner one, which is the mechanism decorators are built on.

A decorator wraps a function to add behavior without changing its source. A timing decorator would define a wrapper function that records time.time() before and after calling the original function, then returns the wrapper in place of the original, applied with @decorator_name above the function definition.

You need three levels of nested functions: the outermost takes the decorator's arguments (times=3) and returns the actual decorator, which takes the function to wrap and returns the wrapper, which contains the retry logic and calls the original function.

When you wrap a function with a decorator, the wrapper replaces the original function's metadata (its __name__, docstring, etc.) unless you fix it. functools.wraps copies that metadata from the original function onto the wrapper, which matters for debugging, introspection tools, and anything that relies on a function's __name__ being accurate.

*args collects extra positional arguments into a tuple, and **kwargs collects extra keyword arguments into a dict. A keyword-only argument, defined after a bare * in the signature (def f(a, *, b):), forces callers to pass it by name, which is useful for making a function call unambiguous when there are several boolean or optional flags.

An iterable is anything you can loop over, meaning it implements __iter__ and returns an iterator. An iterator is the object that actually tracks progress through the sequence, implementing both __iter__ and __next__, and it's the __next__ calls that lazily produce each value.

A generator uses yield to produce values one at a time, on demand, instead of building the entire result in memory upfront. You'd choose a generator when processing a large or unbounded dataset, like reading a multi-gigabyte log file line by line, where materializing the full list upfront would burn memory you never actually needed all at once.

A generator expression uses parentheses instead of square brackets, like (x*x for x in range(1000000)), and produces values lazily rather than building the whole list immediately. It's the right choice when you're going to consume the values once, in order, and don't need random access or the length upfront.

yield from delegates iteration to a sub-generator or any iterable, forwarding its values one at a time without needing an explicit inner loop. It's mainly useful for composing generators, like a generator that flattens a nested structure by yielding from each nested generator in turn.

Iterate over the file object directly (which is itself an iterator, yielding one line at a time) or use csv.reader on the file handle instead of reading the whole file into a string first. For heavier transformation, chaining generator expressions lets you filter and transform each row lazily, one at a time, keeping memory flat regardless of file size.

Use collections.Counter and add the two together with the + operator, which sums values for matching keys automatically. Without Counter, you'd loop through the second dict and do result[key] = result.get(key, 0) + value for each entry.

Using the requests library: response = requests.get(url), then check response.status_code or call response.raise_for_status(), which throws an HTTPError for 4xx/5xx responses so you can catch it explicitly rather than silently proceeding with a failed response's body.

json.loads() parses the raw string into a Python dict, but that alone doesn't validate structure or types. In practice, most teams use a library like Pydantic to define an expected schema and get clear validation errors if a required field is missing or has the wrong type, rather than hitting a KeyError deep in business logic.

unittest is Python's built-in testing framework, class-based and verbose (self.assertEqual etc). pytest is a third-party framework that uses plain functions and assert statements, has a much richer plugin ecosystem, and better fixture support. For a new project, most teams default to pytest for its lower boilerplate and readability, even though it can still run unittest-style tests.

Use unittest.mock.patch to replace the function or method that makes the actual network call with a Mock object that returns a canned response, so the test doesn't depend on network access or the real service being up. This keeps tests fast and deterministic, and lets you simulate error responses you couldn't easily trigger against the real API.

A Python installation is the interpreter and its site-wide packages, shared across everything on the machine. A virtual environment is an isolated copy of package dependencies for one project, so two projects needing different versions of the same library, e.g. Django 3 vs Django 4, don't conflict. Without one, installing a dependency for one project can silently break another.

Always use parameterized queries (placeholders like %s or ? that the database driver fills in safely) instead of building SQL strings with f-strings or concatenation. Every major Python DB library (psycopg2, sqlite3, SQLAlchemy) supports parameterization natively, so there's rarely a good reason to concatenate user input directly into a query.

An ORM like SQLAlchemy or Django's ORM lets you work with Python objects instead of SQL strings, and handles a lot of boilerplate (joins, migrations) for you. Raw SQL gives full control and is often faster for complex queries or bulk operations, where an ORM can generate inefficient queries without you noticing. Most teams default to the ORM for typical CRUD and drop to raw SQL for reporting queries or performance-critical paths.

Offset-based pagination (LIMIT/OFFSET) is simplest but gets slow on large tables since the database still has to scan past the skipped rows. Cursor-based pagination (using a value from the last row, like an ID or timestamp, as the starting point for the next page) scales much better for large datasets and avoids the 'page shifts under you while data is being added' problem offset pagination has.

A synchronous driver blocks the calling thread until the query returns. An async driver (like asyncpg) lets other coroutines run while waiting on the database. It matters far less in a typical Flask app, which is usually synchronous end-to-end and scales via multiple worker processes, than in an async framework like FastAPI, where a blocking DB call would stall the whole event loop.

Use threading for I/O-bound concurrency where tasks spend most of their time waiting (network calls, file I/O) and you want a simpler model than async. Use multiprocessing for CPU-bound work, since separate processes each get their own GIL and can run truly in parallel across cores. Use asyncio for high-concurrency I/O-bound workloads, like handling thousands of simultaneous network connections, where the overhead of one thread per connection would be too high.

A single thread runs an event loop that manages a queue of coroutines. When a coroutine hits an await on an I/O operation, it yields control back to the loop instead of blocking, letting the loop run other ready coroutines in the meantime, and resumes the original coroutine once its I/O completes. Nothing here runs in true parallel. It's cooperative concurrency on one thread.

Calling a blocking function, like time.sleep() or a synchronous database driver call, directly inside an async function blocks the entire event loop, stalling every other coroutine that was supposed to be running concurrently. The fix is either an async-native library (asyncio.sleep, an async DB driver) or running the blocking call in a thread pool executor via loop.run_in_executor.

Offload it to a separate process using multiprocessing or a ProcessPoolExecutor via loop.run_in_executor, since that work needs to bypass the GIL entirely rather than just yielding cooperatively. Trying to solve a CPU-bound problem with more coroutines doesn't help, since they all still compete for the same GIL on one thread.

CPython uses reference counting as its primary mechanism: when an object's reference count drops to zero, it's freed immediately. Reference counting alone can't collect two objects that reference each other in a cycle, so a separate generational garbage collector periodically scans for and cleans up cycles that reference counting misses.

Start with cProfile for a function-level breakdown of where time is spent, then use a line-level profiler like line_profiler once you've narrowed it to a specific function, since cProfile alone won't tell you which line inside a slow function is the actual problem. For memory issues specifically, tracemalloc or memory_profiler are the equivalent tools.

A shallow copy (copy.copy) duplicates the outer object but keeps references to the same nested objects, so mutating a nested list inside the copy also changes the original. A deep copy (copy.deepcopy) recursively duplicates everything. This commonly bites people who copy a config dict expecting independence, then mutate a nested list inside it and silently corrupt the 'original' too.

Since strings are immutable, each += in a loop creates an entirely new string object, making the operation O(n) per iteration and O(n^2) overall for n concatenations. The fix is collecting pieces in a list and joining once at the end with ''.join(pieces), which is O(n) overall.

By default, every Python object stores its attributes in a per-instance __dict__, which has real memory overhead. Defining __slots__ on a class tells Python to allocate fixed storage for only the named attributes instead, which meaningfully reduces memory usage when you're creating a very large number of instances of a simple class, at the cost of losing the ability to add arbitrary new attributes dynamically.

A plain attribute is accessed directly with no logic in between. @property lets you expose a method as if it were an attribute, so you can add validation, computed values, or lazy evaluation behind what looks like simple attribute access, without breaking every caller that already does obj.value instead of obj.get_value().

You can override __new__ to return the same instance on every construction call, or use a module-level instance, since Python modules are already singletons by import caching. In practice, singletons are often avoided in Python because they introduce hidden global state that makes testing harder. A module-level instance or dependency injection is usually a cleaner fit.

A property is actually implemented using the descriptor protocol under the hood. A descriptor is a more general, reusable mechanism, a class implementing __get__, __set__, or __delete__, that you attach to multiple classes or attributes, whereas @property is a convenient shortcut for a one-off case on a single class.

A common approach is entry points (via importlib.metadata or the older setuptools mechanism), which let installed packages declare themselves as plugins that your application discovers at runtime without hardcoding imports. A simpler in-house version uses a registry dict and a @register decorator that plugins call to add themselves at import time.

Define fixtures in a conftest.py so they're automatically available across test files without importing, and use fixture scope (function, module, session) to control how often expensive setup, like spinning up a test database, actually runs. Yield-based fixtures also let you write teardown logic after the yield, which runs even if the test fails.

Python remains dynamically typed at runtime, no type is enforced when the code actually executes. Type hints plus mypy add a static analysis layer that catches type mismatches before code ever runs, which most teams now run in CI alongside tests, treating type errors as build failures without changing Python's actual runtime behavior at all.

Never commit secrets to source control. Load them from environment variables or a secrets manager (AWS Secrets Manager, Vault) at runtime, with a library like python-dotenv for local development convenience only. Configuration itself (non-secret values) is typically layered: defaults in code, overridden by environment-specific files, overridden again by environment variables for anything that needs to change per-deployment.

Pin exact versions in a lockfile (via pip-tools, Poetry, or similar) so builds are reproducible, rather than relying on loose version ranges that can silently pull in a breaking update. Separate direct dependencies you actually import from the full resolved dependency tree, and review and update pinned versions deliberately rather than letting them drift indefinitely.

Use tracemalloc to take memory snapshots at intervals and diff them to see which objects are accumulating, since a 'leak' in Python usually means something (a cache, a list, an event listener) is holding references and preventing garbage collection rather than a true C-level leak. Common culprits are unbounded caches, circular references involving objects with __del__, or a growing list that's appended to but never cleared.

A token bucket or sliding-window counter, backed by Redis so it works correctly across multiple app instances rather than an in-memory counter that would reset per process. The choice between algorithms matters: a fixed window is simplest but allows bursts at window boundaries, while a sliding window or token bucket gives smoother, more accurate limiting at the cost of a bit more complexity.

Vertical scaling means a bigger machine. Horizontal scaling means more instances behind a load balancer. Because the GIL caps how much a single Python process can do on multiple cores, Python services generally scale horizontally by running multiple worker processes (Gunicorn workers, multiple containers) rather than expecting one big process to use all of a large machine's cores efficiently.

Horizontally scale via multiple worker processes (via multiprocessing, or a process-per-container model behind a queue like Celery or an equivalent job system), since each process gets its own GIL. For genuinely hot code paths, I'd also consider pushing the computation into a C extension, using NumPy/Cython, or rewriting just that hot path in a compiled language and calling it from Python, rather than fighting the GIL in pure Python.

It depends on the shape of the problem: Django when you want a batteries-included framework with ORM, admin, and auth out of the box for a data-heavy CRUD application. FastAPI when you need async support, high throughput, and automatic OpenAPI docs for an API-first service. Flask when you want minimal structure and full control, often for smaller services or internal tools. I weigh this against what the team already knows well, since a 'better' framework the team doesn't know slows delivery more than a good-enough framework they do.

Run the migration incrementally behind CI: get the old codebase passing under both versions temporarily using compatibility libraries, add automated test coverage for the areas you're about to touch since old codebases are often under-tested, then migrate module by module, merging continuously rather than maintaining a long-lived migration branch that drifts from main. Freezing feature development for a big-bang rewrite is rarely something the business will actually tolerate, so the migration has to be compatible with normal delivery.

I look at whether the capability is core to our competitive differentiation or just supporting infrastructure: build in-house only where it is genuinely core, or where existing options don't fit our specific constraints closely enough to be worth the integration compromise. For supporting infrastructure, buy or adopt open source, since the ongoing maintenance cost of home-grown infrastructure is usually underestimated at the time it's built.

Automate as much as possible: linting (ruff/flake8), formatting (black), and type checking (mypy) enforced in CI so standards aren't a matter of opinion in code review. For things that can't be automated, like architectural conventions, I'd rather document the handful of decisions that actually matter, with the reasoning behind them, since a long style guide nobody reads doesn't actually change anyone's behavior.

Earlier on, I focused mostly on correctness and style in the diff itself. Now I spend more review attention on whether the change is solving the right problem, whether it's consistent with the system's broader architecture, and whether it's setting a precedent I'd be comfortable seeing repeated across the codebase, since at this level the cost of a bad pattern is that ten other engineers copy it.

I'd separate the two skills explicitly: pair on a real piece of their code and walk through how a future reader (including them, in six months) would have to reconstruct their reasoning, rather than giving generic 'write cleaner code' feedback. Concrete, example-driven feedback tied to their own code sticks far better than abstract principles.

I weigh it against actual, measurable cost: how often does this code get touched, how many incidents or slow-downs has it caused, and how much harder does it make the next few roadmap items. Debt that's isolated and rarely touched can usually wait. Debt sitting on a hot path that every team keeps tripping over is worth prioritizing even without a specific incident forcing the issue.

Lead with the shared problem and data rather than a prescribed solution, since staff-level influence works through credibility and clear reasoning, not org-chart authority. I'd also try to find where our incentives already align, most teams do want fewer production incidents and less duplicated work, and frame the proposal in those terms rather than as 'you're doing this wrong.'

Error rate alone won't catch this. Track queue depth and processing latency as leading indicators too, since a queue that's silently backing up often precedes a visible failure by hours. I'd alert on rate-of-change (queue growing faster than it's draining) rather than only static thresholds, and make sure retried and dead-lettered jobs show up on the dashboard alongside successes and hard failures.

First rule out the obvious environmental differences, data volume, connection pool sizing, and whether staging traffic is actually representative of production concurrency. Then I'd want distributed tracing or at least structured logging with timing at each stage of the request, since 'intermittently slow' under real load is very often contention, a lock, a connection pool exhausting, or GC pauses under memory pressure, none of which show up predictably in a low-traffic staging environment.

Treat any public-facing interface as a contract: additive changes are usually safe, but renaming, removing, or changing the behavior of existing functions needs a deprecation period with clear warnings before removal, not a silent breaking change in a minor version bump. I'd also want visibility into who's actually calling the old interface before removing it, rather than assuming nobody depends on it.

Start from actual load testing at realistic traffic shapes rather than linear extrapolation, since bottlenecks (a database, a downstream API's rate limit, single-threaded processing somewhere in the pipeline) rarely scale linearly and often show up well before 10x. I'd identify the actual constraint first, then decide whether the fix is more instances, a caching layer, offloading work asynchronously, or in some cases redesigning the hot path entirely.

This is a behavioral/experience question interviewers use to see how you reason under uncertainty rather than to test a specific technical fact. A strong answer names the actual constraint that forced the decision, the options genuinely on the table, why you picked one knowing it wasn't guaranteed to be right, and what you'd have done differently with the information you have now, rather than presenting the decision as obviously correct in hindsight.

First priority is mitigation over root-causing, roll back, fail over, or shed load if that stops the bleeding, even before you fully understand why it broke. I'd also make sure one person is clearly driving the incident and communicating status, since the most common way incidents drag on longer than necessary is diffuse ownership, not a lack of technical skill in the room.

Weigh it against concrete benefit, performance improvements, security support lifetime, features you're actively blocked without, against the real migration cost and risk to velocity while it's in progress. I'd pilot it on a lower-risk service first rather than upgrading the most critical system first, and I'd want a rollback plan defined before starting, sitting right alongside the forward one.