Python Coding Interview Foundations Course

Python interviews reward precise mental models of how variables and values actually work. A name is a reference to an object, so a = [] and b = a make b point to the same list rather than copying it. Use id() and is to inspect object identity, and reserve == for value equality.

Knowing which types are mutable and which are immutable prevents classic aliasing bugs. Lists, dicts, and sets can change in place, while ints, strings, and tuples cannot. Passing a mutable object into a function can surprise you when the caller's data changes, so understand when to copy with copy.copy() or copy.deepcopy().

Interviewers increasingly expect type hints because they show clarity and professionalism. Annotate function parameters and return values, for example def parse(text: str) -> list[int]:, and use Optional, Union, or Any when needed. Clear hints communicate your intent faster than long comments.

Understand how interviewers evaluate code: correctness, efficiency, communication, and edge cases all matter. Explain your approach before typing, then write clean code and test it with concrete examples. Do not memorize solutions; instead show that you can reason from first principles under pressure.

Be ready to work in a shared editor or remote environment where Python may be preconfigured. Practice running python -m pytest, debugging with pdb or breakpoint(), and formatting code with a tool such as ruff or black. Smooth tooling keeps attention on the problem instead of the setup.

A strong fundamentals session sets the tone for the whole interview. State your assumptions, test the behavior of small snippets in your head, and explain why each line exists. This foundation makes every later topic easier to apply.

Mental model drill: understand names, references, and object identity. Use id() and is for identity, == for value, and copy() for independent lists. Test mutability with simple examples.

Lists are the most common sequence because they support fast appends, indexing, slicing, and iteration. Operations like lst.append(x) and lst.pop() run in constant time, while insertion or deletion near the front is O(n). Use a list when order matters and you need indexed access.

Tuples are immutable sequences that work well for fixed records and dictionary keys. A single-element tuple requires a comma, as in (1,), and unpacking lets you write a, b = pair. Prefer tuples when the data should not change.

Sets store unique elements and provide O(1) average membership checks. Use set(), add(), remove(), and operations such as &, |, and - for intersection, union, and difference. They are ideal for deduplication and fast existence queries.

Dictionaries map keys to values with average O(1) lookup, insertion, and deletion. Hashable keys, such as strings or tuples, enable fast access like counts[key], and defaultdict or Counter can simplify counting. Keep key choices deliberate because unhashable lists cannot be used as keys.

Built-in functions often replace manual loops and make solutions easier to read. len(), sorted(), enumerate(), zip(), min(), and max() cover common interview patterns, and sorted(items, key=...) gives flexible ordering. Know what each returns and when it creates a new object.

Interviewers care about time complexity and whether you choose the right structure for the operation. Lookups in lists are O(n), while sets and dicts are O(1) on average; sorting is O(n log n). Name the tradeoff out loud before implementing so the choice looks deliberate.

Choice drill: use lists for ordered sequences, tuples for fixed records and dict keys, sets for uniqueness and membership, and dicts for key-value lookups. Know when each operation is O(1) or O(n).

Function signatures communicate how a caller should use your code. Positional parameters, default values, keyword-only parameters, and *args / **kwargs give flexibility when used intentionally. Avoid mutable default arguments such as def f(items=[]) because they are shared across calls.

*args collects extra positional arguments into a tuple, while **kwargs collects extra keyword arguments into a dict. They are especially useful for wrappers and delegating calls with func(*args, **kwargs). Use them sparingly so signatures stay explicit.

Python resolves names with LEGB: local, enclosing, global, and built-in scopes. Assigning inside a function creates a local variable unless you use nonlocal or global. Closures capture enclosing variables and can retain state without a class.

Decorators wrap functions to add behavior without changing their core logic. A decorator is a callable that takes a function and returns a new function, and @timer is shorthand for func = timer(func). Preserve metadata with functools.wraps in production code.

Comprehensions build lists, dicts, and sets concisely and often faster than equivalent loops. Use [x * 2 for x in nums if x > 0], {k: v for ...}, and {x for x in ...} for readable transforms. Keep them short; nested comprehensions can become harder to read than a named loop.

Generators produce values lazily with yield, so they avoid building a full collection in memory. A generator expression like (x for x in data) pairs well with sum(), any(), or all(). Mentioning lazy evaluation shows awareness of memory and streaming problems.

Signature drill: use positional, default, keyword-only, *args, and **kwargs appropriately. Avoid mutable default arguments, and use comprehensions and generators for clean, memory-efficient code.

Classes bundle state and behavior, and instance attributes are usually assigned in __init__. Use self explicitly so every method knows which object it operates on. Class attributes are shared, while instance attributes are created per object.

Inheritance lets a subclass reuse and extend parent behavior, and super().__init__() calls the parent initializer. Method overriding replaces behavior, while isinstance(obj, Base) checks the class hierarchy. Prefer composition over deep inheritance chains in interviews.

Polymorphism means different objects can share the same interface, so code works across types. Duck typing in Python allows any object with the required method to participate; len() works through __len__, and iteration works through __iter__. Design for the interface rather than exact classes.

Dunder methods customize built-in behavior: __repr__, __str__, __eq__, __lt__, and __hash__ are common interview examples. Implement __eq__ and __hash__ together when objects go into sets or dicts. Keep them consistent so value equality and hashing agree.

Use try, except, else, and finally to handle failures predictably. else runs only when no exception occurred, while finally always runs for cleanup. Catch specific exceptions instead of bare except: to avoid hiding bugs.

Raise exceptions with clear messages using raise ValueError("...") or define custom exceptions by subclassing Exception. Custom types make callers able to catch your domain errors precisely. A short hierarchy such as class PaymentError(Exception) is usually enough.

Class drill: assign instance attributes in __init__, use self explicitly, and know the difference between class and instance attributes. Use inheritance with super().__init__() and catch specific exceptions.

Start every algorithm by estimating time complexity and space complexity. State big-O reasoning such as O(n), O(n log n), or O(n^2) and connect it to the input size. This tells the interviewer you understand the cost before writing code.

Two pointers solve many sorted-array and palindrome problems with O(n) time and O(1) extra space. Move one or both pointers toward each other based on a comparison, as in left += 1 or right -= 1. Recognize when a brute-force loop can be replaced by this pattern.

Hashing with dicts or sets turns repeated lookups from O(n) into O(1), and a sliding window maintains a range of valid elements. Use collections.Counter to track frequencies in a window. Both patterns appear constantly in interview questions.

Sorting provides a strong precondition: sorted input enables binary search, greedy choices, and simpler merging. Recursion is natural for divide-and-conquer and tree problems, but always identify the base case. Convert recursion to an explicit stack only when depth or performance demands it.

Read code aloud while tracing concrete examples, including the tricky lines that change state. Test edge cases such as empty input, one element, duplicates, negatives, and very large values. A small set of hand-run examples builds confidence before the final code.

Use a repeatable solve-explain-refine workflow: restate the problem, propose a brute-force solution, improve it, then explain trade-offs. After code is written, walk through a trace, state complexity, and refine only with clear evidence. This structure keeps you calm and makes your reasoning visible.

Complexity drill: estimate time and space before coding. Practice two pointers, sliding window, hash maps, and recursion. State the tradeoff and test edge cases like empty input and duplicates.