460 Python Developer Interview Questions & Answers

A Python namespace is a mapping from names to objects. For an unqualified name, Python normally searches the local, enclosing, global, and built in namespaces in that order. Separate namespaces let functions and modules reuse the same name without automatically changing one another.

A Python namespace maps names to objects. After count = 5, the current namespace binds the name count to the integer object 5. The name is not the object itself.

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 an unqualified name inside a function, Python normally follows the local, enclosing, global, and built in lookup order. The local namespace belongs to the current function call. Enclosing namespaces belong to outer functions. The global namespace belongs to the current module. The built in namespace provides names such as print and len.

Namespaces reduce conflicts because separate functions and modules can use the same name independently. Assignment inside a function normally makes that name local to the function. The global statement allows assignment to a module global name. The nonlocal statement allows assignment to a name in an enclosing function.

One important edge case is that assigning to a name anywhere in a function normally makes it local throughout that function. Reading it before the assignment can raise UnboundLocalError.

Namespace entries require memory for name bindings, and lookup adds a small implementation dependent runtime cost. In production code, clear local names, explicit imports, and limited mutable global state make behavior easier to understand and test.

A common mistake is saying that a variable directly contains an object. In Python, a name is bound to an object through a namespace. Another mistake is assuming that assignment inside a function changes a global name. It normally creates or updates a local binding unless global is declared. Developers may also hide built in names by assigning names such as list, str, or len. Another mistake is treating namespace and scope as the same thing. A namespace stores bindings, while a scope defines where a name can be resolved. It is also incorrect to assume that the local namespace is shared by every call to the same function.

Start by saying that a namespace maps names to objects. Then explain the local, enclosing, global, and built in lookup order. Finish with one practical point about shadowing or about two functions safely using the same local name.

A local variable is a name created inside a function and is normally visible only in that function call. A global variable is a name stored in the module namespace. A function can read a global name without a declaration. It needs the global declaration only when it will assign a new value to that name. Mutating an existing global object does not require global when the name itself is not reassigned. In production code, I usually prefer function arguments and return values because they make dependencies clear and testing easier.

The practical rule is to use local names for function work and limit changes to global state.

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?

A name assigned inside a function is local by default. It is visible inside that function call. Its binding disappears when the call ends, although the referenced object can remain alive if another reference still points to it.

A global name is stored in the module namespace. Code in the module and functions in that module can read it. The name normally remains available while the module remains loaded.

A function does not need global to read a global name. It needs global when an assignment should rebind that module level name. Without the declaration, Python treats an assigned name as local throughout the function. Reading it before the local assignment then raises UnboundLocalError.

The global statement is not needed when code only mutates an existing global object, such as appending to a list, because the name is not rebound. Assignment binds a name to an object and does not copy that object. Local and global name access normally has small constant time cost, although local lookup is generally simpler. Mutable global state can make testing and concurrent execution harder to control.

The example creates request_count in the module namespace. The read_count function reads that global name without a global declaration. The record_request function uses global because it assigns a new integer to request_count. The local name message exists only inside that function call. The recent_requests list is also global, but appending to it does not require global because the code mutates the existing list instead of assigning a different object to the name. The assignments only bind names to objects and do not copy the referenced objects.

A common mistake is using global just to read a global name. Reading alone does not require it. Another mistake is assigning to a global name without declaring it global. Python then treats that name as local throughout the function, which can cause UnboundLocalError. Developers may also think that mutating a global list requires global. It does not unless the list name itself is reassigned. Another mistake is assuming that global means one shared namespace for the entire application. A global name belongs to a specific module namespace. Excessive mutable global state can also create test isolation problems and unexpected behavior during concurrent execution.

Start with the main rule. Names assigned inside a function are local by default. Then explain that reading a module level name needs no declaration, while rebinding it requires global. Mention that mutating an existing global object is different from rebinding its name. Finish by explaining why explicit arguments and return values are usually safer in production.

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.

