460 Python Developer Interview Questions & Answers

Python resolves a name in Local, Enclosing, Global, and Built in scope order. It stops when it finds the first matching binding. Assignment inside a function normally creates or changes a local name. The global declaration makes assignment use the module scope, while nonlocal makes assignment use the nearest enclosing function scope that already contains that name.

Python uses the LEGB rule to decide which binding a name refers to. It checks the Local scope of the current function first. It then checks Enclosing function scopes, starting with the nearest outer function. Next, it checks the Global scope of the current module. Finally, it checks the Built in scope, which contains names such as len and print. Python uses the first match. If no match exists, it raises NameError.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

Assignment has an important rule. Assigning to a name inside a function normally makes that name local throughout that function. Reading it before the local assignment can therefore raise UnboundLocalError. The global declaration makes assignments target the module scope. The nonlocal declaration makes assignments target an existing binding in the nearest enclosing function scope. It cannot target the module scope.

These rules matter in closures, decorators, callbacks, and nested helper functions. Use global and nonlocal only when changing outer state is intentional. Passing values and returning results is often clearer. Name lookup does not copy the referenced object. It only finds a binding. The lookup cost is normally small, and it does not create a new object by itself.

The example uses the same name in module and enclosing function scopes. The first nested function only reads the name, so Python finds the nearest enclosing binding. The second nested function declares the name as nonlocal, so its assignment changes the enclosing binding. The final function declares the name as global, so its assignment changes the module binding. The printed output shows each change in that order.

A common mistake is thinking that assignment searches all LEGB scopes. Normal assignment inside a function creates or changes a local binding. Another mistake is reading a name before assigning to it in the same function, which can raise UnboundLocalError. Developers may also use global when they need nonlocal, or try to use nonlocal when no enclosing function binding exists. Another mistake is assuming that a class body acts like an enclosing function scope for methods. Shadowing Built in names such as list, str, or print can also make code confusing.

State the LEGB order first. Then clearly separate name lookup from assignment. Explain that global targets the module scope and nonlocal targets an existing binding in the nearest enclosing function scope. Mention UnboundLocalError as the main assignment edge case.

Sequence slicing selects items with sequence[start:stop:step]. Start is included, stop is excluded, and step controls the direction and distance between selected items. Omitted bounds use defaults that depend on the step direction. Negative indices count from the end, and a negative step can produce a reversed result. For a list, slicing creates a new outer list and copies references to the selected elements. Immutable built in sequences return a result of the same type, but code should not depend on whether Python reuses an existing immutable object for some slices.

Sequence slicing uses sequence[start:stop:step]. Start is the first included position. Stop is the first excluded position. Step tells Python how far to move after each selected item. The normal step is 1, and a step of zero raises ValueError.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

For values = [10, 20, 30, 40, 50], values[1:4] returns [20, 30, 40]. An omitted start normally means the beginning, and an omitted stop normally means the end. With a negative step, the defaults change so Python can move from right to left. For example, values[::-1] returns [50, 40, 30, 20, 10].

Negative indices count from the end. values[-3:] returns [30, 40, 50]. Slice bounds outside the sequence are adjusted safely, so slicing normally returns a shorter or empty result instead of raising IndexError.

A list slice creates a new outer list, but nested mutable objects are still shared because the copy is shallow. Tuple, string, and bytes slices return the same sequence type. Python may reuse an immutable object for some full or empty slices, so object identity should not be assumed. A typical slice selecting k items takes about O(k) time and O(k) extra memory.

A common mistake is expecting the stop position to be included. Another mistake is using a step of zero, which raises ValueError. Developers may also choose incorrect start and stop values for a negative step because movement is from right to left. Some assume a list slice is a deep copy, but nested mutable objects remain shared. Another mistake is comparing slice results with is and assuming every immutable slice must have a new identity. Code should compare values unless object identity is part of a documented guarantee. Repeated large slices can also create avoidable copying and memory use.

