Programming Fundamentals and Code Quality Questions

Encompasses core programming skills, data structures, basic algorithms, language fundamentals, and code quality practices. Expect proficiency with arrays, strings, lists, hash maps or dictionaries, sets, common collection operations, basic sorting and searching algorithms, and tradeoffs between data structures. Understand control flow, functions and modular design, classes and object oriented programming concepts including encapsulation, inheritance, and polymorphism, exception handling, file input and output, and common language idioms for mainstream interview languages such as Python, Java, and C plus plus. Emphasizes writing clean, readable, maintainable code: meaningful naming, modular functions, small interfaces, handling edge cases and errors, logging and documentation, simple testing and debugging strategies, and awareness of time and space complexity for common operations. Candidates should be able to implement correct solutions, follow language specific idioms where appropriate, and demonstrate attention to code quality and readability.

MediumTechnical

30 practiced

You receive a flaky test that fails 1% of runs due to nondeterministic ordering of items in a dictionary-based result. How do you diagnose and fix the test and the underlying code to avoid relying on dictionary ordering? Provide code examples or test assertions to make results deterministic.

Sample Answer

Situation: A unit test fails ~1% of runs because it compares a dictionary-based result whose item ordering is nondeterministic.

Diagnosis:- Reproduce by running the test many times (pytest -k test_name -n 100 or a small loop).- Log the serialized outputs to see ordering differences.- Confirm code returns a dict whose ordering isn’t guaranteed to be compared as an ordered structure.

Fixes (both test and code):

1) Make test robust to unordered dicts by comparing content, not order:

python

def test_feature_scores():
    result = compute_feature_scores(...)  # returns dict
    expected = {"age": 0.3, "income": 0.5, "zipcode": 0.2}
    assert result.keys() == expected.keys()
    # compare numeric values with tolerance
    for k in expected:
        assert pytest.approx(expected[k], rel=1e-6) == result[k]

2) If the API should be ordered (deterministic), change the function to return a sorted list:

python

def compute_feature_scores(...):
    scores = {"income": 0.5, "age": 0.3, "zipcode": 0.2}
    # deterministic: return list of tuples sorted by score desc then key
    return sorted(scores.items(), key=lambda kv: (-kv[1], kv[0]))

Then test explicitly:

python

assert compute_feature_scores(...) == [("income", 0.5), ("age", 0.3), ("zipcode", 0.2)]

3) For serialized outputs (JSON/API), ensure deterministic serialization:

python

json.dumps(result, sort_keys=True)  # deterministic key order

Why:- Tests should assert semantics (set equality / value equality) not incidental ordering.- If ordering is part of contract, make the function explicitly return an ordered structure or sort before returning/serializing, removing nondeterminism.

Edge cases:- Floating-point tolerance with pytest.approx- Large dicts: consider stable tie-breakers when sorting (e.g., key name) to avoid non-determinism on equal scores.

This approach quickly removes flakiness and clarifies API contract for consumers.

MediumTechnical

26 practiced

Implement a function in Python to find the longest substring without repeating characters. State complexity and explain how your sliding window or two-pointer approach works. Discuss how your approach performs on very long strings and memory tradeoffs when storing indices.

Sample Answer

Use a sliding-window (two-pointer) approach tracking the last index of each character to maintain a window [left, right) with unique characters. Expand right each step; if a duplicate is seen inside the current window, move left to last_index + 1. This is O(n) time and O(min(n, alphabet)) space.

python

def longest_unique_substring(s: str) -> str:
    """
    Returns the longest substring without repeating characters.
    """
    last = {}           # maps char -> last index seen
    left = 0
    best_start = 0
    best_len = 0

    for right, ch in enumerate(s):
        if ch in last and last[ch] >= left:
            # duplicate inside window: move left just past previous occurrence
            left = last[ch] + 1
        last[ch] = right
        cur_len = right - left + 1
        if cur_len > best_len:
            best_len = cur_len
            best_start = left

    return s[best_start:best_start + best_len]

Key points:- Time complexity O(n): each index visited once; left only moves forward.- Space complexity O(k) where k is character set size (<= n). For ASCII k ≤ 128; for Unicode it can grow.- Edge cases: empty string -> "", all-identical chars -> single char, full-unique -> whole string.- For very long strings: algorithm scales linearly; main cost is the map of seen indices. If memory is constrained and alphabet is large (e.g., full Unicode), consider using character hashing with eviction (LRU-like) or compressing characters to integers; or trade time for space by scanning chunks if approximate results acceptable.- Storing indices enables O(1) jumps of left pointer; without indices you'd need O(window_size) checks, increasing time.

MediumTechnical

31 practiced

