46 Microsoft Python Developer Interview Questions & Answers

No, multiple Python threads can normally read the same variable safely when no thread changes the variable binding, the referenced object, or relevant nested state. A lock is usually unnecessary for true read only access. I would still verify that no property, method, callback, or background task can mutate the shared data.

No, multiple Python threads can normally read the same variable safely when no thread changes the binding, the referenced object, or relevant nested state. Reading a name obtains a reference to an object. It does not copy or modify the object, so a normal read has constant time overhead and does not allocate a copy.

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, worker threads can read the same string, number, deeply immutable tuple, or immutable configuration snapshot. A lock is usually unnecessary for this true read only case.

The main limitation is that no assignment is not the same as no mutation. A method, property, lazy cache, iterator, shared list, shared dictionary, or nested mutable object may change state during an apparent read. If a writer exists, readers may observe different logical states. Iterating over a dictionary while its size changes can raise RuntimeError.

The Global Interpreter Lock is not the reason this design is correct. It does not make a sequence of operations atomic, and modern CPython also supports free threaded builds. ([docs.python.org](https://docs.python.org/3/howto/free-threading-python.html?utm_source=chatgpt.com))

In production, finish constructing shared data before starting workers. Prefer immutable snapshots. Use a lock or another synchronization method when updates are possible or several reads must form one consistent snapshot.

A common mistake is assuming that no visible assignment means no mutation. A property, method, iterator, lazy cache, or nested collection may still change state. Another mistake is claiming that the Global Interpreter Lock makes every shared operation safe. It does not make several related operations one atomic action or guarantee one consistent snapshot. Developers may also overlook a background task that updates data which appears read only to the current function.

Start with the direct conclusion that true concurrent reads are normally safe and do not need a lock. Then state the condition clearly: the variable binding, the object, and relevant nested state must remain unchanged. Finish by explaining that the Global Interpreter Lock is not the reason for correctness.

I would define one small DataSource contract with retrieve and update methods. Database, API, and file classes would implement that contract. I would inject the active source into a DataAccessService, use a factory only to build sources from trusted configuration, and replace the injected Strategy when the source changes. Each operation would first capture the current source, so a concurrent switch cannot split one operation across two sources. Business code stays independent from storage details and tests can inject a fake source.

I would define one DataSource Protocol with retrieve and update methods. In Python, Protocol supports structural typing. This means a class satisfies the contract by providing the required methods, even without inheriting from a common base class.

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?

DatabaseSource, ApiSource, and FileSource implement the same contract. DataAccessService receives one source through constructor injection. It delegates each call to that object. The object is also the Strategy because it decides how the operation is performed. A factory converts trusted configuration into the correct concrete source.

At runtime, set_source replaces the active object. Each retrieve or update first captures the current source while holding a small lock, then releases the lock before doing input or output. Therefore, an operation that already started keeps using one source, while later operations can use the new source.

The extra dispatch and lock work are constant time and use constant additional memory. The real cost depends on the source. The sample file implementation reads and writes the complete JSON object, so an update takes linear time and memory in the file size. In production, I would use atomic file replacement, timeouts for APIs, transactions for databases, and cleanup of an old source until active operations finish.

The code defines a DataSource Protocol with retrieve and update methods. DatabaseSource and ApiSource use dictionaries to simulate their storage behavior. FileSource persists one JSON object and uses a lock plus atomic file replacement for safer updates inside one process. DataSourceFactory creates a source from trusted configuration. DataAccessService receives the source through dependency injection. Its set_source method swaps the Strategy while holding a lock. Each operation captures the current source under the same lock and then calls it after releasing the lock. This keeps one operation on one source without holding the service lock during database, network, or file input and output. The service adds constant time dispatch and constant additional memory. File updates remain linear in the JSON file size because the complete object is copied, changed, and written.

A common mistake is placing database, API, and file conditions inside every business method. That couples business logic to storage details. Another mistake is giving each source different return shapes, missing value rules, or exception behavior. Callers need one clear contract. The factory should build objects at the application boundary, not appear throughout business code. A shared service should not switch sources without synchronization. It is also unsafe to close an old database or API client immediately when an active operation may still be using it. Finally, the sample JSON file approach is not suitable for large data because every update reads and rewrites the complete file.

Explain the design in this order: one contract, three source implementations, constructor injection, factory creation, and Strategy replacement. Then state that each operation captures one source, and mention consistent errors, resource cleanup, database transactions, API timeouts, and the linear cost of rewriting a JSON file.

I would use breadth first search because every wheel turn has the same cost, so states are explored in increasing move count. I would store states in a deque, keep dead ends and visited states in sets, generate the eight states reachable by one wheel turn, and mark each valid state visited when I add it to the queue. The first time the target is reached gives the minimum number of moves.

Use breadth first search because every wheel turn costs one move. The initial state is 0000. Each lock combination is a graph state, and turning one wheel creates a neighboring state. A deque stores states waiting to be processed. Python deque supports constant time removal from the left, unlike removing the first item from 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?

Store dead ends in a set for fast membership checks. Return negative one if 0000 or the target is blocked. Return zero if the unblocked target is already 0000. Add 0000 to the queue and visited set. For each state, turn each of four digits once forward and once backward, including wraparound between 0 and 9. This creates eight neighbors. Python strings are immutable, so each neighbor is created with slicing.

Add only neighbors that are not blocked and not visited. Mark each neighbor visited before adding it to the queue. This prevents duplicate queue entries. Return when the target is found. If the queue becomes empty, return negative one. There are only ten thousand possible states. Since each state creates eight fixed length neighbors, time and memory are both bounded by the state space.

The code converts dead ends to a set so blocked state checks are fast. It rejects a blocked initial state and a blocked target before starting the search. It uses collections.deque because removing an item from the left is constant time. Each queue item stores a lock state and the number of moves used to reach it. For every state, the code creates eight neighbors by changing one of four digits forward or backward with wraparound. Python strings cannot be changed in place, so slicing creates each new state. A valid neighbor is marked visited before it enters the queue, which prevents duplicate entries. Breadth first search processes states in increasing move count, so the first valid target match is the minimum. At most ten thousand states can be visited. Each state creates eight strings of fixed length four, so the time cost is O(10000) and the memory cost is O(10000).

Common mistakes include using a list and removing its first item, which shifts the remaining elements, and marking a state visited only after removing it from the queue, which allows duplicate entries. Other mistakes include forgetting wraparound, trying to modify a Python string in place, allowing dead ends into the queue, returning the target before checking whether it is blocked, missing the blocked initial state, and using depth first search even though it does not guarantee minimum moves.

Start by saying that every wheel turn has equal cost, so breadth first search guarantees minimum moves. Then explain why deque is used, why dead ends and visited states are sets, how the eight neighbors are created, and why each state is marked visited when it enters the queue.

I would keep the rectangular data in a Matrix class, place each traversal order behind a TraversalStrategy interface, and implement the boundary logic in SpiralTraversal. Client code asks TraversalFactory for a named strategy and calls traverse. Adding another registered strategy does not change the client flow. Spiral traversal still visits every matrix cell exactly once.

I would separate matrix storage from traversal behavior. Matrix copies the input rows, verifies that every row has the same length, and provides row count, column count, and indexed reading. TraversalStrategy is an abstract base class with one traverse method. Python type hints describe the expected types, but they do not enforce the contract at runtime. The abstract base class prevents an incomplete strategy from being instantiated.

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?

SpiralTraversal keeps four boundaries named top, bottom, left, and right. It reads the top row, right column, bottom row, and left column, then moves inward. Checks before the bottom and left passes prevent duplicates when a layer has only one row or one column.

TraversalFactory stores names mapped to strategy classes and creates a fresh object for each request. The client uses the same selection and traversal flow for spiral or row major order. Each traversal takes linear time because each cell is read once. Returning a list also uses linear result memory. This structure is useful when several traversal orders are required. For one fixed order in a small script, plain functions are usually simpler.

The code defines Matrix as the owner of validated rectangular data. TraversalStrategy defines the common method required by every traversal class. SpiralTraversal uses four shrinking boundaries. RowMajorTraversal shows that another order can follow the same contract. TraversalFactory maps the names spiral and row_major to their classes and returns a fresh instance. It also validates newly registered classes. Client code selects a name and calls the same traverse method. For the example matrix containing the values 1 through 9, spiral order returns 1, 2, 3, 6, 9, 8, 7, 4, 5. Empty matrices and matrices with zero columns return an empty list. The reverse passes are guarded so a single row or single column layer is never visited twice.

Common mistakes include putting storage, selection, and traversal logic in one class, using condition branches throughout client code, and forgetting the checks before the reverse passes. Missing those checks duplicates values in a single row or single column layer. Other mistakes include accepting rows with different lengths without defining their behavior, storing one shared mutable strategy instance, relying on type hints as runtime validation, and claiming that Strategy or Factory makes the traversal faster.

Explain the responsibilities before showing the loop. Matrix owns valid data. TraversalStrategy defines the contract. SpiralTraversal owns the boundary algorithm. TraversalFactory owns selection. Then walk through the 3 by 3 output, mention the duplicate prevention checks, and state the linear time and result memory costs.

I would store the current values in a normal Python set. In __iter__, I would immediately make a shallow copy and return an iterator over that copy. Each iterator then keeps the membership that existed when it was created, while add, remove, and contains continue to use the live set. The main tradeoff is that every iterator creation copies all current values.

The practical solution is to keep one live Python set and copy it when an iterator is created. The add, remove, and contains operations use only the live set. The __iter__ method calls self._items.copy() and immediately returns an iterator over that copy. This timing matters. The snapshot must be captured when iter(snapshot_set) runs, not later when next is first called.

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 copy is shallow. It creates a separate set membership table, but both sets still refer to the same element objects. Later add or remove calls do not change an existing iterator. This implementation uses discard for remove, so removing a missing value does nothing. Set iteration order is not guaranteed, so callers should compare contents rather than order.

Creating an iterator takes linear time and linear extra memory because every current reference is copied into a new set. Reading all values from the iterator also takes linear time. Add, remove, and contains are average constant time. This design works well when stable iteration matters more than copying cost. It is less suitable for very large sets or frequent iterator creation. It also provides no thread safety guarantee, so shared production use needs external synchronization.

The class stores current values in self._items. add inserts a value into the live set. remove uses discard, so a missing value is ignored instead of raising KeyError. contains checks the live set, and __contains__ supports the Python in operator. __iter__ copies the live set at the exact moment iter is called and returns the copied set iterator. The iterator keeps the copied set alive internally, so the local snapshot variable can safely leave scope. In the example, the first iterator captures 1 and 2. Later changes make the live set contain 2 and 3, but the first iterator still produces 1 and 2. A second iterator created after those changes produces 2 and 3. The results are sorted only for stable display because set iteration order is not guaranteed.

A common mistake is returning iter(self._items). That iterator reads the live set and can raise RuntimeError if the set size changes during iteration. Another mistake is using a generator whose body makes the copy. Generator code begins when next is first called, so that design can capture the snapshot too late. Deep copying every element is also unnecessary because the requirement protects membership, not the internal state of each object. Candidates may also promise stable ordering, but Python sets provide no ordering guarantee. Another mistake is using mutable objects whose hash or equality behavior changes after insertion, which can break normal set lookup behavior.

State the snapshot moment first. Explain that __iter__ copies the live set immediately and returns an iterator over that copy. Then mention shallow copy behavior, average constant time live operations, linear iterator creation cost, linear memory cost, and the lack of guaranteed iteration order.

I would model the main business concepts as small Python classes, keep important rules inside domain objects or policy classes, and use a service class to coordinate the workflow. I would pass repositories and other dependencies into the service instead of creating them inside it. This keeps the business logic independent from the web framework and makes it easier to test, change, and extend.

This question asks how to add a business feature to an existing Python backend without putting every rule in one large function or web handler. Before designing it, I would ask the interviewer:

1. What business rules must always be enforced?
2. Which database and external services already exist?
3. What errors should callers receive?
4. Can the same request happen more than once?

I would first identify the domain objects. These are the main business concepts. For an order discount feature, they could be Order and DiscountPolicy.

Each class should have one clear responsibility. Order stores order state and protects rules about valid changes. DiscountPolicy calculates the allowed discount. OrderService coordinates the use case by loading the order, asking the policy for a value, applying the change, and saving the order.

I would pass the repository and policy into OrderService through its constructor. Python stores references to these objects on the service instance. Tests can therefore pass an in memory repository without opening a real database.

The web handler should only parse input, call the service, and translate known exceptions into responses. Database access and business rules should remain separate.

Important cases include a missing order, invalid state, repeated requests, and concurrent updates. A real implementation should use a transaction and locking or version checks when shared data changes. This design creates more Python objects than one large function, but object allocation is usually small compared with database or network work. The main benefit is clearer testing and safer extension.

The example implements an order discount use case. Order is the domain object and owns the rules for changing its discount state. DiscountPolicy calculates the discount amount. OrderRepository is a Protocol that describes the storage operations required by the service without choosing a database. OrderService coordinates loading, calculating, applying, and saving. Its dependencies are passed through the constructor, so tests can use an in memory repository. The example rejects a second discount application and uses Decimal for money values. With the in memory repository, a lookup and save are normally constant time because they use a dictionary. The policy calculation and domain validation also use constant time and constant additional working memory for one order.

Common mistakes include placing every rule inside a Django or Flask handler, creating database connections inside the service, and building one large class that handles unrelated responsibilities. Other mistakes include exposing state changes without validation, using float for money, adding inheritance when a small policy object is enough, and testing only through slow integration tests. Production code must also define transaction boundaries and decide how repeated or concurrent requests are handled.

Start by naming the domain objects and the responsibility of each one. Then explain how the service coordinates them, how dependencies are injected, and how the design is tested. Use one concrete example and clearly separate framework code, storage code, and business rules.

The best prevention method is to define one global order for locks and always acquire them in that order. A deadlock happens when threads or tasks wait forever for resources held by one another. It requires mutual exclusion, holding a resource while waiting, no forced resource removal, and circular wait. The Python GIL does not prevent this. I also keep critical sections short, release locks with context managers, and use timeouts and monitoring to detect unexpected blocking.

The practical rule is to give every lock a stable order and always acquire locks in that order. Suppose thread A holds lock 1 and waits for lock 2, thread B holds lock 2 and waits for lock 3, and thread C holds lock 3 and waits for lock 1. This three lock cycle cannot make progress.

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 deadlock needs four conditions. A resource has one owner. A worker holds one resource while waiting for another. The runtime cannot safely take the resource away. A circular chain of waiting exists. Both threading.Lock and asyncio.Lock can be involved. The GIL does not prevent this because Python code can block while holding application locks.

Prevention removes one condition, usually circular wait through fixed ordering. Avoidance checks whether granting a resource would leave execution in a safe state, but it requires advance knowledge and extra bookkeeping. Detection uses timeouts, thread dumps, task stack inspection, health checks, or application wait tracking. Recovery can cancel an asyncio task, fail an operation, restart a worker, or restart the process. Python cannot safely force a thread to release a lock. Timeouts support detection and recovery, but correct ordering remains the main prevention method.

Common mistakes include assuming the GIL prevents deadlocks, acquiring the same locks in different orders, holding a lock during network or file input, calling unknown callback code while holding a lock, and failing to release a lock after an exception. Another mistake is treating a timeout as prevention. A timeout only limits waiting and may leave partial work that needs cleanup. Developers may also check only pairs of locks and miss circular waits involving three or more locks. Using threading.RLock can prevent one thread from blocking when it reacquires the same lock, but it does not prevent cycles involving different locks.

Start with fixed lock ordering as the practical answer. Then define deadlock, name the four necessary conditions, explain the three lock circular wait, and compare prevention, avoidance, detection, and recovery. State clearly that the GIL does not prevent deadlocks involving application locks.

I would review the existing functions in a fixed order. First, I would trace inputs, return values, exceptions, and side effects. Then I would add runtime validation at trust boundaries, remove credentials from print statements and logs, and inspect risky operations such as dynamic evaluation, shell execution, file access, and broad exception handling. I would make the smallest safe corrections and add tests for valid input, invalid input, and failure paths.

The practical goal is to correct the supplied functions without rewriting the file. I would first trace every value from its source to where it is used. Python type hints describe expected types, but they do not enforce them at runtime. Public functions should therefore reject missing values, wrong types, invalid ranges, malformed text, and unexpected collection contents before performing sensitive work.

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?

Next, I would inspect every print call, log message, and exception message for passwords, tokens, connection strings, personal data, or complete request objects. Secrets should come from environment variables or a secret manager, and logs should contain only safe context.

I would then check for mutable default arguments, missing return paths, inconsistent return types, bare or overly broad except blocks, swallowed exceptions, unsafe eval or exec calls, shell commands built from untrusted strings, path traversal, unclosed files, and unchecked external responses. Files should use context managers, exceptions should be specific, and error messages should not expose secrets.

Finally, I would add tests for normal input, boundary values, invalid types, missing credentials, external failures, and partial results. No source file was included here, so exact line findings cannot be stated.

Common mistakes include treating type hints as runtime validation, printing complete objects that contain secrets, storing credentials directly in source code, catching Exception and hiding the real failure, using mutable lists or dictionaries as default arguments, calling eval or exec on untrusted text, building shell commands with string formatting, accepting file paths without checking their resolved location, opening files without a context manager, ignoring failed external responses, and changing the whole design before proving which behavior is incorrect.

Explain the review in this order: trace data, validate inputs, protect secrets, inspect unsafe operations, verify exceptions and resources, then add tests. State clearly that exact defects must be tied to exact lines in the supplied file.

I would store points in a quadtree and split a full leaf into four children before inserting the next point. Each inserted point also gets a sequence number. A range query skips nodes that do not intersect the query, collects matching points, and sorts them by sequence number so the result keeps original insertion order. I would use one consistent midpoint rule and a maximum depth to handle boundary points and repeated coordinates safely.

This question asks us to store points inside one large rectangle and find points inside smaller query rectangles. Before coding, I would ask:

1. Are rectangle edges inclusive?
2. Can the same point appear more than once?
3. Should an outside point be rejected?
4. Must results keep insertion order?
5. May I use a maximum depth?

A quadtree begins as one leaf. It stores points until it reaches capacity. When another point arrives, the node creates four children, moves its points into them, and inserts the new point into one child.

The child choice must be consistent. This code sends midpoint values west or north. Child rectangles touch at the midpoint, but insertion chooses only one child, so a point is never stored twice.

A query first checks whether its rectangle intersects the node boundary. If not, the node is skipped. Otherwise, it checks stored points and visits children.

Tree traversal does not preserve insertion order. Each point stores a sequence number. Python sorts matches by that number before returning coordinates.

A maximum depth prevents endless splitting when duplicate points always enter the same child. With depth d and capacity c, insertion costs O(d times c) because a split can redistribute up to c points at each level. With constant capacity, this is O(d), and balanced depth is usually O(log n). A query costs O(v plus k log k), where v is visited work and k is matches. Memory is O(n plus m) for points and nodes.

The implementation uses Rect for inclusive containment and intersection tests. QuadtreeNode keeps indexed points in a leaf until a new insertion would exceed capacity. It then creates four children and redistributes every stored point with one deterministic midpoint rule. Quadtree assigns a growing sequence number only after a successful insertion. A range query visits only intersecting nodes, collects matching indexed points, sorts them by sequence number, and returns coordinates in original insertion order. A maximum depth prevents endless splitting for duplicate or extremely close points. With tree depth d and node capacity c, insertion costs O(d times c) because each split can redistribute up to c points. With constant capacity, this becomes O(d), and balanced depth is usually O(log n). Query work is O(v plus k log k), where v is the number of visited nodes and stored points examined and k is the number of matches. Memory is O(n plus m), where n is the number of inserted points and m is the number of created tree nodes.

Common mistakes include placing a midpoint point into more than one child, forgetting to redistribute existing points after a split, and using exclusive comparisons even though query edges are inclusive. Another mistake is assuming recursive traversal preserves insertion order. It does not, so sequence numbers are required. Implementations may also split forever for duplicate points, accept invalid capacities, ignore outside points without documenting the behavior, or claim every operation is always logarithmic.

State the boundary and duplicate rules first. Then explain splitting, redistribution, intersection pruning, and sequence numbers in that order. Mention the maximum depth and give both average and worst case costs instead of claiming guaranteed logarithmic performance.