460 Python Developer Interview Questions & Answers

Python sends every normal attribute read through __getattribute__. The default lookup first checks the class hierarchy for a data descriptor. It then checks the instance __dict__. After that, it checks the class hierarchy for a non data descriptor or a normal class attribute, following the method resolution order. If lookup raises AttributeError, Python calls __getattr__ when it is defined. I normally use __getattr__ for missing values and override __getattribute__ only when every read must be controlled. Inside an override, I delegate to object.__getattribute__ to avoid infinite recursion.

The practical rule is to preserve Python's normal lookup and customize only the part you need. Every expression such as user.name starts with __getattribute__. The default implementation first searches the class and its base classes for a data descriptor. A property is a common example. It then checks the instance __dict__, which stores normal instance attributes when the class allows one. Next, it searches the class hierarchy again for a non data descriptor or a regular class value, following the method resolution order. Normal methods are non data descriptors and become bound methods when read through an instance. If no value is found and AttributeError leaves __getattribute__, Python calls __getattr__ as a fallback. This is useful for lazy values, compatibility names, and proxy objects. A class using __slots__ may not have an instance __dict__. Reading an attribute normally returns a reference to the stored object rather than copying it. Custom __getattribute__ code runs on every read, so it can add noticeable cost. It can also recurse forever if it reads another attribute through self instead of delegating to object.__getattribute__.

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 example uses the same lookup rules described in the answer. name is stored in the instance __dict__. category is inherited from the base class. display_name is a property, so it acts as a data descriptor on the class. The __getattribute__ override records each read and then delegates to object.__getattribute__, which preserves descriptor handling, instance lookup, and class hierarchy lookup. When nickname cannot be found normally, __getattr__ creates a fallback value. Any other missing name raises AttributeError so that Python tools such as hasattr continue to behave correctly.

A common mistake is saying that Python always checks the instance dictionary before the class. A data descriptor on the class has higher priority than the instance __dict__. Another mistake is treating __getattr__ and __getattribute__ as the same hook. __getattribute__ handles every normal read, while __getattr__ is a fallback for a missing name. Reading self.some_name inside an unsafe __getattribute__ override can call the same method again until RecursionError occurs. Returning a default for every name in __getattr__ can hide spelling mistakes and make hasattr report that an attribute exists when it should not. It is also incorrect to assume every instance has a __dict__, because a class using __slots__ may not provide one.

State the lookup order clearly. Start with data descriptors, then the instance __dict__, then non data descriptors and class attributes through the method resolution order. Explain that __getattribute__ handles every read and __getattr__ handles only a missing name. Finish by mentioning delegation to object.__getattribute__, recursion risk, and the possible absence of __dict__ when __slots__ is used.

Exception chaining connects a new exception to an earlier exception. If I raise a new exception while handling another one, Python automatically stores the earlier exception in __context__. If the earlier exception is the direct cause, I use raise NewError from original_error, which stores it in __cause__. If I use from None, Python hides the automatic context from the normal traceback but does not remove the stored __context__. Explicit chaining is usually best when translating a low level failure into a clearer application error because the traceback keeps the real cause.

The practical rule is to preserve the earlier exception when it explains why the new exception occurred. If a new exception is raised while another exception is being handled, Python automatically assigns the active exception to the new exception's __context__. The traceback normally says that another exception occurred while handling the earlier one.

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?

Use raise NewError from original_error when the earlier exception is the direct cause. Python stores that exception in __cause__, sets context suppression, and presents the cause before the new exception. The traceback says that the new exception was the direct result of the earlier one. This makes error translation clear across abstraction layers.

Use raise NewError from None when the automatic context is not useful to the person reading the traceback. Python sets __cause__ to None and __suppress_context__ to true. The original exception can still remain in __context__, but the standard traceback does not display it.

Chaining adds little work beyond exception creation and traceback handling. It can keep references to earlier exceptions, traceback frames, and local values while the exception chain remains reachable. Production code should preserve useful causes, avoid retaining exception objects unnecessarily, and suppress context only when the hidden details do not help debugging.