You are given a poorly documented Python function that processes numeric arrays and sometimes returns NaN silently for certain inputs. Describe a systematic debugging strategy to isolate the input patterns that cause NaN, including writing tests, adding assertions, and instrumentation you would add before making changes to the algorithm.

Sample Answer

Start by reproducing the failure deterministically and collecting evidence before changing logic.

1) Reproduce & isolate- Run function on known failing input(s). If failure is non-deterministic, fix RNG seeds and sample sources.- Record environment: numpy/pandas versions, dtype, shape, device (if using GPU).

2) Quick instrumentation- Turn on numpy floating-error trapping to surface invalid ops:

python

import numpy as np
np.seterr(all='raise')  # will raise FloatingPointError on divide-by-zero/invalid

- Add lightweight assertions at function entry to capture input properties:

python

assert not np.any(np.isnan(arr)), "input has NaNs"
assert np.isfinite(arr).all(), "input has infinities"
assert arr.dtype.kind in ('f','i'), f"unexpected dtype {arr.dtype}"

3) Add internal invariants/logging- Instrument intermediate variables with guarded checks and context-rich logs:

python

val = compute_step(...)
if np.isnan(val).any():
    import logging
    logging.error("NaN at step X; indices=%s, inputs=%s", np.where(np.isnan(val)), snapshot)
    raise ValueError("NaN encountered")

- Capture small “snapshots” (slices, summaries) not whole huge arrays to avoid IO overload.

4) Write tests- Unit tests for nominal and corner cases (zeros, negatives, extreme magnitudes, empty arrays, singletons, integer vs float).- Add parametric tests (pytest.mark.parametrize) and edge-case matrices.- Use property-based testing (Hypothesis) to fuzz input shapes/dtypes and shrink failing cases:

python

from hypothesis import given, strategies as st
@given(st.lists(st.floats(allow_nan=False, allow_infinity=False), min_size=1, max_size=100))
def test_no_nan(lst):
    arr = np.array(lst, dtype=float)
    out = myfunc(arr)
    assert not np.any(np.isnan(out))

5) Root-cause checks to add- Check for divisions by zero, log of non-positive, sqrt of negatives, invalid indexing, dtype overflow/underflow (cast ints to float when needed).- Inspect gradients/nan-propagation if using tensors.

6) Automated triage & shrinking- When a failing test appears, log minimal failing input; run a bisection/shrinking strategy (Hypothesis does this) to find smallest reproducible input.

7) Before changing algorithm- Add regression tests that assert the NaN scenario is handled (either by raising informative error or returning defined behavior).- Keep instrumentation and tests in CI to prevent regressions.

Why this approach: it preserves reproducibility, surfaces the exact failing operation, creates tests to prevent regressions, and gives targeted evidence so algorithm fixes are minimal and safe.

MediumBehavioral

28 practiced

You find a function in a teammate's data cleaning script that swallows exceptions and returns None on any error. Describe your approach to code review feedback to improve error handling and ensure issues are visible in production, while being respectful and actionable.

Sample Answer

Situation: During a review of a teammate's data-cleaning script, I noticed a function that wrapped everything in a broad try/except and returned None on any error. That hides failures and can silently corrupt downstream analyses.

Task: My goal was to give feedback that fixes the error-handling issue, makes failures visible in production, and preserves team trust.

Action:- I left a constructive PR comment describing the risk (silent data loss, hard-to-debug pipeline failures) and suggested concrete changes rather than only criticizing.- Recommended replacing the blanket except with targeted exception handling (e.g., ValueError, KeyError, IOError) so known, recoverable errors can be handled explicitly.- Suggested logging the exception with context (function inputs, source file/row id) and either re-raising or returning a well-defined sentinel that downstream code checks.- Provided a short example and a unit test to illustrate the expected behavior.- Offered to pair-program to implement the change and update pipeline monitoring/alerts so failed records surface in logs/metrics.

Example snippet I included:

python

def parse_row(row):
    try:
        return int(row["id"])
    except (KeyError, ValueError) as e:
        logger.exception("Failed to parse row", extra={"row": row})
        raise  # or return {"error": "parse_failed", "row": row}

Result: The teammate accepted the change; we merged targeted exception handling, added tests, and the pipeline now emits clear errors to monitoring. This reduced silent failures and made debugging much faster. I learned that pairing concrete code examples with empathy and offers to help makes feedback more actionable and well-received.

HardTechnical

29 practiced

Explain race conditions, deadlocks and livelocks with concrete examples in multithreaded code. Then describe a strategy to detect and eliminate a subtle race in a feature cache update during concurrent model serving, including tests you would write.

Sample Answer

Race condition, deadlock and livelock are different concurrency failures. Brief definitions first, then concrete Python examples, then a strategy for a subtle feature-cache race and tests.

