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.

*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.

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.

None is the single Python object used to represent the absence of a value. It is different from False, zero, an empty string, and an empty collection, even though all of them are treated as false in a condition. I compare a value with None by using is or is not because the check is about whether the value refers to the exact None object.

Use None when a value is missing, unknown, not provided, or has no useful result. None is the only instance of NoneType, so every reference to None points to the same 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?

None is not equal to False, zero, an empty string, or an empty collection. These values are all false in a truth value test, but they can still contain valid information. For example, zero can be a valid count, and an empty list can be a valid result with no items.

Compare a value with None by writing value is None or value is not None. The is operator checks object identity. Writing value == None may call custom equality behavior defined by the value's class, so it is less clear and can produce unexpected behavior.

A function that reaches its end without an explicit return statement returns None. A return statement with no expression also returns None.

The identity check takes constant time and does not create another None object. Python reuses the singleton. In production, None is commonly used for optional arguments, missing database values, cache misses, and operations that do not return useful data. Use a direct None check when other false values are valid.

A common mistake is writing value == None instead of value is None. Another mistake is assuming that None is the same as False, zero, an empty string, or an empty collection. Developers also sometimes write if not value when they only want to detect None. That condition also matches every other false value. Another mistake is forgetting that a function without an explicit returned expression produces None. It is also incorrect to use None as a default argument when the application must distinguish an omitted argument from an argument explicitly set to None.

Start by saying that None represents the absence of a value and is the only instance of NoneType. Then separate it from other false values and state the comparison rule clearly: use is None or is not None.

PEP 8 is the main style guide for Python code. It recommends four spaces for each indentation level, clear naming conventions, organized imports, consistent whitespace, and a maximum line length of 79 characters. Most of its guidance improves readability and does not change runtime behavior. Indentation is the important exception because Python uses indentation to define code blocks. In a real project, I follow the established project style when it differs from PEP 8.

PEP 8 is the main style guide for Python code. Its practical goal is to make code easier to read, review, and maintain. Most of its rules are conventions, not requirements enforced by the Python interpreter.

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?

PEP 8 recommends four spaces for each indentation level. Spaces are preferred over tabs. This matters because Python uses indentation to define code blocks, so inconsistent indentation can change program structure or cause an error.

Function and variable names normally use lowercase words separated by underscores. Class names normally use capitalized words. Constants normally use uppercase words separated by underscores.

Imports usually appear near the top of the file. They should normally be written on separate lines and grouped as standard library imports, third party imports, and local application imports.

PEP 8 also recommends avoiding unnecessary whitespace, while placing spaces around most binary operators. It limits code lines to 79 characters and comments or documentation text to 72 characters. A team may agree on a code limit up to 99 characters. Project consistency takes priority when a documented local convention differs. Following PEP 8 has no inherent runtime or memory cost, although formatters and linters use development and build resources when they run.

A common mistake is saying that Python requires every PEP 8 rule. Most rules are recommendations for readability. Another mistake is treating indentation as only visual style. Python uses indentation to form code blocks, and mixing tabs with spaces for indentation can raise a TabError when the meaning is inconsistent. Other mistakes include putting several unrelated imports on one line, failing to separate import groups, using unclear names, adding spaces inside brackets, adding spaces around keyword argument equals signs, and enforcing the 79 character limit even when a documented project convention uses another limit. Developers should not change stable code only to satisfy style rules when the change adds risk or reduces clarity.

Begin by defining PEP 8 as Python's main style guide. Cover four spaces for indentation, naming, import grouping, whitespace, and line length. Then explain that most rules improve readability rather than runtime behavior, while indentation can affect syntax and program structure. Mention that an established project convention takes priority within that project.

Use list.sort() when I want to change an existing list. It sorts that list in place and returns None. Use sorted() when I want a new sorted list or need to sort another iterable such as a tuple, set, dictionary, or generator. Both accept key for choosing the comparison value and reverse for controlling the sort direction.

The practical choice is simple. Use list.sort() when changing the existing list is acceptable. Use sorted() when the original data must remain unchanged or the input is not a list.

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 sort() method exists only on lists. It rearranges the items inside the same list object and returns None. Returning None helps show that the method performs a change instead of creating a result value.

The sorted() function accepts any iterable. This includes lists, tuples, sets, dictionaries, and generators. It reads the iterable and returns a new list. For a dictionary, it sorts the keys unless another iterable is provided.

Both forms accept key and reverse. Python calls key once for each item and sorts using the returned values. Setting reverse=True produces descending order. Python sorting is stable, so items with equal key values keep their original relative order.

Sorting is usually O(n log n), but already ordered data can be closer to O(n). sorted() needs O(n) memory for its new list. list.sort() avoids that second result list, but the sorting process can still use temporary memory. Items must also have values that Python can compare.

The example uses one employee list as the shared source data. sorted() creates a new list ordered by score and leaves the source list unchanged. A separate copy is then sorted with list.sort(), which changes that copy directly and returns None. Both operations use the score field as the key and reverse=True to place higher scores first.

A common mistake is writing result = values.sort() and expecting result to contain the sorted list. The result is None because sort() changes values directly. Another mistake is calling sort() on a tuple, set, dictionary, or generator. Only lists provide this method. Use sorted() for other iterables. Developers may also forget that sorted() always returns a list, even when the input is another type. The key function does not replace the items. It only provides the comparison value. Sorting values that cannot be compared can raise TypeError. A key function should return values that are mutually comparable. Finally, calling sort() on a shared list can change what other parts of the program observe.

Begin with the main difference. Say that list.sort() changes one list and returns None, while sorted() accepts any iterable and returns a new list. Then mention key, reverse, stable ordering, comparable values, and the memory tradeoff.

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.

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.

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.