Begin with the rule that start is included and stop is excluded. Then explain step, omitted bounds, negative indices, and reverse slicing with one small list. Finish by stating that list slicing makes a shallow outer copy, while immutable sequence identity should not be assumed.

F strings are usually the most readable way to place Python values and expressions inside text. I add the letter f before the opening quote and put each expression inside braces. Python evaluates the expressions when that line runs and builds a new string from their formatted results. I can use conversion flags such as !r, a format specification after a colon, and the equals debugging syntax. I keep expensive work outside the f string and do not treat formatted output as automatically safe for SQL, HTML, or shell commands.

F strings place evaluated Python expressions inside text. Add the letter f before the opening quote and put an expression inside braces. For example, f"{name} owes ${balance:.2f}" inserts a name and displays a number with two decimal places.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

Python evaluates each expression when the statement runs. The result is converted and added to a newly created string. A conversion flag controls the first conversion step. !s uses str, !r uses repr, and !a uses ascii. A format specification follows a colon and controls details such as width, alignment, decimal places, percentage display, or date formatting when the value supports that rule.

The equals debugging syntax, such as f"{balance=}", includes the expression text and its value. Literal braces must be doubled as {{ and }}.

F strings are preferred when developers control the format because the value and its display rule stay close together. They do not make data safe for SQL, HTML, or shell commands. Their runtime cost includes evaluating every expression and creating the result string. Memory use mainly depends on the final text size and any temporary objects created by the expressions.

The example uses the same customer name and balance throughout. The first f string inserts both values and formats the balance with two decimal places. The second uses !r to show the representation of the name. The third uses the equals debugging syntax to include the expression name and value. The fourth doubles the outer braces so they appear as literal text. Every statement creates a new result string after evaluating its expressions.

Common mistakes include forgetting the letter f, using single braces when literal braces are required, placing a conversion flag after the format specification, and applying a format rule that the value does not support. Another mistake is hiding slow function calls or expressions with side effects inside braces. Developers may also assume that an f string escapes values for SQL, HTML, URLs, or shell commands. It does not. Using eval on untrusted text to create dynamic f string behavior is also unsafe because it can execute Python code.

Begin by saying that an f string evaluates expressions inside braces when the statement runs and creates a new string. Show one small example. Then explain conversion flags, the colon format specification, the equals debugging syntax, and doubled literal braces. Finish with the allocation cost and the fact that formatting does not provide security escaping.

Use try for code that may fail, except for expected errors, else for work that should run only when try succeeds, and finally for cleanup. Python checks except clauses from top to bottom and runs the first compatible handler. The finally block normally runs whether the operation succeeds, fails, or returns, so it is useful for releasing resources.

Use try for code that may fail, except for expected errors, else for work that should happen only after success, and finally for cleanup. Python runs the try block first. If try finishes without an exception, Python skips every except block, runs else, and then runs finally. If an exception is raised inside try, Python stops the remaining statements in that block and checks the except clauses from top to bottom. The first clause with a compatible exception type runs. A handler for a parent class also matches its child exception classes, so specific handlers should come before broad handlers.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

If no handler matches, the exception continues to the caller after finally runs. An exception raised inside else is not handled by the earlier except clauses, but finally still runs. Finally also normally runs before return, break, or continue completes. It is therefore useful for closing files, releasing locks, and freeing other resources.

Finally is not an absolute guarantee if the process is forcibly stopped or exits immediately. Avoid return inside finally because it can hide an active exception or replace an earlier return value. In production, catch only errors you can handle and keep the try block small.

The example creates an in memory text stream and tries to read an integer from it. Valid text lets the try block finish, so else prints the converted value. Invalid text raises ValueError, so the matching except block prints an error message. The finally block closes the stream in both cases. An unexpected exception would continue to the caller after the stream is closed.