*args collects extra positional arguments into a tuple, while **kwargs collects extra keyword arguments into a dictionary. In a function call, * unpacks an iterable into positional arguments, and ** unpacks a mapping into keyword arguments. I use these forms when the number of values can vary or when forwarding arguments, but I prefer explicit parameters when the expected inputs are known.

*args and **kwargs let a function receive additional arguments when their exact number is not fixed. In a function definition, *args collects unmatched positional arguments into a tuple. Positional arguments are matched by their order. **kwargs collects unmatched keyword arguments into a dictionary. Keyword arguments are passed using names.

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?

The names args and kwargs are conventions. The star symbols create the behavior. Even when no extra values are passed, the function receives an empty tuple for *args and an empty dictionary for **kwargs.

The syntax works in the opposite direction during a call. One star reads values from an iterable and passes them as separate positional arguments. Two stars read a mapping and pass its entries as separate keyword arguments. Keyword names produced by ** must be strings.

These forms are useful in wrappers, decorators, callbacks, configuration helpers, and functions that forward arguments. However, they can hide which inputs are accepted. Explicit parameters are clearer when the interface is known.

Python must process every collected or unpacked value, so call setup time and temporary memory grow with the number of arguments. Duplicate keyword names and invalid keyword keys raise TypeError.

The example defines a function with one required parameter, extra positional parameters, and extra keyword parameters. The name parameter receives the required value. scores receives the remaining positional values as a tuple. details receives the remaining keyword values as a dictionary. The first call passes each value directly. The second call uses * to unpack a list into positional arguments and ** to unpack a dictionary into keyword arguments. Both calls give the function the same values and produce the same output.

A common mistake is thinking args and kwargs are required names. They are only conventions. The star symbols create the behavior. Another mistake is expecting *args to be a list, but it is a tuple. kwargs is a dictionary. Developers may also use flexible parameters when named parameters would make the interface clearer. During a call, duplicate keyword names raise TypeError. Values passed with must come from a mapping, and every resulting keyword name must be a string. Unpacking an iterable with * also consumes its values, so a generator may be exhausted after the call.

Explain the two directions clearly. In a function definition, the stars collect extra arguments. In a function call, the stars unpack stored values. Then state that *args is a tuple, **kwargs is a dictionary, and explicit parameters are better when the accepted inputs are known.

Default function arguments let callers omit selected arguments because the function already has stored values for them. Python evaluates each default expression when the def statement runs, not each time the function is called. Immutable defaults such as numbers, strings, and None are usually safe. For a list, dictionary, or set that should be new for every call, I use None and create the object inside the function.

The practical rule is simple. Use a fixed immutable value as a default. Use None when each call needs a new mutable 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?

A default function argument is a parameter that has a value in the function definition. When the caller omits that argument, Python uses the stored default value. The caller can still provide another value.

Python evaluates a default expression when execution reaches the def statement. The resulting object is stored with the function. If the def statement runs again, such as when an enclosing function is called again, new defaults are created for that new function object.

This behavior matters for mutable objects. A list, dictionary, or set can change after creation. If one is used as a default and the function changes it, later calls that omit the argument reuse the same object and can see earlier changes.

The safe pattern is to use None and create a new object inside the function. This adds one small allocation for each omitted call. Memory is separate for each created object and grows only with the data stored in it. When None is a valid input, use a unique sentinel object instead.

The function uses None as the stored default. When the caller omits items, the function creates a new list for that call. The first call returns a list containing apple. The second call returns a different list containing banana. When the caller provides an existing list, the function uses and changes that exact list. The final two printed values both contain orange and grape because they refer to the same provided list.

A common mistake is believing that Python evaluates a default expression for every call. Another mistake is using an empty list, dictionary, or set as a default and changing it inside the function. Developers may also write if not items when they only want to detect an omitted value. That condition also treats an intentionally empty list as missing. Use if items is None when None is the marker. Another mistake is assuming a function call used as a default runs on every call. It runs when execution reaches the def statement. Mutable defaults can be used intentionally for shared state or caching, but that behavior should be explicit, documented, and carefully tested.