A common mistake is raising a replacement exception without from when the original exception is the known direct cause. The automatic context may still exist, but the intended causal relationship is less precise. Another mistake is believing that from None deletes the original exception. It only suppresses implicit context in the standard traceback. Developers may also suppress useful context only to shorten logs, catch Exception too broadly before translating it, or log only the final error message instead of the complete traceback. Another mistake is using chaining when a bare raise is better. A bare raise should be used when the same exception should continue with its existing traceback.

Explain the three cases in order. Start with automatic __context__, then explicit __cause__ through raise from, and finally suppression through from None. State that explicit chaining is useful when translating an error while preserving its real cause. Also mention that from None hides traceback context but does not erase __context__.

Python considers an object hashable when hash(obj) can call its type’s __hash__ method and receive an integer. The hash must stay stable while the object is in use, and objects that compare equal must have the same hash. Hashable objects can be dictionary keys and set members. When a class defines __eq__ but does not define a matching __hash__, Python normally sets __hash__ to None, so its instances become unhashable.

Python determines hashability by checking the __hash__ behavior provided by the object’s type. When code calls hash(obj), Python calls that hash implementation. If the type sets __hash__ to None, or the operation raises TypeError because hashing is unsupported, the object is unhashable. A valid __hash__ method must return an integer.

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?

Hashing and equality must follow one important rule. If a == b is true, hash(a) and hash(b) must be equal. Dictionaries and sets use the hash to choose where to search, then use equality to confirm a match. Breaking this rule can cause incorrect lookups.

Immutable built in values such as integers and strings are hashable. A tuple is hashable only when every contained value is hashable. Lists, dictionaries, and sets are unhashable because their contents can change.

Custom class instances use identity based equality and hashing by default. If a class overrides __eq__ without defining __hash__, Python normally sets __hash__ to None. This prevents an equality definition from silently conflicting with the inherited identity hash. A custom hash should use only stable values that also take part in equality.

A common mistake is assuming that immutability alone automatically makes an object hashable. Hashability depends on the type’s __hash__ behavior. Another mistake is assuming that every tuple is hashable. A tuple containing a list is unhashable. Developers may also override __eq__ and forget that Python normally disables __hash__. A more serious mistake is calculating the hash from mutable fields. If those fields change after insertion into a dictionary or set, lookup and removal may fail. Equal objects must never return different hashes. Unequal objects may return the same hash, but too many collisions can reduce performance.

Begin with the direct rule: hash(obj) must succeed, the hash must stay stable, and equal objects must have equal hashes. Then explain why dictionaries and sets need that rule. Finish by mentioning that overriding __eq__ without a matching __hash__ normally makes instances unhashable.

Asyncio uses an event loop and cooperative scheduling. Calling an async function creates a coroutine object, but does not run it. Awaiting that coroutine runs it as part of the current task. Creating a task schedules it to run independently when the event loop gets control. Each task runs until it reaches an await that must wait. It then suspends so the event loop can run other ready work. Because the loop does not interrupt normal Python code, one blocking call or long calculation can delay every task on that loop.

Asyncio schedules coroutine work through an event loop. Calling an async function creates a coroutine object. The object holds the future execution state, but does not start by 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?

Awaiting a coroutine runs it as part of the current task. Creating a task registers the coroutine with the event loop so it can make progress independently. The loop selects ready tasks and lets each task run until it finishes, raises an exception, or reaches an await that cannot complete yet.

At that suspension point, the task saves its state and gives control back to the loop. When the awaited operation becomes ready, the loop schedules the task to continue. An await may not suspend when its result is already available.

This is cooperative scheduling. Asyncio provides concurrency, but does not make ordinary Python code run in parallel on one event loop. Blocking input and output, time.sleep, or long calculation can stall every task because the loop cannot run other work until control returns.

Each coroutine and task also uses memory for frames, local values, state, and results. Task switching has overhead, but it is usually small compared with the waiting time saved in input and output heavy programs.

Common mistakes include believing that calling an async function starts it, creating coroutine objects without awaiting or scheduling them, and assuming that every await always gives control to another task. Another mistake is treating concurrency as parallel execution. Developers may also call time.sleep, use a blocking library, or perform long calculation directly on the event loop. This prevents other tasks from running. It is also incorrect to assume that cancel stops a task immediately. Cancellation is a request and cleanup may still need to run. Fire and forget tasks should be stored and their exceptions should be observed.

