Python Fundamentals and Problem Solving Questions

Comprehensive knowledge of the Python programming language, idiomatic usage, and the ability to implement correct, readable, and testable solutions to coding problems. Core language elements include syntax and semantics, primitive and composite data types such as integers, floats, strings, lists, dictionaries, sets, and tuples, sequence and mapping operations, control flow constructs, functions and closures, and object oriented programming basics including classes, instances, inheritance, and special methods. Additional practical topics include error and exception handling, file input and output operations, comprehensions and generator expressions, generator functions and iteration protocols, context managers, lambda functions, unpacking, and common standard library utilities. Candidates should understand algorithmic time and space complexity for common operations, typical performance characteristics of lists and dictionaries, and common pitfalls such as mutable default arguments and shared mutable state. Interview focused expectations include writing clean correct code without editor assistance, sensible variable naming, implementing basic algorithms and data structure manipulations under time constraints, reasoning about tradeoffs and complexity, and demonstrating testability and code quality.

HardTechnical

59 practiced

You inherit a model training loop class that directly opens files, seeds random globally, and instantiates heavy dependencies inside methods making it hard to unit test. Refactor this design to improve testability: show a before-and-after code sketch where you inject data loaders, rng, and persistence handlers. Explain how dependency injection and small interfaces improve unit testing and CI reliability for model code.

Sample Answer

Before (tight coupling — opens files, sets global seed, instantiates saver inside train):

python

import random
import torch

class Trainer:
    def train(self, data_path, epochs=5):
        random.seed(42)                     # global RNG side-effect
        data = open(data_path).readlines()  # direct file I/O
        model = torch.nn.Linear(10,1)       # heavy dependency in method
        optimizer = torch.optim.SGD(model.parameters(), lr=0.1)
        for e in range(epochs):
            for line in data:
                x, y = parse(line)
                pred = model(x)
                loss = loss_fn(pred, y)
                optimizer.zero_grad()
                loss.backward()
                optimizer.step()
        torch.save(model.state_dict(), "model.pt")  # hard-coded persistence

After (dependency injection + small interfaces):

python

from typing import Protocol, Iterable
import torch

class DataLoader(Protocol):
    def __iter__(self) -> Iterable:
        ...

class RNG(Protocol):
    def seed(self, s: int): ...

class Persistence(Protocol):
    def save(self, obj, dest: str): ...

class Trainer:
    def __init__(self, dataloader: DataLoader, rng: RNG, persister: Persistence, model, optimizer):
        self.dataloader = dataloader
        self.rng = rng
        self.persister = persister
        self.model = model
        self.optimizer = optimizer

    def train(self, epochs=5, save_path="model.pt"):
        self.rng.seed(42)                     # injected, no global side effects
        for e in range(epochs):
            for x, y in self.dataloader:
                pred = self.model(x)
                loss = loss_fn(pred, y)
                self.optimizer.zero_grad()
                loss.backward()
                self.optimizer.step()
        self.persister.save(self.model.state_dict(), save_path)

Why this improves testability and CI reliability:- Isolation: Injected DataLoader, RNG, and Persistence let tests supply deterministic mocks (e.g., small in-memory dataset, fake RNG that records seeds, persister that writes to tmp or captures calls).- No global state: Avoids flaky tests caused by global random seeds or file system races.- Small interfaces (Protocols) minimize surface area to mock; you don't need to initialize heavy frameworks in unit tests.- Faster and deterministic: Unit tests run quickly in CI without GPU/IO, making failures actionable.- Clear boundaries: Easier to write integration tests separately (real DataLoader + real persister) and unit tests for training logic.- Example unit test pattern: pass a dummy dataloader yielding fixed tensors, a stub RNG, and a persister that asserts save called — asserts training loop updates optimizer/model calls without touching disk or global state.

HardTechnical

59 practiced

Explain the Global Interpreter Lock (GIL) in CPython and its implications for multi-threaded data processing. Provide strategies to parallelize CPU-bound computations in Python (multiprocessing, C extensions, numpy vectorization, joblib) and include a small code example showing how to parallelize a CPU-bound NumPy operation safely.