Start with the main rule that Python evaluates default expressions when the def statement runs. Then explain that callers may omit those arguments. Finish with the mutable default bug and the None pattern. This clearly covers the behavior, the risk, and the safe solution.

Positional only parameters must be passed by position, while keyword only parameters must be passed by name. Parameters before / are positional only. Parameters after * are keyword only. Parameters between the two markers can usually be passed either way. API authors use these rules to make calls clearer, prevent incorrect argument order, and avoid making some parameter names part of the public API.

Use / and * when a function should control how callers provide arguments. Parameters before / are positional only. Their values must be supplied in order. Parameters after a bare * are keyword only, so callers must write their names. Parameters between / and * can normally be passed by position or by name.

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 example, def resize(width, height, /, *, keep_ratio=True) requires width and height by position and keep_ratio by name. Therefore, resize(800, 600, keep_ratio=False) is valid. Passing width=800 or passing False as a third positional value raises TypeError during argument binding.

An API author may hide positional only parameter names so those names can change later without breaking callers. Keyword only options make calls easier to read and reduce mistakes when several values have similar types. However, unnecessary restrictions can make a simple function less convenient. These markers do not change the function result and do not create separate application data. Their direct performance and memory effects are normally insignificant. The main benefits are readability, safer calls, and better control of API compatibility.

The function places width and height before /, so callers must pass them by position. It places keep_ratio after *, so callers must pass it by name. The valid call prints the supplied values. Each invalid call is placed inside a try block so the program can show the TypeError raised during argument binding and then continue.

A common mistake is thinking callers include / or * in a function call. These markers appear only in the function definition. Another mistake is assuming every parameter before * is positional only. A parameter is positional only only when it appears before /. Developers may also forget that parameters between / and * can usually be passed either by position or by name. Another mistake is changing an existing public signature without checking callers, because adding either restriction can break previously valid calls. Finally, the name of a positional only parameter can still appear as a separate key inside **kwargs when the function accepts extra keyword arguments.

State the rule for / first, then the rule for *. Show one short function signature and one valid call. Finish by explaining that the main purpose is clearer calls and better API compatibility, not faster execution.

A lambda function is a small anonymous function created with the lambda keyword. It can accept multiple arguments, but its body contains one expression. Python evaluates that expression and returns the result automatically. I use a lambda for a short operation passed to a function such as sorted. I use a named function when the logic needs several steps, reuse, testing, or a clear name.

Use a lambda when you need a very small function for a short and clear operation. A lambda function is created with the lambda keyword. Arguments appear before a colon, and one expression appears after it. For example, lambda value: value * 2 creates a function that returns twice the given value.

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?

A lambda does not need a name when it is created, but Python still creates a normal function object. The function can be stored, passed to another function, or called later. Python evaluates the single expression and returns its result automatically. Statements such as return, try, and normal assignment statements cannot appear in the body. Some expression forms, including a conditional expression, are allowed, but complex expressions reduce readability.

Lambdas are useful as short key functions for sorted, min, and max, or as small callbacks. A named function is clearer when logic needs several steps, reuse, documentation, type hints, testing, or error handling. A lambda has no special speed advantage over def. Creating either form allocates a function object. If a lambda closes over outside variables, it keeps references to them, which can extend the lifetime of those objects.

A common mistake is thinking that lambda creates a special or faster kind of function. Python creates a normal function object, and lambda has no special speed benefit. Another mistake is trying to place statements such as return, try, or a normal assignment statement inside the body. Only one expression is allowed. Developers may also place complex conditional logic inside a lambda, which makes the code hard to read. Another important mistake appears when lambdas created inside a loop close over the same changing variable. The variable is looked up when the function is called, so every lambda may see the final loop value unless the current value is captured with a default argument.