Explain the runtime flow in this order: coroutine object, current task or new task, event loop, await, suspension, and resumption. Then state the main limitation clearly. Asyncio is cooperative, so code must return control to the event loop and must not perform blocking work there.

Metaclasses control the process that creates class objects. Most Python classes are instances of type, but a class can use a custom metaclass. Python selects a metaclass that is compatible with all base classes. It calls __prepare__ to create the namespace for the class body, __new__ to create the class object, and __init__ to finish initializing that object. I would use a metaclass for rules that must apply during class creation, but I would prefer a class decorator or __init_subclass__ when either gives a simpler solution.

Use a metaclass when you must control how Python creates classes, not how those classes create instances. A class is an object, and the object that creates it is its metaclass. Most classes use type.

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?

When Python reaches a class statement, it determines the metaclass. An explicit metaclass argument is considered first. Python then checks the metaclasses of all base classes and selects the most specific compatible choice. If no compatible metaclass exists, Python raises TypeError.

Python calls __prepare__ to obtain the namespace in which the class body will run. After the body finishes, __new__ receives the class name, bases, namespace, and class options. It validates or changes that data and creates the class object. The metaclass __init__ then performs final initialization.

A metaclass can validate required attributes, register created classes, or change class definitions. Its work happens once each time a class statement executes. The time cost depends on the work performed. A registry also uses memory because it keeps references to registered classes. Metaclasses can cause inheritance conflicts and make code difficult to follow, so simpler tools should be preferred when possible.

This example uses a metaclass to validate and register model classes. __prepare__ returns the namespace used while the class body executes and adds a shared created_by attribute. __new__ checks that every concrete model defines a nonempty table_name before it creates the class object. It also passes the complete namespace to type.__new__, which is important because Python may place internal values such as __classcell__ in that namespace. __init__ runs after the class object exists and stores the concrete model in a registry. The validation and registration happen once when each class statement executes. The registry keeps a strong reference to each registered class, so it also has a small memory cost for every entry.

A common mistake is saying that a metaclass creates normal instances. A metaclass creates a class object, while that class normally creates its instances. Another mistake is confusing metaclass __new__ with the __new__ method used during instance creation. Developers may also forget that the selected metaclass must be compatible with the metaclasses of every base class. This can cause a metaclass conflict during multiple inheritance. Other mistakes include returning an unsuitable object from __prepare__, failing to return the created class from __new__, discarding values from the original namespace, performing expensive input or network work during class creation, and keeping unnecessary class references in a permanent registry. The main design mistake is using a metaclass when a decorator, __init_subclass__, or normal inheritance would be easier to understand.

Explain the sequence in order. Start by saying that classes are objects and most are instances of type. Then explain metaclass selection, __prepare__, execution of the class body, __new__, and __init__. Finish with one practical use, one inheritance risk, and one simpler alternative.

__new__ creates and returns an object, while __init__ initializes an object that has already been created. Python calls __new__ first. It then calls initialization only when the returned object is an instance of the requested class or one of its subclasses. I normally use __init__ for regular setup and override __new__ only when creation itself must be controlled, such as for an immutable subclass or a singleton like design.

__new__ handles object creation. It receives the class as its first argument and must return an object. In a normal custom class, it usually calls super().__new__(cls) and returns the new instance.

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 then performs initialization when the returned object is an instance of the requested class or one of its subclasses. __init__ receives that existing object. It can validate input, assign attributes, and prepare state. It must return None. Returning another value raises TypeError.

The order is therefore creation first and initialization second. If __new__ returns an unrelated object, Python skips initialization for the requested construction call.

Most classes should only define __init__. Immutable subclasses may define __new__ because values such as an int, str, or tuple value must be chosen while the object is being created. A singleton like design may also define __new__ to return a cached instance. However, __init__ can still run after each successful class call, so repeated initialization must be safe or guarded.

Overriding __new__ has no fixed performance or memory cost by itself. The cost depends on extra allocation, caching, locking, validation, or lookup logic added by the implementation.