A common mistake is catching Exception when only one known error is expected. This can hide unrelated problems. Another mistake is placing too much code inside try, which makes it difficult to know which operation failed. Developers may expect else to run after except, but else runs only when try finishes without an exception. An error raised inside else is not caught by the earlier except clauses. A broad handler placed before a specific handler also prevents the specific handler from running. Avoid a bare except because it also catches signals such as KeyboardInterrupt and SystemExit. Returning from finally can suppress an active exception or replace an earlier return value.

Explain the blocks in execution order. Say that try performs the risky work, except handles the first matching error, else means the try block succeeded, and finally performs cleanup. Also mention that specific exception types should come before broad ones.

Python is both compiled and interpreted. In CPython, source code is first compiled into bytecode. The CPython evaluation loop then executes that bytecode inside the Python runtime. This normally happens automatically when the program runs. Python itself is a language, so another implementation, such as PyPy, may use a different execution strategy, including just in time compilation.

Python is both compiled and interpreted, but the exact process depends on the implementation. In CPython, source code is parsed and compiled into bytecode before its statements execute. Bytecode is a set of instructions for the CPython runtime. The CPython evaluation loop reads those instructions and performs the requested operations.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

This work normally happens automatically. Developers do not need to run a separate compiler first. When CPython imports a module, it may save compatible bytecode in the __pycache__ directory. A later import can reuse that cache and avoid compiling the unchanged source again. The cache mainly reduces import work. It does not make normal program operations execute as native machine code.

Compilation can also expose syntax errors before the affected code begins execution. Dynamic features such as exec and eval compile supplied source while the program is running.

Python is the language, while CPython and PyPy are implementations. PyPy may use just in time compilation for frequently executed code. This can improve some long running workloads, but it can add warmup time and memory use. Production teams should test startup time, memory, library compatibility, and real workload performance before choosing an implementation.

A common mistake is saying that Python is only interpreted. In CPython, source code is compiled into bytecode before execution. Another mistake is saying that CPython normally compiles the whole program directly into native machine code. Standard CPython usually executes Python bytecode through its runtime. Candidates also confuse Python with CPython. Python is the language, while CPython is one implementation. Another mistake is assuming that __pycache__ always speeds up the whole program. It mainly avoids repeated compilation during compatible module imports. Cached bytecode is also tied to implementation and version compatibility, so it should not be treated as a universal deployment format.

Begin with the conclusion that Python is both compiled and interpreted. Then explain the CPython path in order: source code is parsed, compiled into bytecode, and executed by the runtime. Finish by saying that Python is a language and that implementations such as CPython and PyPy can use different execution strategies.

Dynamic typing means a Python name is not restricted to one type. The name is bound to an object at runtime, and the object has the type. For example, value can first refer to the integer 10 and later refer to the string "ten". This flexibility makes Python convenient, but an invalid operation may fail only when that line runs. Type hints can find some mistakes earlier, but Python does not enforce them at runtime by default.

Dynamic typing means a Python name can refer to objects of different types during one program run. The type belongs to the object, not to the name. For example, value = 10 binds value to an integer object. Later, value = "ten" rebinds the same name to a string object.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

Rebinding does not convert the integer into a string. It only changes the object referenced by value. Another name may still refer to the original integer object.

Python checks whether an operation is valid when that operation runs. For example, adding an integer to a string raises TypeError. A faulty path may remain unnoticed until tests or real input execute it.

Static type checking is different. Tools can inspect type hints before execution and report likely mismatches. Python itself still remains dynamically typed because annotations do not normally restrict assignments or enforce argument types at runtime.

Dynamic typing is useful for flexible functions and changing input data. In production, use clear interfaces, type hints, tests, and runtime validation at system boundaries. Binding a name does not copy the referenced object. Any allocation cost comes from creating the new object, not from dynamic typing itself.

A common mistake is saying that a Python variable changes its own type. More precisely, a name is rebound to another object, and each object has a type. Another mistake is saying that Python has no types. Python is strongly typed at runtime, so unsupported mixed type operations can raise TypeError. Candidates also confuse dynamic typing with automatic conversion between unrelated types. Python does not freely convert every value. Another mistake is assuming type hints enforce types during execution. They do not do so by default. Finally, changing a name binding should not be confused with mutating a shared object.