Start by saying that a lambda is a small anonymous function with one expression. Explain that the expression result is returned automatically. Give one practical use such as a sorting key. Finish by saying that a named function is clearer for complex, reusable, documented, or separately tested logic.

A list comprehension is a concise way to create a new list from an iterable. Its basic form is [expression for item in iterable], and it can include an optional filter such as [expression for item in iterable if condition]. It creates the complete list immediately. I use it for one clear transformation and perhaps one simple condition. I use a normal loop when the logic needs several steps or becomes difficult to read.

A list comprehension creates a new list by iterating over an iterable and evaluating an expression for each selected item. Its basic syntax is [expression for item in iterable]. An optional filter appears after the for clause, as in [number * number for number in numbers if number % 2 == 0].

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 numbers equal to [1, 2, 3, 4, 5, 6], Python visits each value in order. It tests whether the number is even. When the condition is true, it squares the number and adds the result to the new list. The output is [4, 16, 36]. An equivalent loop starts with an empty list, checks the same condition, and calls append with the same expression.

For this example, both forms take linear time because they inspect every input value. If n values are checked and k results are kept, the new list uses space proportional to k, not counting the internal size of newly created result objects.

A comprehension is best for simple transformation and filtering. Use a normal loop for complex conditions, several actions, logging, error handling, or logic that needs clear intermediate steps.

A common mistake is putting the filter before the for clause. A filtering condition belongs after the iterable clause. Another mistake is using a comprehension only for side effects, such as printing values or changing unrelated state. A comprehension should normally create useful result values. Developers may also place several conditions, nested loops, or long expressions inside one comprehension, which can make valid code difficult to understand. Another mistake is assuming that a comprehension changes the original list. It creates a new outer list. However, if the new and original lists contain references to the same mutable objects, changing one shared object can be visible through both lists. An empty iterable is not an error. It simply produces an empty list. If the expression or condition raises an exception, list creation stops and the exception is propagated.

Start with the basic syntax. Show one example with a filter. Explain the equivalent loop and state that both create the same result. Then mention eager list creation, linear work for a simple single loop, and the readability rule: use a normal loop when the comprehension becomes hard to understand.

Unpacking lets Python take values from an iterable and assign them to several targets in one statement. Normal unpacking requires the number and structure of the values to match the targets. A starred target can collect remaining values into a new list. Unpacking is useful for fixed records, swapping values, and nested data, but it should be used carefully when the input shape may change.

Unpacking lets Python assign items from an iterable to several targets in one statement. For example, name, age = ("Amina", 30) assigns one value to each target. Python iterates over the object and requires the values to match the target structure.

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?

Normal unpacking raises ValueError when there are too few or too many values. A starred target handles a variable number of values. In first, *middle, last = values, Python assigns the first and last items normally and stores the remaining items in a new list named middle. Only one starred target is allowed at the same assignment level.

Python also supports swapping with left, right = right, left. Python evaluates the right side first, then assigns those results to the targets. Nested unpacking works when the target shape matches the data shape, such as name, (city, country) = user.

Use unpacking for stable records, function results, dictionary item iteration, and clear data extraction. Avoid deep or fragile unpacking when external data may change. Unpacking processes the required items, so its time cost grows with the number of values read. A starred target also allocates a new list for the collected values.

Common mistakes include using a different number of targets and values, which raises ValueError, and using more than one starred target at the same assignment level, which causes SyntaxError. Another mistake is assuming that a starred target preserves the original iterable type. Python stores the collected values in a new list. Nested unpacking also fails with ValueError when the data shape does not match the target shape. Deep unpacking can reduce readability and make changing input formats harder to handle.

Begin by saying that unpacking assigns iterable values to several targets. Then explain exact matching, starred targets, swapping, nested unpacking, and ValueError. Mention that a starred target creates a new list and that unpacking is safest when the input shape is stable.

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.