A common mistake is saying that __init__ creates the object. The object already exists when __init__ starts. Another mistake is forgetting that __new__ must return an object. If it returns None or an unrelated object, normal initialization does not occur. Developers may also return a value from __init__, but Python requires an implicit or explicit None return. In singleton like designs, it is incorrect to assume that __init__ runs only once. It can run after every class call that returns a valid instance. Another mistake is overriding __new__ for normal attribute assignment when __init__ is simpler and clearer.

Begin with the direct rule: __new__ creates and returns the object, while __init__ prepares the returned object. Then explain the call order, the return requirements, and the case where initialization is skipped. Finish with one practical example involving an immutable subclass.

Use an async iterator when getting the next value may require waiting. It implements __aiter__ and __anext__. Async for calls __aiter__, awaits each __anext__ result, and stops when __anext__ raises StopAsyncIteration. Use an async context manager when resource setup or cleanup may require waiting. It implements __aenter__ and __aexit__, and async with awaits both methods. These protocols are common for network streams, database sessions, locks, and other input or output resources.

Use an async iterator for values that become available over time. The __aiter__ method must return an async iterator directly. Its __anext__ method returns an awaitable that produces one value. When no value remains, it raises StopAsyncIteration. Async for performs these calls and awaits automatically. Any other exception leaves the loop and continues through normal exception handling.

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?

Use an async context manager when entering or leaving a resource may require waiting. Async with awaits __aenter__, runs the block, and then awaits __aexit__. The __aexit__ method receives information about any exception. A truthy return value suppresses that exception. A false value lets it continue. If __aenter__ fails, the block is never entered and __aexit__ is not called.

Each iteration adds an awaited method call, so it has more overhead than a normal loop. It is useful when waiting time is much larger than that overhead. It does not speed up CPU heavy work. Async iteration can process one value at a time, so it can avoid storing the full result in memory. Cancellation still requires care because cleanup code can also be interrupted while it awaits.

The example uses AsyncNumbers as a single use async iterator. Its __aiter__ method returns the same iterator object. Its __anext__ method waits briefly, returns the next number, and raises StopAsyncIteration after three values. AsyncResource is an async context manager. Its __aenter__ method waits and opens the resource. Its __aexit__ method waits and closes the resource, then returns false so exceptions are not hidden. Main enters the resource with async with and consumes the values with async for. The output is Resource opened, the numbers 1, 2, and 3, Resource closed, and Finished.

A common mistake is defining __aiter__ with async def in modern Python. That returns a coroutine instead of returning the async iterator directly. Another mistake is returning a plain value from __anext__ instead of returning an awaitable, or raising StopIteration instead of StopAsyncIteration. Developers may also use for instead of async for, or with instead of async with. Returning true from __aexit__ by accident can hide an important exception. Breaking out of async for does not automatically call a custom cleanup method on every async iterator. Resource cleanup should therefore use an explicit async context manager when cleanup is required. Cancellation and failures inside cleanup must also be considered.

Explain the two protocols separately. First say that async for gets the iterator from __aiter__, awaits __anext__, and stops on StopAsyncIteration. Then say that async with awaits __aenter__ and __aexit__ for resource setup and cleanup. Mention that these tools help with waiting operations, not CPU heavy work. Finish with a database or network example and one cancellation warning.

Using __slots__ declares the instance attributes a class expects and can remove the normal instance __dict__. This can reduce memory when an application creates many small objects. It also prevents normal assignment to undeclared attributes when no parent or subclass provides __dict__. Slots do not make an object immutable, and inheritance, weak references, and dataclasses need careful handling.

Use __slots__ when a class creates many instances with a small and stable set of attributes. A normal Python instance usually stores its attributes in an instance __dict__. That dictionary allows new attribute names to be added at runtime. A class that declares __slots__ gets descriptors for the declared names and may avoid the instance dictionary.

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 neither the class nor its parent classes provide __dict__, assigning an undeclared attribute raises AttributeError. Slots do not make existing attributes read only. Their values can still change unless other code prevents it.

The memory benefit matters most when many instances exist. The exact saving depends on the Python implementation, inheritance structure, and declared slots. Attribute access may also be slightly faster, but this is not guaranteed and should be measured.

Weak references require a __weakref__ slot unless a parent already provides weak reference support. A subclass without __slots__ normally gains __dict__ and restores dynamic attributes. A parent with __dict__ also keeps dictionary storage available.