Sample Answer

The Global Interpreter Lock (GIL) is a CPython mechanism that ensures only one native thread executes Python bytecode at a time. It simplifies memory management (reference counting) but prevents true CPU-parallelism for Python-level operations in the same process. For data scientists this means: multi-threading (threading.Thread) often won’t speed up CPU-bound tasks (e.g., pure Python loops, heavy numeric compute using Python-level code). I/O-bound tasks still benefit from threads.

Strategies to parallelize CPU-bound computations in Python- Multiprocessing (multiprocessing, concurrent.futures.ProcessPoolExecutor): spawn multiple processes; each has its own GIL and memory space — good for embarrassingly parallel tasks. Overhead: pickling, IPC, memory copies.- C extensions / Cython: move hot loops to C/C++ (or Cython) and release the GIL around heavy C work. Great when you can rewrite performance-critical code.- NumPy vectorization: use NumPy ufuncs and BLAS-backed operations which run in C and often release the GIL — huge speedups without multiprocessing.- Numba: JIT-compile functions to native code; can also parallelize loops and release GIL.- Joblib / loky: high-level parallel map with robust process management and caching; convenient for scikit-learn style workloads.

Example — safely parallelize a CPU-bound NumPy operation by splitting the array and using ProcessPoolExecutor. Each worker operates on a chunk (NumPy work happens in C; but using processes avoids GIL limits and keeps memory isolated).

python

import numpy as np
from concurrent.futures import ProcessPoolExecutor

def heavy_chunk(x_chunk):
    # example CPU-heavy NumPy operations (performed in C)
    # avoid Python-level loops here
    return np.sqrt(np.exp(x_chunk) * np.log1p(x_chunk**2))

def parallel_apply(arr, n_workers=4):
    # split into roughly equal chunks along first axis
    chunks = np.array_split(arr, n_workers)
    with ProcessPoolExecutor(max_workers=n_workers) as exe:
        results = list(exe.map(heavy_chunk, chunks))
    return np.concatenate(results, axis=0)

if __name__ == "__main__":
    N = 10_000_000
    a = np.random.rand(N).astype(np.float64)
    out = parallel_apply(a, n_workers=4)
    print(out.shape)

Key trade-offs:- Multiprocessing avoids the GIL but costs memory and serialization (use shared memory or memory-mapped arrays if needed).- If heavy work is already in NumPy/BLAS, vectorization may be enough and is simplest.- Use Cython/Numba when vectorization isn’t possible or to reduce per-task overhead.- Joblib offers convenience for model training loops; loky backend uses processes (avoids GIL).

In summary: prefer vectorized NumPy + BLAS first; if not sufficient, use multiprocessing or compile to native code (Cython/Numba/C extensions) to bypass the GIL for CPU-bound workloads.

HardTechnical

57 practiced

Design a small DSL in Python to build composable filters for tabular data. Example API:

python

q = (Q('age') > 30) & (Q('country') == 'US' | Q('country') == 'CA')
print(q.to_sql())  # -> "(age > %s) AND ((country = %s) OR (country = %s))"

Implement a minimal `Q` class supporting __eq__, __gt__, __and__, __or__ and a `to_sql()` method that produces a parameterized WHERE clause and a list of parameters. Discuss SQL injection mitigation and how to extend to IN, NOT, and LIKE.

Sample Answer

Approach: represent each expression as a tree node. Overload comparison and boolean operators to build nodes. to_sql() recursively renders parameterized SQL and collects parameters (no string interpolation) to mitigate SQL injection.

python

from typing import Any, List, Tuple

