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.

MediumTechnical

55 practiced

Describe the most commonly used itertools functions (chain, islice, groupby, accumulate, combinations). Give a concrete example showing how itertools.chain and islice can be used to process many small iterables lazily without extra memory overhead.

Sample Answer

itertools provides memory-efficient building blocks for iterator algebra. Brief descriptions:

- chain: concatenate multiple iterables into one iterator (lazy).- islice: slice an iterator by indices/length without materializing it.- groupby: group consecutive elements by a key function; requires sorted input for full grouping semantics.- accumulate: running totals or reductions (like prefix sums) using an optional binary function.- combinations: generate r-length combinations (orderless) from an input iterable.

Concrete lazy example — suppose you have many small data files or batches and want to process the first N items across them without loading all batches into memory:

python

from itertools import chain, islice

# generator that yields small iterables (e.g., lines from many files)
def batches():
    yield from (range(5))          # batch 1: 0..4
    yield from (x+10 for x in range(3))  # batch 2: 10..12
    yield from (range(20, 25))    # batch 3: 20..24

# If batches() produced many small iterables, chain flattens them lazily.
flattened = chain(batches())  # doesn't build list, yields items one by one

# Take only the first 7 items across all batches
first_seven = islice(flattened, 7)
for item in first_seven:
    print(item)

Why this is good:- Memory: chain + islice never materialize whole collections; items are produced/consumed on demand.- Performance: constant extra memory regardless of number/size of batches.- Use cases in AI: streaming dataset preprocessing, online evaluation, lazy augmentation pipelines.

Notes/edge cases:- groupby groups consecutive equal keys; sort first if global grouping needed.- combinations yields combinatorial outputs — beware explosion.- accumulate supports custom reducers (e.g., running max).

HardTechnical

51 practiced

Explain the Global Interpreter Lock (GIL) in CPython: why it exists, how it affects multi-threaded programs doing CPU-bound work, strategies to work around it (multiprocessing, C extensions releasing GIL, subinterpreters), and practical implications for AI workloads that use heavy C libraries like NumPy and PyTorch.

Sample Answer

The Global Interpreter Lock (GIL) is a mutex in CPython that ensures only one native thread executes Python bytecode at a time. It exists mainly for simplicity and safety: it makes memory management (reference counting), object model invariants, and many C-API operations easier and faster to implement without fine-grained locking inside the interpreter.

Impact on multi-threaded CPU-bound programs:- CPU-bound Python code (pure Python loops, math in Python) cannot run concurrently on multiple cores because the GIL serializes bytecode execution → no linear speedup with threads.- I/O-bound programs still benefit from threads because the GIL is released during blocking I/O waits.

Workarounds and alternatives:- Multiprocessing: spawn processes (multiprocessing, concurrent.futures.ProcessPoolExecutor). Each process has its own interpreter and memory space, so you get real parallelism across cores. Overheads: IPC, serialization (pickle), memory duplication (mitigated by shared memory / mmap).- C extensions that release the GIL: well-written C/C++ extensions (or code in Cython with nogil) can perform heavy CPU work while temporarily releasing the GIL, allowing other Python threads to run. This requires careful handling of Python API calls only while GIL is held.- Subinterpreters / per-interpreter GIL (PEP proposals): experimental — aims to allow multiple independent interpreters in one process with separate GILs, but ecosystem and C-API compatibility remain challenges.

Practical implications for AI workloads:- Most heavy AI libraries (NumPy, SciPy, PyTorch, TensorFlow) implement core ops in C/C++/CUDA and release the GIL (or run outside Python on GPUs). Therefore Python-level threading is often fine for orchestrating work while native code uses all cores/GPUs.- For data preprocessing that’s CPU-bound (Python code manipulating objects), prefer multiprocessing or rewrite hotspots in Cython/Numba or vectorize with NumPy.- For model training on GPU: GIL is rarely the bottleneck because CUDA kernels run asynchronously in native code; focus on data pipeline parallelism, pinned memory, and overlap of CPU/GPU work.- When low-latency multithreaded inference is required, consider: process pools, serving frameworks (TensorRT, TorchServe), or embedding inference in C++ services to avoid Python GIL overhead.