For dataclasses, slots=True creates generated slots. Add weakref_slot=True when weak references are required. Use slots only when reduced flexibility and compatibility limits are acceptable.

The example compares a normal class with a slotted class. The normal instance accepts a new label attribute because it has __dict__. The slotted instance accepts only x and y, so assigning label raises AttributeError. The class includes __weakref__, so weak references work. The subclass does not declare __slots__, so Python gives it __dict__ and dynamic attributes become available again. The dataclass uses slots=True and weakref_slot=True, which creates slotted fields and weak reference support.

A common mistake is saying that __slots__ always removes __dict__. A parent class may already provide a dictionary, a subclass without slots normally adds one, and __dict__ can be declared as a slot. Another mistake is saying that slots make objects immutable. Declared attributes can still be changed. Developers may also forget __weakref__, repeat a parent slot name in a subclass, combine incompatible slotted base classes, assume every tool supports slotted objects, or claim memory and speed improvements without measuring the real application.

Start with the practical rule that slots declare expected attributes and can remove the instance dictionary. Then explain the memory benefit, the undeclared attribute error, and the main exceptions involving inheritance, weak references, and dataclasses. Make it clear that slots are an optional optimization, not a default rule.

Use an abstract base class when related implementations need an explicit runtime contract. ABCMeta provides the machinery, while inheriting from ABC is the usual simpler syntax. A method marked with abstractmethod must be implemented before a normal subclass can be instantiated. register makes an unrelated class a virtual subclass, so isinstance and issubclass recognize it, but registration does not add methods, change its method resolution order, or verify that it follows the interface.

Use an abstract base class when several related classes must follow an explicit runtime contract. ABCMeta is the metaclass that tracks abstract methods and controls subclass and instance checks. Inheriting from ABC is the common shortcut because ABC already uses ABCMeta. A method marked with abstractmethod remains required until a normal subclass overrides it with a nonabstract attribute. Python allows the subclass definition, but creating an instance raises TypeError while any abstract method remains. Python checks abstract status, not the method signature, so a wrong signature can still satisfy the runtime rule.

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 register method makes an unrelated class, and its descendants, virtual subclasses. After registration, issubclass and isinstance return true. The abstract base class is not added to their method resolution order. Its methods are not inherited, and abstract method enforcement does not apply to them.

This is stricter than informal duck typing, which simply calls the needed behavior. A static Protocol lets type checkers accept matching structure without required inheritance. Use abstract base classes for framework extension points and shared runtime rules. Registration adds small runtime bookkeeping and cached checks, but it does not copy objects or allocate per instance data.

MessageSender is an abstract base class because it inherits from ABC. Its send method is marked with abstractmethod. EmailSender implements send, so it is concrete and can be instantiated. IncompleteSender leaves send abstract, so Python raises TypeError when code tries to create an instance. LegacySender does not inherit from MessageSender. Calling register makes it a virtual subclass, so isinstance and issubclass return true. Registration does not add MessageSender to the method resolution order and does not validate or copy the send method. The example works because LegacySender already provides the expected behavior.

A common mistake is thinking register adds inheritance. It does not place the abstract base class in the registered class method resolution order, and methods from the abstract base class are not available through super. Another mistake is assuming registration validates required methods or signatures. It performs neither check. A normal subclass can also satisfy the runtime abstract rule with a method that has an incompatible signature, so type checking and tests are still important. Developers may also overuse isinstance instead of calling the required behavior directly. Finally, abstract methods may contain reusable code, but a concrete subclass must still override them before instantiation.

Start with the decision: use an abstract base class for an explicit runtime contract. Then explain ABCMeta, abstractmethod enforcement at instantiation, and register. State clearly that a virtual subclass passes isinstance and issubclass checks but gains no methods. Finish by comparing runtime enforcement with informal duck typing and static Protocol checks.

I use Big O to compare how the work or extra memory grows as input size n grows. It is about growth, not exact seconds. For example, list index access is O(1), binary search is O(log n), one full scan is O(n), sorting is generally O(n log n), and two nested loops are O(n²). Python dictionaries and sets give average O(1) lookup or membership checks, while heap push and pop are O(log n). I use the input constraints to choose the simplest approach that scales well.