Race condition- Definition: two or more threads access shared state where at least one writes, and the final result depends on interleaving.- Example: incrementing a counter without synchronization.

python

# python
import threading

counter = 0
def inc():
    global counter
    for _ in range(10000):
        # read-modify-write is not atomic -> race
        counter += 1

threads = [threading.Thread(target=inc) for _ in range(4)]
for t in threads: t.start()
for t in threads: t.join()
print(counter)  # often < 40000 due to lost updates

Deadlock- Definition: two or more threads wait forever for locks held by each other.- Example: thread A holds lock1 and waits for lock2 while thread B holds lock2 and waits for lock1.

python

# python
import threading, time
a_lock = threading.Lock()
b_lock = threading.Lock()

def t1():
    with a_lock:
        time.sleep(0.1)
        with b_lock:
            pass

def t2():
    with b_lock:
        time.sleep(0.1)
        with a_lock:
            pass

# t1 and t2 can deadlock waiting on each other's lock

Livelock- Definition: threads actively change state to avoid blocking but never make progress (often by repeatedly retrying).- Example: two threads politely yielding to each other by releasing locks and retrying, causing infinite retries.

python

# python pseudo-example for livelock idea
# Two threads repeatedly back off on collision, never progressing

Strategy to detect and eliminate a subtle race in feature cache update during concurrent model servingProblem: multiple requests may trigger cache refreshes concurrently; a naive pattern: if key not in cache -> compute and store can cause duplicate expensive computations or inconsistent partial writes.

Detection- Reproducible stress tests that run many concurrent requests for same key and assert only one computation occurred (use counters/mocks).- Deterministic concurrency tests using thread synchronization (barriers) to align threads to the window of race.- Instrumentation/metrics in production: counts of duplicate recomputations, cache-miss storms, latency spikes.- Static review for non-atomic read-check-write sequences.

Elimination approaches (practical, ranked)1. Per-key locking (mutex map) - Acquire a lock for the specific feature key; only one thread computes and stores.2. Optimistic update with version/CAS - Compute value off-line, use atomic compare-and-swap to set if still absent/older. - Works well with Redis using SETNX or WATCH/MULTI.3. Futures/promises in cache - Store a Future or promise placeholder on first request; other threads await it, no duplicate compute.4. Idempotent and side-effect free computations - Ensure recomputation is safe; combine with backoff to prevent thundering herd.

Concrete implementation sketch (per-key lock + placeholder Future):

python

# python
from concurrent.futures import Future, ThreadPoolExecutor
from threading import Lock

cache = {}
locks = {}
global_lock = Lock()  # protects locks dict

def get_feature(key, compute_fn):
    # fast path
    val = cache.get(key)
    if val is not None: return val

    # ensure a per-key placeholder exists
    with global_lock:
        fut = cache.get(key)
        if fut is None:
            fut = Future()
            cache[key] = fut
            locks[key] = True  # marker optional

    # only the creator computes
    if not fut.done():
        try:
            result = compute_fn(key)
            fut.set_result(result)
        except Exception as e:
            fut.set_exception(e)
            # cleanup on failure so next request can retry
            with global_lock:
                del cache[key]
            raise
    return fut.result()

Tests to write- Unit deterministic race reproduction: - Use threading.Barrier to align N threads hitting get_feature simultaneously; mock compute_fn to increment a counter and sleep; assert counter==1 and all threads receive same result.- Stress test: - High-concurrency test (many threads/processes) repeated runs to detect flaky races; assert no exceptions and only one computation per key.- Failure & retry test: - Make compute_fn raise on first attempt; ensure exception propagated and subsequent calls can recompute successfully (cache cleaned on failure).- Integration test with external cache (Redis): - Use a test Redis instance, test SETNX or Lua CAS approach; simulate process crashes between placeholder set and write to ensure placeholder cleanup / TTL correctness.- Property/chaos test: - Random delays, restart worker threads mid-computation to ensure no permanent staleness; assert eventual consistency and bounded recomputations.

Why this works- Per-key placeholder/future serializes computation for that key without global locking; CAS or SETNX ensures atomic write across processes; tests with barriers make the subtle timing window deterministic; stress & chaos tests validate behavior under real load.

Key trade-offs- Per-key locks add memory for lock map; use weak refs/TTL to cleanup.- Futures work in-process; for multi-process/cluster use Redis primitives or distributed locks with care to avoid deadlocks/poisoning (use TTLs).- Prefer idempotent compute and metrics to detect regressions.

This combination of design + deterministic and stress testing catches subtle races and prevents duplicate expensive recomputations while keeping latency predictable.

Unlock Full Question Bank

Get access to hundreds of Programming Fundamentals and Code Quality interview questions and detailed answers.

Join thousands of developers preparing for their dream job.