Key takeaways:- GIL prevents Python-level parallel CPU-bound threading but is not a blocker for high-performance AI when heavy lifting is in native libraries or on GPUs.- Use multiprocessing, native code with GIL release, or move bottlenecks out of Python for true parallelism.

HardTechnical

82 practiced

Discuss best practices for serializing and saving large machine learning models and state in Python. Cover pickle pitfalls (security, versioning), joblib and memory-mapped approaches, atomic checkpointing, storing optimizer state, and recommendations for cross-language interoperability (e.g., ONNX or HDF5).

Sample Answer

Start with a clear goal: durable, secure, versioned checkpoints that allow fast reload (possibly partial), cross-language inference, and reproducible experiments.

Pickle pitfalls- Security: never unpickle data from untrusted sources — it can execute arbitrary code.- Versioning: pickle ties to Python class/module paths and library versions; loading after refactor or different package versions often fails.- Use pickle only for trusted, short-term artifacts (e.g., ephemeral experiment artifacts). Prefer safer, versioned formats for long-term storage.

Joblib and memory-mapping- joblib.dump/load is convenient for large numpy arrays and sklearn pipelines; supports compression.- For huge arrays, use memory-mapping to avoid copying into RAM:

python

import joblib
joblib.dump(arr, 'arr.pkl')            # save
arr = joblib.load('arr.pkl', mmap_mode='r')  # memory-mapped readonly

- mmap_mode='r+' allows in-place updates on disk-backed arrays. Good for large embedding tables.

Atomic checkpointing- Always write checkpoints atomically to avoid corrupt files on crash: write to a temp file and atomically rename/replace.

python

import tempfile, os
def atomic_save(path, data_bytes):
    dirn = os.path.dirname(path)
    fd, tmp = tempfile.mkstemp(dir=dirn)
    with os.fdopen(fd, 'wb') as f:
        f.write(data_bytes)
    os.replace(tmp, path)  # atomic on POSIX/Windows

- Keep multiple recent checkpoints (e.g., last N), and a manifest with checksums and metadata (timestamp, training step, git commit, library versions).

Storing optimizer and training state- For full reproducibility, checkpoint model weights, optimizer state (momentum, learning rate schedule), RNG states (python, numpy, framework), and training step.- PyTorch example:

python

torch.save({
  'epoch': epoch,
  'model_state': model.state_dict(),
  'optim_state': optimizer.state_dict(),
  'rng_python': random.getstate(),
  'rng_numpy': np.random.get_state(),
  'rng_cuda': torch.random.get_rng_state_all()
}, tmp_path)
os.replace(tmp_path, final_path)

- Beware that optimizer state can be large (e.g., Adam has two moment tensors per parameter). Consider sharded checkpoints or excluding/resetting optimizer state for cheap fine-tuning.

Sharding and streaming for huge models- Split large tensors into shards (per-layer or per-parameter-file) to parallelize upload/download and reduce memory during load.- Use formats that support streaming reads (HDF5, Zarr, custom shard+manifest).

Cross-language interoperability- ONNX: good for exporting model structure and weights for inference across Python/C++/.NET; not ideal for optimizer or training state. Use for production inference paths.- HDF5: hierarchical, supports named datasets (weights, metadata). Many languages and libs support HDF5; good for large arrays and partial reads.- FlatBuffers/Protobuf: schema-enforced, versionable; good for metadata and small tensors.- Recommend: export model for inference in ONNX (or framework-specific runtime) and keep training checkpoints (optimizer, RNG) in framework-native format. Provide a conversion pipeline and document versions.