The question asks how we decide whether one Python solution will scale better than another as the amount of data becomes larger. Big O gives a simple way to describe that growth. It can describe running time or extra memory. It does not predict exact seconds because real speed also depends on the machine, Python version, implementation, and constant factors. The main goal is to compare growth rates, understand common Python operation costs, and use the input limits to choose a solution that will still work when n becomes large.

1. How large can n become?
2. Should I discuss running time, extra space, or both?
3. Is average-case behavior for Python dictionaries and sets acceptable for this comparison?

Let n mean the input size. Big O tells us how the amount of work or extra memory changes when n grows. It focuses on the growth pattern. It does not give an exact number of milliseconds.

O(1) is constant growth. The amount of work stays about the same as n grows. The diagram shows list index access, dictionary key access on average, and set insertion on average.

O(log n) grows very slowly. Binary search on a sorted list is the example. Each step removes a large part of the remaining search range.

O(n) is linear growth. If n doubles, the amount of work is roughly doubled. A loop that visits each item once is the main example.

O(n log n) grows faster than O(n) but much slower than O(n²). General-purpose comparison sorting is the main example in the diagram. Python's sorted() and list.sort() have O(n log n) worst-case time.

O(n²) is quadratic growth. Two nested loops that each run n times perform about n × n operations. This can become expensive quickly when n is large.

A list gives O(1) index access, but searching for a value is O(n). A dictionary gives average O(1) get and set by key. A set gives average O(1) add and membership checks. Python's heapq is a min-heap. heappush() and heappop() are O(log n), so a heap is useful for repeated priority operations such as top-k work.

One technical correction is important: heapq.heapify(arr) builds a heap in O(n) time. It is not O(n log n). The diagram places heapify near the O(n log n) examples, but the individual heap push and pop operations shown elsewhere are correctly O(log n).

For a small n, an O(n²) solution may be acceptable. As n becomes larger, lower growth rates become more important. For many repeated lookups or membership tests, a dictionary or set is often a better fit than repeatedly scanning a list. For repeated smallest-item or priority operations, a heap can be useful. For ordering data, sorting usually costs O(n log n).

Two programs can have the same Big O but still run at different speeds because they do different constant amounts of work. An O(n) program can even be slower than an O(n log n) program for a small input. Big O becomes most useful when we care about how behavior changes as n becomes large.

First check the input limits. Then identify the operations the solution performs most often. Choose the simplest algorithm and Python data structure whose growth rate fits those limits. Measure real performance when needed, but use Big O to reason about whether the solution will scale.

This is a complexity-comparison question rather than one problem with a single algorithm. The key insight is to classify each possible operation or solution by how its running time or extra memory grows with n. The main invariant is conceptual: for the same growing input, the lower-order growth rate usually becomes more scalable as n gets large. Then match the work you need to a suitable Python structure. Use list indexing for direct access, dictionaries or sets for average constant-time hash operations, heaps for repeated logarithmic priority operations, and sorting when ordered data is needed.

There is no single time or space complexity for the whole question because the diagram compares several operations. O(1) means the work stays about the same as n grows. O(log n) grows very slowly. O(n) grows in direct proportion to n. O(n log n) is common for efficient sorting. O(n²) often appears when two loops each run across n items. Extra-space complexity uses the same notation but measures additional memory. Python dictionary and set lookup or insertion are O(1) on average. Heap push and pop are O(log n). heapq.heapify() is O(n). Python sorting is O(n log n) in the worst case.

A common mistake is treating Big O as an exact runtime instead of a growth rate. Another is saying dictionary and set operations are guaranteed O(1); in Python they are O(1) on average. Candidates may also confuse O(1) list index access with O(n) list search. Another mistake is forgetting the O(n log n) sorting cost inside a larger solution. It is also incorrect to call heapq.heapify() O(n log n); heap construction with heapify is O(n), while individual heap push and pop operations are O(log n). Finally, choosing O(n²) without checking how large n can become can lead to a solution that is too slow.

When comparing two solutions, name n first, identify the operation that dominates the work, state its Big O, and then explain whether that growth rate is safe for the given input limits.