Start with the rule that names refer to objects and objects have types. Show one simple rebinding example. Then contrast runtime checks with static checking through type hints. Finish by mentioning tests and runtime validation for production inputs.

The pass statement performs no action. It is mainly used as a valid placeholder when Python requires a statement inside a block, but no behavior is needed yet. Execution continues with the next statement. Unlike continue, pass does not skip the rest of a loop iteration. Unlike break, it does not end the loop.

The pass statement performs no action. When Python reaches it, execution continues with the next statement.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

Python requires at least one statement inside an indented block. For example, a function, class, loop, condition, or exception handler cannot have a completely empty body. Pass can fill that body while keeping the code syntactically valid.

A developer may use pass while defining an unfinished function, creating an empty class, keeping one condition intentionally empty, or temporarily leaving a loop body blank. It can also appear in an exception handler when a specific and expected exception should be ignored. That use requires care because ignoring an exception can hide a real problem.

Pass does not change control flow. In a loop, continue skips the remaining statements in the current iteration and starts the next iteration. Break exits the nearest loop. Pass does neither, so later statements in the same block still run.

Pass does not copy values or create an application data structure. Its performance and memory effect are normally insignificant. Its main value is providing a valid statement where Python syntax requires one.

A common mistake is believing that pass skips the current loop iteration. Continue does that. Another mistake is believing that pass exits a loop. Break does that. Developers may also leave pass inside an unfinished function and accidentally release code with missing behavior. Using pass in a broad exception handler is another mistake because it can hide unexpected errors without logging or handling them.

Begin by saying that pass performs no action and is used as a valid placeholder. Then explain that execution continues normally. Finish by comparing it with continue, which skips an iteration, and break, which exits a loop.

The main rule is that break exits the nearest loop, continue skips the rest of the current iteration, and a loop else clause runs only when the loop finishes without break. Continue does not prevent else from running because it does not end the loop. This is useful for searches where break handles a found result and else handles the case where every item was checked without finding a match.

Use break to stop the nearest loop. Use continue to skip the rest of the current iteration. Use a loop else clause for work that should happen only when the loop finishes without break.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

In a for loop, else runs after all items are exhausted. In a while loop, else runs when the condition becomes false. It also runs when the loop has zero iterations. Continue does not skip else because it does not end the loop. The else clause is skipped when break runs. It is also not reached when return or an exception leaves the loop before normal completion.

This pattern is useful for a search. The loop checks each user name. Empty names are skipped with continue. A match prints the result and uses break. If no match is found, else reports that every item was checked.

For a list of n items, the worst case time is O of n because every item may be checked. Break can stop earlier. The loop uses O of one extra memory because it does not copy the list or create another collection. Use loop else when it makes the no match path clear. Avoid it when the control flow may confuse readers.

The example searches a list of user names. An empty name is skipped with continue, so the loop moves to the next item. When the requested name is found, break exits the loop and the else clause is skipped. When no matching name exists, the for loop reaches the end of the list without break, so the else clause runs. The function checks at most every item, creates no copy of the list, and uses only a small fixed amount of extra memory.

A common mistake is thinking that loop else runs whenever the loop condition is false during an iteration. It runs once after normal completion without break. Another mistake is thinking that continue skips the else clause. Continue only skips the remaining statements in the current iteration. Break also exits only the nearest loop, not every nested loop. In a while loop, placing continue before the statement that updates the loop condition can cause an infinite loop. Developers may also forget that else runs when a for loop receives an empty collection because no break occurred.

State the three rules first. Break exits the nearest loop. Continue skips the rest of the current iteration. Else runs only when the loop finishes without break. Then give a small search example and mention that continue does not prevent else from running.