class Q:
    def __init__(self, field: str = None, op: str = None, value: Any = None, left=None, right=None):
        self.field = field
        self.op = op
        self.value = value
        self.left = left
        self.right = right

    # leaf comparisons
    def __eq__(self, other): return Q(field=self.field, op='=', value=other)
    def __gt__(self, other): return Q(field=self.field, op='>', value=other)
    def like(self, pattern): return Q(field=self.field, op='LIKE', value=pattern)
    def in_(self, seq): return Q(field=self.field, op='IN', value=tuple(seq))

    # boolean composition
    def __and__(self, other): return Q(op='AND', left=self, right=other)
    def __or__(self, other): return Q(op='OR', left=self, right=other)
    def __invert__(self): return Q(op='NOT', left=self)

    def to_sql(self) -> Tuple[str, List[Any]]:
        if self.op in ('=', '>', 'LIKE'):
            return f"({self.field} {self.op} %s)", [self.value]
        if self.op == 'IN':
            placeholders = ', '.join(['%s'] * len(self.value))
            return f"({self.field} IN ({placeholders}))", list(self.value)
        if self.op in ('AND', 'OR'):
            left_sql, left_params = self.left.to_sql()
            right_sql, right_params = self.right.to_sql()
            return f"({left_sql} {self.op} {right_sql})", left_params + right_params
        if self.op == 'NOT':
            inner_sql, inner_params = self.left.to_sql()
            return f"(NOT {inner_sql})", inner_params
        raise ValueError("Invalid Q node")

Key points:- to_sql returns (sql, params); always uses placeholders (%s) and separate params to avoid injection; never format values into SQL strings.- Complexity: building is O(n) nodes; to_sql traverses tree once O(n).- Edge cases: empty IN sequences (should raise), None comparisons (translate to IS/IS NOT NULL), operator precedence (parentheses added).Extensions:- NOT implemented via __invert__. Add __ne__ => use '!=' or translate to NOT (=).- Add parameterized escaping for different DB drivers (psycopg2 uses %s, sqlite uses ? — adapt per dialect).- Add validation of field names (whitelist or identifier quoting) to avoid injection via column names.

HardTechnical

49 practiced

You maintain a function `normalize(data: dict)` that recursively converts numeric-like strings into numbers and normalizes keys (lowercase, underscore). Design unit tests using pytest and write at least two property-based tests using Hypothesis that assert invariants (e.g., normalization idempotence, keys normalized). Provide sample test cases and explain how Hypothesis strategies can generate nested dicts.

Sample Answer

Here are pytest unit tests and Hypothesis property-based tests for normalize(data: dict). Tests cover concrete cases and two invariants: idempotence (normalize(normalize(x)) == normalize(x)) and key-normalization (all keys lowercase + underscore). I also show Hypothesis strategies to generate nested dicts with numeric-like strings.

python

# tests/test_normalize.py
import re
from copy import deepcopy
import pytest
from hypothesis import given, strategies as st
from mymodule import normalize  # function under test

# --- Concrete unit tests ---
def test_simple_numeric_strings():
    data = {"Age": " 42 ", "priceUSD": "3.14", "name": "Alice"}
    out = normalize(data)
    assert out["age"] == 42
    assert out["price_usd"] == 3.14
    assert out["name"] == "Alice"

def test_nested_structures():
    data = {"User Info": {"id": "007", "active": "true", "balance": "0"}}
    out = normalize(data)
    assert out["user_info"]["id"] == 7
    assert out["user_info"]["active"] == "true"  # non-numeric preserved
    assert out["user_info"]["balance"] == 0

# --- Hypothesis strategies for nested dicts ---
# base value: either numeric-like string, non-numeric string, int, float, or None
numeric_like = st.one_of(
    st.text(min_size=1).filter(lambda s: re.fullmatch(r"\s*[+-]?\d+\s*", s) is not None),
    st.text(min_size=1).filter(lambda s: re.fullmatch(r"\s*[+-]?(\d+\.\d*|\.\d+)\s*", s) is not None),
)
base_values = st.one_of(numeric_like, st.integers(), st.floats(allow_nan=False), st.text(), st.none())

# recursive mapping allowing nested dicts and lists
nested = st.recursive(
    base_values,
    lambda children: st.lists(children, max_size=4) | st.dictionaries(st.text(min_size=1), children, max_size=4),
    max_leaves=10
)

# --- Property-based tests ---
@given(nested)
def test_idempotence_prop(data):
    # idempotence: applying normalize twice yields same result as once
    first = normalize(deepcopy(data))
    second = normalize(deepcopy(first))
    assert first == second