Best practices summary- Use atomic saves + manifest/checksums + rotation (keep last N).- Use joblib/HDF5/mmap/Zarr for large arrays to enable partial/memory-mapped loads.- Save optimizer and RNG state for exact resumes; consider sharding to handle size.- Avoid untrusted pickle; prefer standardized, versioned formats for long-term storage and cross-language use (ONNX for inference, HDF5/Zarr for large arrays).- Record environment: framework versions, CUDA, hardware, git commit — embed in metadata for reproducibility.

HardTechnical

55 practiced

Implement a thread-safe cached_property descriptor: the first access computes the value and caches it on the instance, subsequent accesses return the cached value, and deleting the attribute forces recomputation. Ensure the implementation avoids race conditions when used by multiple threads.

Sample Answer

Approach: implement a descriptor that stores the computed value in instance.__dict__ under the property name and uses a per-instance threading.RLock to avoid races. Use double-checked locking in __get__ so only one thread computes the value. __delete__ removes the cached value so next access recomputes.

python

import threading
from functools import wraps

class cached_property:
    def __init__(self, func):
        wraps(func)(self)
        self.func = func
        self.attr_name = func.__name__
        self.lock_name = f"_{self.attr_name}_cache_lock"

    def __get__(self, instance, owner=None):
        if instance is None:
            return self
        # Fast path: already cached
        if self.attr_name in instance.__dict__:
            return instance.__dict__[self.attr_name]
        # Acquire per-instance lock (create lazily)
        lock = instance.__dict__.setdefault(self.lock_name, threading.RLock())
        with lock:
            # Re-check after acquiring lock (double-checked locking)
            if self.attr_name in instance.__dict__:
                return instance.__dict__[self.attr_name]
            value = self.func(instance)
            instance.__dict__[self.attr_name] = value
            return value

    def __set__(self, instance, value):
        # Allow manual override of cached value
        instance.__dict__[self.attr_name] = value

    def __delete__(self, instance):
        instance.__dict__.pop(self.attr_name, None)
        # Optionally keep the lock so future accesses reuse it

Key points:- Double-checked locking prevents duplicate computation.- Per-instance RLock stored in instance.__dict__ avoids global contention and ensures cleanup with the instance.- __delete__ forces recomputation by removing cached value.Complexity: computing the value cost depends on func; descriptor overhead is O(1). Edge cases: if func raises, no value is cached (exception propagates). Alternative: use WeakKeyDictionary for locks if you prefer not to store hidden attributes on instances.

MediumTechnical

46 practiced

Write a generator iterate_gz_lines(paths) that yields non-empty, stripped lines from multiple gzipped files lazily. Each file should be opened only when needed and closed promptly. Use only standard library components and ensure memory usage stays small for very large files.

Sample Answer

Approach: iterate paths lazily, open each gz file only when reached using a context manager, read line-by-line in text mode to keep memory small, strip and skip empty lines, and close each file immediately after finishing.

python

import gzip
from typing import Iterable, Iterator, Union
from pathlib import Path

def iterate_gz_lines(paths: Iterable[Union[str, Path]]) -> Iterator[str]:
    """
    Lazily yield non-empty, stripped lines from multiple gzipped files.
    Each file is opened only when needed and closed promptly.
    """
    for p in paths:
        # allow Path objects or strings
        path = str(p)
        # open in text mode so we get str lines; use utf-8 and replace errors to be robust
        with gzip.open(path, mode='rt', encoding='utf-8', errors='replace') as fh:
            for line in fh:
                s = line.strip()
                if s:
                    yield s

Key points:- Uses gzip.open(mode='rt') to stream text lines, avoiding loading entire file.- The with block ensures file is closed as soon as iteration over that file finishes.- Works with large files since it processes one line at a time.

Time & space:- Time: O(total bytes) to read all lines.- Space: O(max line length) (constant memory relative to file size).

Edge cases:- Nonexistent or corrupt gz files will raise exceptions — caller can catch or you can wrap open in try/except to skip/log.- If different encodings exist, adjust encoding or handle decode errors.- If you need original bytes instead of text, open with mode='rb' and decode per line.

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.