zip() combines two or more iterables one position at a time and returns an iterator of tuples. By default, it stops when the shortest iterable ends. I use strict=True when every iterable must contain the same number of values. The values in each tuple can be unpacked directly inside a loop.

Use zip() when values from different iterables belong together by position. For example, it can combine a list of names with a list of scores. The first name is paired with the first score, the second name with the second score, and so on.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

zip() returns an iterator. It creates each tuple only when iteration requests it. It does not build a complete list of results in advance. This keeps its additional memory use small, although the input iterables still remain in memory if they are stored collections.

By default, zip() stops when the shortest iterable ends. Any remaining values in longer iterables are not included. This is useful when truncation is intentional, but it can silently hide missing data.

Use strict=True when all inputs must have equal lengths. Python then raises ValueError when one iterable ends before the others. This behavior is useful when mismatched data should be rejected instead of ignored.

Each generated tuple can be unpacked directly, such as for name, score in zip(names, scores). A zip object is normally consumed as it is iterated. Convert it to a list only when the complete result must be stored, indexed, or reused.

The example combines names and scores by position. The first loop uses strict=True because each name must have exactly one score. Each generated tuple is unpacked into name and score. The next statement creates a dictionary from the same matching values. The final example shows that strict=True raises ValueError when one input ends before the other.

A common mistake is assuming zip() keeps all values from the longest iterable. Normal zip() stops at the shortest iterable and leaves remaining values unused. Another mistake is forgetting that zip() returns an iterator, so it is usually consumed after one complete pass. Developers may also use normal zip() when unequal lengths should be treated as invalid data. Another mistake is expecting strict=True to raise an error when the zip object is created. The mismatch is detected only when iteration reaches the point where one input ends before another. Unpacking into the wrong number of variables also raises an error.

Start by saying that zip() combines iterables by position. Then explain that it returns an iterator, normal zip() stops at the shortest input, strict=True raises ValueError during iteration for unequal lengths, and each tuple can be unpacked directly.

In Python 3, map() returns a map object, and filter() returns a filter object. Both objects are lazy iterators, so they produce values only when code requests them. map() transforms items by applying a function, while filter() keeps items whose test returns a true value. I convert the result to a list only when I need all values stored or need to read them more than once.

In Python 3, map() returns a map object, and filter() returns a filter object. Both are lazy iterators. Python does not calculate and store every result when these objects are created. It requests input values and calls the supplied function only as the result is consumed.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

map() applies a function to each input item. It can accept more than one iterable and stops when the shortest iterable ends. For the numbers [1, 2, 3, 4], a doubling function produces 2, 4, 6, and 8.

filter() tests each item and returns the original item when the test is true. With an even number test, the same input produces 2 and 4. When the function is None, filter() keeps items whose own truth value is true.

Lazy evaluation supports processing one value at a time. If all n input items are consumed, the work is proportional to n. The iterator itself uses small extra memory, but converting it to a list stores all results and uses memory proportional to the result size.

These iterators are normally consumed once. Use comprehensions when they express simple logic more clearly.

The example uses the numbers [1, 2, 3, 4] throughout. map() creates a lazy map object that doubles each number when the object is consumed. filter() creates a lazy filter object that keeps only even numbers. The program prints the exact object types before requesting the values. Converting each object to a list consumes it and produces [2, 4, 6, 8] for map() and [2, 4] for filter(). A second conversion of the same map object produces an empty list because that iterator has already been exhausted.

A common mistake is expecting map() and filter() to return lists in Python 3. Another mistake is expecting the function to run immediately when the iterator object is created. Printing the object itself does not display all generated values. A developer may also consume an iterator once and incorrectly expect it to return the same values again. Converting a large iterator to a list removes the main memory advantage of lazy processing. It is also incorrect to say that filter() returns the test results because it returns the original input items whose tests are true.

Begin by naming the exact return types. Then explain that both are lazy iterators and are normally consumed once. Clearly state that map() transforms values while filter() selects original values. Mention list conversion and comprehensions only after explaining the core runtime behavior.