@given(nested)
def test_keys_normalized_prop(data):
    # all dict keys at all nesting levels are lowercase and underscore-separated
    res = normalize(deepcopy(data))

    def check_keys(obj):
        if isinstance(obj, dict):
            for k, v in obj.items():
                assert k == k.lower()
                assert " " not in k and "-" not in k  # spaces/hyphens normalized to underscores
                assert re.fullmatch(r"[a-z0-9_]+", k) is not None
                check_keys(v)
        elif isinstance(obj, list):
            for item in obj:
                check_keys(item)
    check_keys(res)

Explanation of strategies:- base_values allows numeric-like strings, native ints/floats, other strings, and None to simulate real data.- st.recursive composes nested dicts and lists to arbitrary depth (bounded by max_leaves), producing realistic deeply nested structures.- Filtering numeric_like via regex ensures we generate strings that should convert to ints/floats, exercising numeric parsing logic.

Notes:- deepcopy used to avoid in-place normalization side effects.- Adjust numeric_like and regexes to match normalize's parsing rules (e.g., thousands separators, locale).- Add examples for edge cases (empty dict, large numbers, negative signs, leading zeros) as additional concrete tests.

MediumTechnical

43 practiced

Implement a Python decorator `@memoize(maxsize)` that caches function results up to maxsize entries. The decorator should accept functions with positional and keyword arguments and evict least-recently-used entries when full. Use only the standard library (collections.OrderedDict is allowed). Discuss hashing of arguments and limitations with unhashable args.

Sample Answer

To implement an LRU memoize decorator with a max size, we build an OrderedDict as an LRU cache and derive a stable hashable key from positional and keyword arguments. For common unhashable inputs (lists, dicts, sets) we recursively convert them to immutable equivalents (tuples, frozensets). This works for most use cases but cannot handle arbitrary objects (e.g., numpy arrays, custom unhashable classes) reliably — those should be converted by the caller (e.g., to bytes or a tuple) or the decorator can fall back to no-cache for unhashable arguments.

python

from collections import OrderedDict
from functools import wraps
from typing import Any

def _deep_freeze(obj: Any):
    """Recursively convert common mutable structures to hashable equivalents."""
    if isinstance(obj, dict):
        return tuple(sorted((k, _deep_freeze(v)) for k, v in obj.items()))
    if isinstance(obj, (list, tuple)):
        return tuple(_deep_freeze(x) for x in obj)
    if isinstance(obj, set):
        return frozenset(_deep_freeze(x) for x in obj)
    # For numpy arrays or other types, caller should pre-convert; we attempt to use as-is
    return obj

def memoize(maxsize: int = 128):
    if maxsize <= 0:
        raise ValueError("maxsize must be positive")

    def decorator(func):
        cache = OrderedDict()

        @wraps(func)
        def wrapper(*args, **kwargs):
            try:
                key = (_deep_freeze(args), _deep_freeze(kwargs))
            except TypeError:
                # Unhashable even after freezing: skip caching
                return func(*args, **kwargs)

            if key in cache:
                # Move to end => most recently used
                cache.move_to_end(key)
                return cache[key]

            result = func(*args, **kwargs)
            cache[key] = result
            cache.move_to_end(key)
            if len(cache) > maxsize:
                # pop least-recently-used item
                cache.popitem(last=False)
            return result

        # expose cache for introspection (optional)
        wrapper._cache = cache
        return wrapper
    return decorator

Key points:- Uses OrderedDict for O(1) amortized get/insert and easy LRU eviction.- _deep_freeze converts lists/dicts/sets to hashable forms so typical mutable containers can be cached.- Limitations: arbitrary unhashable objects (e.g., numpy.ndarray, custom objects) may not be safely frozen; caching such args may raise or produce incorrect behavior if objects mutate. In those cases either preprocess inputs (e.g., .tobytes() for arrays) or skip caching.Time complexity: O(1) average per lookup/insert; space: O(maxsize). Consider thread-safety (add locks) if used in multi-threaded contexts.

Unlock Full Question Bank

Get access to hundreds of Python Fundamentals and Problem Solving interview questions and detailed answers.

Join thousands of developers preparing for their dream job.