Junior 1–3 years

JR-E-O01 · A saved cart, a snapshot and a rebinding

Easy · Output · Junior (1–3 years) · mutability, aliasing, copying, rebinding · 3 min

Question: What does this print?

cart = ["chai", "samosa"]
saved = cart
snapshot = cart.copy()

cart.append("vada pav")
print(saved)
print(snapshot)

cart = cart + ["lassi"]
print(saved)
print(cart is saved, snapshot is saved)

Expected output:

['chai', 'samosa', 'vada pav']
['chai', 'samosa']
['chai', 'samosa', 'vada pav']
False False

Explanation:

Assignment never copies. saved = cart gives the same list object a second name, while cart.copy() builds a new list holding the same items.

• cart.append("vada pav") mutates the one object that cart and saved both name, so saved shows the new item. snapshot is a separate list and still has two items.
• cart = cart + ["lassi"] is different: + builds a brand-new list, and = rebinds only the name cart to it. saved still names the original list, which never received "lassi".
• After the rebinding, cart and saved are different objects (False), and snapshot was always separate (False).

Takeaway: ask two questions about every line, "does this mutate an object?" and "does this rebind a name?". Only mutation is visible through other names.

Follow-ups:

1. "What changes if the last assignment is cart += ["lassi"] instead?" For lists, += calls extend and mutates in place, then rebinds cart to the same object. So saved would also show 'lassi' and cart is saved would be True. x += y and x = x + y are not the same for mutable types.
2. "Is snapshot completely independent of cart?" Only one level deep. .copy() is shallow: if the items were dicts (say {"item": "chai", "qty": 1}), both lists would hold the same dict objects, and changing a quantity through one would show in the other. copy.deepcopy copies nested objects too.
3. "You pass cart to apply_offer(cart) and don't want it changed. What are your options?" Pass a copy (apply_offer(list(cart))), pass an immutable tuple, or write the function to return a new list instead of mutating its argument. Document whichever you choose.

Scoring: Strong: Exact output; uses the words mutate vs rebind; spots the += difference when asked. Acceptable: Gets lines 1, 2 and 4 right but thinks saved also gets 'lassi'; corrects it once + vs append is pointed out. Red flag: Believes saved = cart makes a copy, or can't say why snapshot differs from saved.

JR-E-O02 · Invoice and refund number generators with closures

Easy · Output · Junior (1–3 years) · closures, scope, nonlocal · 3 min

Question: What does this print?

def make_counter(label):
    count = 0

    def tick():
        nonlocal count
        count += 1
        return f"{label}-{count:03d}"

    return tick

next_invoice = make_counter("INV")
next_refund = make_counter("REF")

print(next_invoice(), next_invoice())
print(next_refund())
print(next_invoice())
print(next_invoice.__closure__[0].cell_contents)

Expected output:

INV-001 INV-002
REF-001
INV-003
3

Explanation:

Each call to make_counter runs the function body again, so it creates a new local count and a new tick function. tick is a closure: it keeps access to the count (and label) of the call that created it, even after make_counter has returned.

• next_invoice and next_refund have separate count variables, so the refund counter starts at 1 regardless of how many invoices were numbered.
• nonlocal count lets tick rebind the enclosing variable. Without it, count += 1 would make count local to tick.
• {count:03d} zero-pads to three digits.
• The last line shows where the state lives: the closure keeps the variable in a cell object, and after three calls the invoice counter's cell holds 3. (__closure__ is only for inspection; you would not use it in real code.)

Takeaway: a closure remembers the variables of the call that created it; each call of the outer function gives fresh state.

Follow-ups:

1. "What happens if you delete the nonlocal count line?" The first call raises UnboundLocalError: cannot access local variable 'count' where it is not associated with a value. Because count is assigned inside tick, Python treats it as local to tick for the whole function, and count += 1 reads it before it has a value.
2. "Would you need nonlocal if count were a list and you did count[0] += 1?" No. That mutates the list object; it doesn't rebind the name count. nonlocal (and global) are only needed to rebind a name from an outer scope.
3. "How else could you write this?" A small class with self.count, or itertools.count(1) wrapped with the label. A class is clearer when you also need reset or a peek method; a closure is fine for a single callable.

Scoring: Strong: Exact output; explains that each make_counter call has its own count, and why nonlocal is needed. Acceptable: Right output but vague on why the counters are independent, or unsure what nonlocal does. Red flag: Expects the counters to share state (REF-003), or says count disappears when make_counter returns.

JR-E-O03 · Fetching API pages with a generator

Easy · Output · Junior (1–3 years) · generators, laziness, next, iteration · 4 min

Question: What does this print?

def fetch_pages(total_pages):
    print("start")
    for page in range(1, total_pages + 1):
        print(f"fetching page {page}")
        yield [f"order-{page}a", f"order-{page}b"]
    print("no more pages")

pages = fetch_pages(3)
print("generator created")

for batch in pages:
    print("got", batch)
    if batch[0] == "order-2a":
        break

print(next(pages))
print(next(pages, "done"))

Expected output:

generator created
start
fetching page 1
got ['order-1a', 'order-1b']
fetching page 2
got ['order-2a', 'order-2b']
fetching page 3
['order-3a', 'order-3b']
no more pages
done

Explanation:

A function that contains yield is a generator function: calling it runs none of its body. It returns a generator object, so generator created is printed before start.

• Each step of the for loop calls next(), which runs the body until the next yield and pauses there. Pages are fetched one at a time, just before they are needed.
• break ends the loop, but the generator is not finished: it stays paused right after yielding page 2.
• next(pages) resumes from that pause: it prints fetching page 3 and returns the third batch.
• The second next resumes again, the for loop inside the generator ends, no more pages is printed, and the function returns. That raises StopIteration internally, and next(pages, "done") turns it into the default value.

Takeaway: a generator does work only when asked for the next item, and it remembers exactly where it paused.

Follow-ups:

1. "What would print(next(pages)) (with no default) do as the last line?" Raise StopIteration. A for loop handles StopIteration for you; a bare next() doesn't. That's why the two-argument form is handy for "first item or a default".
2. "The real version opens an HTTP session at the start. How do you make sure it is closed if the caller breaks out early?" Put the loop inside try/finally (or a with httpx.Client() as client: block) in the generator. When the generator is closed, by pages.close(), by garbage collection, or by contextlib.closing(...) around it, Python raises GeneratorExit at the paused yield and the cleanup runs.
3. "Why use a generator here instead of returning a list of all pages?" Memory and latency: the caller can start processing page 1 while later pages are not fetched yet, and can stop early without fetching the rest. A list fetches everything up front.

Scoring: Strong: Exact order, including generator created before start and that next resumes at page 3. Acceptable: Knows generators are lazy but thinks break ends the generator or that start prints first; fixes it when asked what calling a generator function returns. Red flag: Expects all pages to be fetched when fetch_pages(3) is called, or can't say what yield does.

JR-E-O04 · An audit decorator on a GST helper

Easy · Output · Junior (1–3 years) · decorators, functools.wraps, *args/**kwargs · 4 min

Question: What does this print?

import functools

def audit(func):
    print(f"decorating {func.__name__}")

    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        print(f"-> {func.__name__}{args}")
        result = func(*args, **kwargs)
        print(f"<- {result}")
        return result

    return wrapper

@audit
def apply_gst(amount, rate=0.18):
    return round(amount * (1 + rate), 2)

print("module loaded")
total = apply_gst(500, rate=0.05)
print(total, apply_gst.__name__)

Expected output:

decorating apply_gst
module loaded
-> apply_gst(500,)
<- 525.0
525.0 apply_gst

Explanation:

@audit above def apply_gst means apply_gst = audit(apply_gst), and it runs once, when the def statement executes, which is when the module is loaded. So decorating apply_gst prints before module loaded.

• From then on the name apply_gst refers to wrapper. Calling it prints the arrow line, calls the original function, prints the result, and returns it.
• args holds only the positional arguments, (500,). rate=0.05 was passed by keyword, so it is in kwargs, which this decorator doesn't print.
• round(500 * 1.05, 2) is 525.0 (a float).
• functools.wraps(func) copies __name__, __doc__ and other metadata from the original onto wrapper, so apply_gst.__name__ is still 'apply_gst'.

Takeaway: decorator code runs at definition time; the wrapper code runs at every call.

Follow-ups:

1. "What would the last line print without @functools.wraps(func)?" 525.0 wrapper. Every decorated function would look like wrapper in logs, tracebacks, help() and anything that registers functions by name.
2. "How would you make the prefix configurable, as in @audit(prefix="GST")?" Add one more level: audit(prefix) returns a decorator, which takes func and returns wrapper. @audit(prefix="GST") first calls audit(...), then applies the decorator it returns.
3. "Where have you seen code that runs at decoration time?" Web frameworks: @app.get("/orders") in FastAPI or @app.route in Flask registers the route when the module is imported, not when a request arrives. @pytest.fixture and @dataclass also do their work at definition time.

Scoring: Strong: Gets the order (decorating before module loaded) and explains (500,) and the preserved name. Acceptable: Gets the call lines right but puts decorating after module loaded, or prints (500, 0.05); corrects it with a hint. Red flag: Thinks the decorator body runs on each call, or can't explain what @audit desugars to.

JR-E-O05 · A pipeline step as a context manager

Easy · Output · Junior (1–3 years) · context managers, __enter__/__exit__, exceptions · 4 min

Question: What does this print?

class Step:
    def __init__(self, name):
        self.name = name

    def __enter__(self):
        print(f"enter {self.name}")
        return self.name.upper()

    def __exit__(self, exc_type, exc, tb):
        status = "ok" if exc_type is None else f"failed: {exc_type.__name__}"
        print(f"exit {self.name} ({status})")
        return False

with Step("extract") as label:
    print("inside", label)

try:
    with Step("load") as label:
        print("inside", label)
        raise ValueError("bad row 42")
        print("never printed")
except ValueError as err:
    print("caught:", err)

Expected output:

enter extract
inside EXTRACT
exit extract (ok)
enter load
inside LOAD
exit load (failed: ValueError)
caught: bad row 42

Explanation:

with Step("extract") as label: calls __enter__, and its return value is what as binds, here "EXTRACT", not the Step object. When the block ends, __exit__ runs.

• On a normal exit, __exit__ receives (None, None, None), so it prints ok.
• When the block raises, the rest of the block is skipped (never printed), and __exit__ receives the exception type, value and traceback. It runs before any outer except.
• __exit__ returns False, which means "don't suppress". The ValueError continues out of the with and the outer except catches it.

Takeaway: __exit__ always runs, sees any exception, and decides whether it propagates; as gets whatever __enter__ returns.

Follow-ups:

1. "What changes if __exit__ returns True?" The exception is suppressed: the except never runs and caught: ... is not printed. Execution continues after the with block as if nothing happened. That's why a context manager should return a truthy value only when swallowing the error is deliberate.
2. "Write the same thing with contextlib.contextmanager." A generator: print enter, then try: yield name.upper() / except Exception as e: print failed; raise / else: print ok. The code before yield is __enter__, the code after is __exit__, and the exception is re-raised at the yield line.
3. "Name context managers you use at work." open() (closes the file), httpx.Client() (closes connections), a database connection or transaction (commit or rollback), threading.Lock (release), pytest.raises, unittest.mock.patch.

Scoring: Strong: Exact output; knows as gets __enter__'s return value and that __exit__ runs before the outer except. Acceptable: Right order but thinks label is the Step object, or unsure whether __exit__ runs on error. Red flag: Puts caught before exit load, or thinks the exception is swallowed by the with.

JR-E-O06 · Filtering and grouping orders in pandas

Easy · Output · Junior (1–3 years) · pandas, boolean indexing, groupby, index · 4 min

Question: What does this print?

import pandas as pd

orders = pd.DataFrame({
    "city": ["Pune", "Chennai", "Pune", "Jaipur", "Chennai", "Pune"],
    "amount": [450, 1200, 800, 300, 650, 1500],
})

big = orders[orders["amount"] >= 500]
print(len(orders), len(big))
print(big.index.tolist())
print(big.groupby("city")["amount"].sum())

Expected output:

6 4
[1, 2, 4, 5]
city
Chennai    1850
Pune       2300
Name: amount, dtype: int64

Explanation:

orders["amount"] >= 500 is a boolean Series, one True/False per row. Indexing the DataFrame with it keeps the True rows: 1200, 800, 650 and 1500. So the filtered frame has 4 of the 6 rows.

• Filtering keeps the original index labels. The surviving rows were at positions 1, 2, 4 and 5, so the index is [1, 2, 4, 5], not [0, 1, 2, 3].
• groupby("city")["amount"].sum() returns a Series indexed by city: Chennai 1200 + 650 = 1850, Pune 800 + 1500 =
• Jaipur's only order (300) was filtered out, so it doesn't appear at all.
• groupby sorts the group keys by default, so Chennai comes before Pune.

Takeaway: boolean masks keep the original labels, and groupby(...).sum() gives one row per group present in the data.

Follow-ups:

1. "What does big.loc[0] do? And big.iloc[0]?" big.loc[0] raises KeyError: 0, because there is no row with label 0 any more. big.iloc[0] is the first row by position (Chennai, 1200). Use reset_index(drop=True) if you want labels 0..n-1 again.
2. "Filter Pune orders of at least ₹500. Why does (orders.amount >= 500) and (orders.city == "Pune") fail?" and asks for the truth value of a whole Series, which is ambiguous, so pandas raises ValueError. Use the element-wise & with parentheses: orders[(orders.amount >= 500) & (orders.city == "Pune")].
3. "The report needs Jaipur listed with 0. How?" Reindex the result over all cities: big.groupby("city")["amount"].sum().reindex(orders.city.unique(), fill_value=0), or compute the sum on the full frame with the condition inside the aggregation.

Scoring: Strong: Gets the index [1, 2, 4, 5], the sums, and that Jaipur is missing; knows loc vs iloc. Acceptable: Gets the counts and sums but expects [0, 1, 2, 3]; understands once labels vs positions is mentioned. Red flag: Can't read a boolean mask, or expects Jaipur in the groupby output.

JR-E-C01 · A call-counting decorator

Easy · Coding · Junior (1–3 years) · decorators, functools.wraps, closures, typing · 10 min

Problem:

Write a decorator count_calls that records how many times a function has been called. The count is available as an attribute: after decorating apply_discount, apply_discount.calls starts at 0 and goes up by one per call.

Requirements: - Arguments (positional and keyword) and the return value pass through unchanged. - Each decorated function has its own counter. - A call that raises still counts, and the exception still reaches the caller. - The decorated function keeps its original __name__ and __doc__.

Signature: from typing import Any, Callable, TypeVar F = TypeVar("F", bound=Callable[..., Any]) def count_calls(func: F) -> F:

Constraints: Plain functions only (no methods or async functions needed). Single-threaded use.

Examples:

• apply_discount(1000) after decorating → 900.0, and apply_discount.calls == 1
• two decorated functions, each called once → each has .calls == 1
• apply_discount.__name__ → 'apply_discount'

Hints:

1. Start from the decorator skeleton: a function that takes func, defines wrapper(*args, **kwargs), and returns wrapper.
2. Functions are objects: you can set an attribute on wrapper and update it inside wrapper.
3. Where should the counter live so that two decorated functions don't share it?
4. Which standard-library helper copies __name__ and __doc__ from func to wrapper?

Reference solution:

import functools
from typing import Any, Callable, TypeVar

F = TypeVar("F", bound=Callable[..., Any])


def count_calls(func: F) -> F:
    """Count how many times `func` is called; the count is on `.calls`.

    The wrapper keeps the original name and docstring, passes all
    arguments through unchanged, and counts a call even if it raises.
    """
    @functools.wraps(func)
    def wrapper(*args: Any, **kwargs: Any) -> Any:
        wrapper.calls += 1  # type: ignore[attr-defined]
        return func(*args, **kwargs)

    wrapper.calls = 0  # type: ignore[attr-defined]
    return wrapper  # type: ignore[return-value]

Complexity: O(1) extra time per call and O(1) memory per decorated function.

Tests:

@count_calls
def apply_discount(amount: float, *, pct: float = 10) -> float:
    """Return amount after a percentage discount."""
    if amount < 0:
        raise ValueError("negative amount")
    return amount * (100 - pct) / 100

@count_calls
def greet(name: str) -> str:
    return f"Namaste, {name}"

assert apply_discount.calls == 0
assert apply_discount(1000) == 900.0
assert apply_discount(1000, pct=25) == 750.0          # keyword-only arg passes through
assert apply_discount.calls == 2
assert greet("Asha") == "Namaste, Asha"
assert greet.calls == 1 and apply_discount.calls == 2  # independent counters
try:
    apply_discount(-5)
except ValueError:
    pass
else:
    raise AssertionError("expected ValueError")
assert apply_discount.calls == 3                       # failed calls still count
assert apply_discount.__name__ == "apply_discount"     # metadata preserved
assert apply_discount.__doc__ == "Return amount after a percentage discount."
assert apply_discount.__wrapped__(200) == 180.0        # original reachable, not counted
assert apply_discount.calls == 3

A common wrong solution (the tests catch it):

calls = 0

def count_calls(func):
    def wrapper(*args, **kwargs):
        global calls
        calls += 1
        wrapper.calls = calls
        return func(*args, **kwargs)
    wrapper.calls = 0
    return wrapper

Alternatives and tradeoffs:

• A class with __call__ (self.calls, functools.update_wrapper(self, func)) is easier to type-check and can grow a reset() method, but it doesn't bind as a method on classes without extra work.
• A module-level dict keyed by function name is fragile: two functions with the same name in different modules collide, and it's global state that tests must reset.
• unittest.mock.Mock(wraps=func) gives call_count for free in tests, but it isn't meant for production code.

Pick: the closure version. It's short, each function gets its own counter, and the attribute is easy to read in tests.

Follow-ups:

1. "Why does the counter go on wrapper and not in a global variable?" A global is shared by every decorated function, so greet would see the calls of apply_discount. An attribute on each wrapper (or a nonlocal variable in the decorator) gives each function its own counter.
2. "Should a call that raises be counted?" Here, yes: it was a call. If you only want successful calls, increment after func returns, or keep two counters. The point is to decide and test it.
3. "Two threads call the function at the same time. Is the count correct?" Not guaranteed. wrapper.calls += 1 is a read, an add and a write, and two threads can interleave between them and lose an update. Protect it with a threading.Lock (or use itertools.count, whose next() is atomic in CPython with the GIL).
4. "How would you test this decorator with pytest?" Decorate a tiny function inside the test, call it a few times, assert .calls, assert the return value, and use pytest.raises for the error path. Defining the function in the test keeps counts from leaking between tests.

Scoring: Strong: Uses functools.wraps, keeps a per-function counter, passes *args, **kwargs through and returns the result; tests the error path. Acceptable: Working counter but forgets wraps or the return value until a test fails; fixes it quickly. Red flag: Uses one global counter for all functions, or calls func at decoration time.

JR-E-C02 · Temporarily override environment variables

Easy · Coding · Junior (1–3 years) · context managers, contextlib, try/finally, os.environ, testing · 12 min

Problem:

Tests keep changing os.environ and forgetting to undo it, so later tests fail at random. Write a context manager temp_env(**overrides) that sets the given environment variables for the duration of a with block and then puts everything back exactly as it was.

• temp_env(APP_REGION="ap-south-2") sets the variable inside the block.
• A value of None unsets that variable inside the block.
• On exit, each touched variable returns to its old value, or is removed if it didn't exist before (not set to "").
• Restoration must happen even if the block raises, and the exception must still propagate.

Signature: from collections.abc import Iterator from contextlib import contextmanager @contextmanager def temp_env(**overrides: str | None) -> Iterator[None]:

Constraints: Values are strings; None means "unset this variable inside the block". Single-threaded use (tests).

Examples:

• APP_REGION is 'ap-south-1'; with temp_env(APP_REGION='ap-south-2'): ... → inside: 'ap-south-2'; after: 'ap-south-1'
• APP_DEBUG not set; with temp_env(APP_DEBUG='1'): ... → inside: '1'; after: not in os.environ
• APP_TOKEN is 'secret'; with temp_env(APP_TOKEN=None): ... → inside: not set; after: 'secret'

Hints:

1. contextlib.contextmanager turns a generator with one yield into a context manager.
2. Save the old values before changing anything.
3. "Didn't exist" and "existed as an empty string" are different. How will you remember which it was?
4. What happens to the code after yield if the with block raises? How do you make sure it still runs?

Reference solution:

import os
from collections.abc import Iterator
from contextlib import contextmanager


@contextmanager
def temp_env(**overrides: str | None) -> Iterator[None]:
    """Temporarily set (or, with None, unset) environment variables.

    On exit, even if the block raises, every touched variable goes back to
    exactly what it was: restored to its old value, or removed if it did not
    exist before.
    """
    saved = {name: os.environ.get(name) for name in overrides}
    try:
        for name, value in overrides.items():
            if value is None:
                os.environ.pop(name, None)
            else:
                os.environ[name] = value
        yield
    finally:
        for name, old in saved.items():
            if old is None:
                os.environ.pop(name, None)
            else:
                os.environ[name] = old

Complexity: O(k) time for k overridden variables on enter and exit; O(k) memory for the saved values.

Tests:

import os

os.environ["APP_REGION"] = "ap-south-1"
os.environ.pop("APP_DEBUG", None)
os.environ["APP_TOKEN"] = "secret"

with temp_env(APP_REGION="ap-south-2", APP_DEBUG="1", APP_TOKEN=None):
    assert os.environ["APP_REGION"] == "ap-south-2"
    assert os.environ["APP_DEBUG"] == "1"
    assert "APP_TOKEN" not in os.environ

assert os.environ["APP_REGION"] == "ap-south-1"    # old value restored
assert "APP_DEBUG" not in os.environ               # did not exist before: removed, not ""
assert os.environ["APP_TOKEN"] == "secret"         # unset inside, restored after

try:
    with temp_env(APP_REGION="eu-west-1"):
        raise RuntimeError("test failed midway")
except RuntimeError:
    pass
assert os.environ["APP_REGION"] == "ap-south-1"    # restored even after an exception

with temp_env():                                   # no overrides: a no-op
    pass
assert os.environ["APP_REGION"] == "ap-south-1"

A common wrong solution (the tests catch it):

import os
from contextlib import contextmanager

@contextmanager
def temp_env(**overrides):
    saved = {name: os.environ.get(name, "") for name in overrides}
    for name, value in overrides.items():
        if value is None:
            os.environ.pop(name, None)
        else:
            os.environ[name] = value
    yield
    for name, old in saved.items():
        os.environ[name] = old

Alternatives and tradeoffs:

• pytest's monkeypatch.setenv / monkeypatch.delenv does exactly this inside tests and undoes it automatically; prefer it in pytest code. This helper is for scripts or non-pytest code.
• unittest.mock.patch.dict(os.environ, {...}) restores the whole mapping on exit; it can't easily unset a variable for the duration of the block without clear=True, which wipes everything else.
• A class with __enter__/__exit__ is equivalent and makes the saved state an attribute; more lines for no gain here.

Pick: @contextmanager with try/finally for its size and clarity; monkeypatch inside pytest.

Follow-ups:

1. "Why must the restore code be in finally?" If the block raises, @contextmanager re-raises the exception at the yield. Code after the yield that isn't in finally (or except) is skipped, so a failing test would leave the override in place and break the tests that run after it.
2. "Why not save os.environ.get(name, "")?" Then you can't tell "was unset" from "was set to an empty string", and restoring writes APP_DEBUG="", which is a different state. Code that checks "APP_DEBUG" in os.environ would behave differently after the test.
3. "Is this safe to use from several threads at once?" No. The environment is process-wide, so one thread's override is visible to all threads, and two overlapping blocks can restore each other's values in the wrong order. It's a test helper; pass config explicitly in concurrent code.
4. "How would the code under test read these variables so it's easy to test without this helper at all?" Read the environment once at startup into a settings object (for example a Pydantic BaseSettings or a dataclass) and pass that object in. Tests then build the object directly.

Scoring: Strong: try/finally around the yield, saves old values before changing, restores missing variables by deleting them; mentions monkeypatch. Acceptable: Correct for the happy path; adds finally or the delete case once prompted with a test. Red flag: Doesn't restore on exception, or restores missing variables as empty strings and argues it's equivalent.

JR-E-C03 · Validate a signup payload

Easy · Coding · Junior (1–3 years) · validation, dicts, isinstance, APIs · 12 min

Problem:

A signup API receives a JSON body. Write validate_signup(payload) that returns a dict mapping each invalid field to an error message, or {} if the payload is valid. Report every problem, not just the first.

Rules: - name: required, a string that isn't blank after stripping spaces. Otherwise "required". - email: required, a string with exactly one @, something before it, and a dot inside the domain part (not just at its ends). Otherwise "invalid email". - age: required, an integer (JSON true/false and "27" don't count) → "must be an integer"; and from 18 to 120 inclusive → "must be between 18 and 120". - phone: optional. If present, a string of exactly 10 ASCII digits starting with 6, 7, 8 or 9. Otherwise "must be a 10-digit mobile number". - Any other key: "unknown field".

Signature: from typing import Any def validate_signup(payload: dict[str, Any]) -> dict[str, str]:

Constraints: payload is a dict parsed from JSON (values can be any JSON type). Allowed fields: name, email, age, phone. Error messages are exactly: "required", "invalid email", "must be an integer", "must be between 18 and 120", "must be a 10-digit mobile number", "unknown field".

Examples:

• {"name": "Priya Nair", "email": "priya@example.in", "age": 27, "phone": "9876543210"} → {}
• {} → {"name": "required", "email": "invalid email", "age": "must be an integer"}
• {... valid ..., "age": "27"} → {"age": "must be an integer"}
• {... valid ..., "is_admin": true} → {"is_admin": "unknown field"}

Hints:

1. Check each field independently and add to an errors dict; don't return at the first problem.
2. Use .get() so a missing field doesn't raise KeyError.
3. Check the type before the value: what does "27" >= 18 do?
4. isinstance(True, int) is True. What should "age": true produce?
5. How do you find keys in payload that are not in the allowed set?

Reference solution:

from typing import Any

ALLOWED = {"name", "email", "age", "phone"}


def validate_signup(payload: dict[str, Any]) -> dict[str, str]:
    """Validate a signup payload; return {field: message}, empty if valid.

    Rules: name is a non-blank string; email has one "@", a non-empty local
    part and a dot in the domain; age is an int (not bool) from 18 to 120;
    phone is optional, and when present is 10 digits starting with 6-9.
    Unknown fields are reported as errors too. Every problem is reported,
    not just the first one.
    """
    errors: dict[str, str] = {}

    name = payload.get("name")
    if not isinstance(name, str) or not name.strip():
        errors["name"] = "required"

    email = payload.get("email")
    if not isinstance(email, str) or email.count("@") != 1:
        errors["email"] = "invalid email"
    else:
        local, domain = email.split("@")
        if not local or "." not in domain.strip("."):
            errors["email"] = "invalid email"

    age = payload.get("age")
    if not isinstance(age, int) or isinstance(age, bool):
        errors["age"] = "must be an integer"
    elif not 18 <= age <= 120:
        errors["age"] = "must be between 18 and 120"

    if "phone" in payload:
        phone = payload["phone"]
        if not (isinstance(phone, str) and len(phone) == 10
                and phone.isascii() and phone.isdigit() and phone[0] in "6789"):
            errors["phone"] = "must be a 10-digit mobile number"

    for field in sorted(payload.keys() - ALLOWED):
        errors[field] = "unknown field"
    return errors

Complexity: O(f + s) time for f fields and total string length s; O(f) memory for the errors.

Tests:

good = {"name": "Priya Nair", "email": "priya@example.in", "age": 27, "phone": "9876543210"}
assert validate_signup(good) == {}
assert validate_signup({"name": "Ravi", "email": "ravi@example.com", "age": 18}) == {}  # phone optional, 18 allowed

assert validate_signup({}) == {"name": "required", "email": "invalid email", "age": "must be an integer"}
assert validate_signup({**good, "name": "   "}) == {"name": "required"}
assert validate_signup({**good, "email": "priya.example.in"}) == {"email": "invalid email"}
assert validate_signup({**good, "email": "@example.in"}) == {"email": "invalid email"}
assert validate_signup({**good, "email": "a@b@c.in"}) == {"email": "invalid email"}
assert validate_signup({**good, "email": "priya@localhost"}) == {"email": "invalid email"}
assert validate_signup({**good, "age": 17}) == {"age": "must be between 18 and 120"}
assert validate_signup({**good, "age": "27"}) == {"age": "must be an integer"}   # JSON string, not int
assert validate_signup({**good, "age": True}) == {"age": "must be an integer"}   # bool is an int subclass
assert validate_signup({**good, "phone": "12345"}) == {"phone": "must be a 10-digit mobile number"}
assert validate_signup({**good, "phone": "5876543210"}) == {"phone": "must be a 10-digit mobile number"}
assert validate_signup({**good, "phone": "９８７６５４３２１０"}) == {"phone": "must be a 10-digit mobile number"}  # full-width digits
assert validate_signup({**good, "is_admin": True}) == {"is_admin": "unknown field"}
both = validate_signup({"name": "", "email": "x@y.in", "age": 200})
assert both == {"name": "required", "age": "must be between 18 and 120"}        # all errors, not just the first

A common wrong solution (the tests catch it):

def validate_signup(payload):
    errors = {}
    if not payload.get("name", "").strip():
        errors["name"] = "required"
    email = payload.get("email", "")
    if "@" not in email or "." not in email.split("@")[-1]:
        errors["email"] = "invalid email"
    age = payload.get("age")
    if not isinstance(age, int):
        errors["age"] = "must be an integer"
    elif not 18 <= age <= 120:
        errors["age"] = "must be between 18 and 120"
    phone = payload.get("phone")
    if phone and not (len(phone) == 10 and phone.isdigit()):
        errors["phone"] = "must be a 10-digit mobile number"
    return errors

Alternatives and tradeoffs:

• A Pydantic model (EmailStr, Field(ge=18, le=120), pattern=..., model_config = ConfigDict(extra="forbid", strict=True)) is what you'd use in a FastAPI service: declarative, returns all errors, generates API docs. In lax mode Pydantic would accept "27" and convert it to 27, which may or may not be what you want.
• A real email check is not a short regex. Production code uses a library (email-validator) for syntax and a confirmation mail for ownership.
• Raise on the first error is simpler, but the user then fixes one field per submit. Returning every error is friendlier for forms.

Pick: in a FastAPI app, a Pydantic model with extra="forbid"; this hand-written version shows the same rules explicitly.

Follow-ups:

1. "Why reject unknown fields instead of ignoring them?" Mass assignment: if the handler later does User(**payload) or db.update(**payload), a client could set is_admin or balance. Rejecting (or at least explicitly dropping) unknown fields closes that hole and also catches client typos like emial.
2. "How would this look as a FastAPI endpoint?" Define a Pydantic SignupIn model and use it as the body parameter. FastAPI validates it and returns 422 with every error listed, before your function runs. Your handler only sees valid data.
3. "The phone check uses isascii() as well as isdigit(). Why?" isdigit() accepts other scripts' digits, such as full-width ９ or Devanagari ९. int() would even convert them. If downstream systems (an SMS gateway) expect ASCII digits, check for them explicitly.
4. "Should the API return 400 or 422 for these errors?" Either is defensible; be consistent. FastAPI uses 422 Unprocessable Entity for body validation errors and 400 for malformed requests (such as invalid JSON). Include the per-field messages in the body.

Scoring: Strong: Collects all errors, checks type before value, handles bool and string ages, rejects unknown fields; mentions Pydantic for a real service. Acceptable: Correct for typical inputs; misses bool or unknown fields until shown a failing test, then fixes it. Red flag: Crashes with KeyError/TypeError on a missing or wrong-typed field, or stops at the first error.

JR-ET-O01 · A cart helper with a default list

Easy & Tricky · Output · Junior (1–3 years) · functions, mutable default arguments, aliasing · 3 min

Question: What does this print?

def add_to_cart(item, cart=[]):
    cart.append(item)
    return cart

asha = add_to_cart("chai")
ravi = add_to_cart("samosa")
priya = add_to_cart("lassi", [])

print(asha)
print(ravi)
print(priya)
print(asha is ravi)

Expected output:

['chai', 'samosa']
['chai', 'samosa']
['lassi']
True

The trap:

['chai'], ['samosa'], ['lassi'], False. Tempting because the default looks like it creates an empty list on each call, as it would in many other languages.

Real-world bug it maps to: a helper like def validate(row, errors=[]) in a long-running API worker. Each request adds its errors to the same list, so the second customer sees the first customer's validation errors, and the list keeps growing until the process restarts.

Explanation:

Default values are evaluated once, when the def statement runs, and stored on the function (add_to_cart.__defaults__). Every call that doesn't pass cart gets the same list object.

• Asha's call appends "chai" to that shared default list and returns it.
• Ravi's call appends "samosa" to the same list and returns it again. asha and ravi are two names for one list, so both print ['chai', 'samosa'] and asha is ravi is True.
• Priya passes her own new list, so the default is not involved.

Fix: use None as the default and create the list inside the function: def add_to_cart(item, cart=None): if cart is None: cart = [].

Takeaway: a mutable default is shared by every call; use None and create a fresh object in the body.

Follow-ups:

1. "How can you see the shared list without calling the function?" add_to_cart.__defaults__ holds the default values. After the first call it is (['chai'],).
2. "Why doesn't def bump(n=0): n += 1; return n have the same problem?" Ints are immutable. n += 1 builds a new int and rebinds the local name n; the stored default 0 is never changed. The problem only appears when the default object is mutated.
3. "Do dataclasses or Pydantic models have the same issue with items: list = []?" A dataclass refuses it at class creation (ValueError: mutable default <class 'list'> for field items is not allowed: use default_factory); use field(default_factory=list). Pydantic v2 copies the default for each instance, so it's safe there, but Field(default_factory=list) states the intent clearly.

Scoring: Strong: Exact output; explains that defaults are evaluated once at definition time; gives the None fix unprompted. Acceptable: Knows mutable defaults are dangerous but misses that asha and ravi are the same object (prints ['chai'] first). Red flag: Predicts independent lists and can't explain the output after seeing it.

JR-ET-O02 · Booking one seat in a cinema seat map

Easy & Tricky · Output · Junior (1–3 years) · lists, aliasing, list multiplication · 3 min

Question: What does this print?

rows, cols = 3, 4
seats = [[0] * cols] * rows

seats[0][1] = 1          # book row A, seat 2
print(seats)

booked = sum(sum(row) for row in seats)
print("booked:", booked)
print(seats[0] is seats[2])

Expected output:

[[0, 1, 0, 0], [0, 1, 0, 0], [0, 1, 0, 0]]
booked: 3
True

The trap:

[[0, 1, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0]], booked: 1, False. Tempting because [[0] * cols] * rows reads like "a 3 × 4 grid of zeros", and printing it before the assignment looks exactly like one.

Real-world bug it maps to: a seat map, a calendar grid ([[None] * 7] * 5 for a month view) or a per-shard batch list ([[]] * n_shards). One booking or one appended record shows up in every row, and the count is n times too high.

Explanation:

[0] * cols makes one row of four zeros. [row] * rows then makes an outer list containing three references to that same row object; * copies references, not the objects they point to.

• seats[0][1] = 1 changes the shared row, so every "row" shows the booking.
• The sum counts the same booked seat three times: booked: 3.
• seats[0] is seats[2] is True: they are the same list.

The inner [0] * cols is fine because ints are immutable: row[1] = 1 puts a new value in one slot, it doesn't change the 0 object other slots refer to.

Fix: build each row separately, seats = [[0] * cols for _ in range(rows)], or use numpy.zeros((rows, cols), dtype=int).

Takeaway: [x] * n repeats references; with a mutable x you get n names for one object.

Follow-ups:

1. "What does buckets = [[]] * 3; buckets[0].append("x"); print(buckets) print?" [['x'], ['x'], ['x']]. Same mechanism: three references to one empty list. Use [[] for _ in range(3)].
2. "How could you have caught this bug before production?" A test that books one seat and asserts booked == 1 and that other rows are untouched. Printing the grid right after creation doesn't help, because it looks correct.
3. "Does copy.copy(seats) give independent rows?" No. A shallow copy makes a new outer list holding the same row objects (here, three references to the one row). You need new inner lists: a comprehension or copy.deepcopy.

Scoring: Strong: Predicts all three lines and explains that * repeats references; gives the comprehension fix. Acceptable: Senses something is off with nested * but can't state the result exactly; explains it once shown. Red flag: Predicts one booked seat and still can't explain the output after running it.

JR-ET-O03 · Two modules both call logging.basicConfig

Easy & Tricky · Output · Junior (1–3 years) · logging, basicConfig, log levels · 4 min

Question: What does this print?

import logging
import sys

# orders/config.py, imported first
logging.basicConfig(stream=sys.stdout, format="%(levelname)s %(name)s: %(message)s")

# main.py, runs later and wants to see INFO logs
logging.basicConfig(stream=sys.stdout, level=logging.INFO,
                    format="%(asctime)s %(levelname)s %(message)s")

log = logging.getLogger("orders.sync")
log.info("synced 120 orders")
log.warning("3 orders missing GSTIN")
log.debug("raw payload: ...")
print(logging.getLogger().level == logging.WARNING)

Expected output:

WARNING orders.sync: 3 orders missing GSTIN
True

The trap:

Something like <timestamp> INFO synced 120 orders and <timestamp> WARNING 3 orders missing GSTIN. Tempting because the last basicConfig call "should win", the way a later assignment overwrites an earlier one.

Real-world bug it maps to: a shared utility module calls basicConfig() at import time. The service's own logging setup in main.py then does nothing, INFO logs never reach production, and during an incident nobody can tell which orders were synced.

Explanation:

logging.basicConfig configures the root logger only if it has no handlers yet. The first call (in orders/config.py) adds a stdout handler with the LEVEL name: message format. It doesn't pass level, so the root logger keeps its default level, WARNING.

The second call in main.py finds a handler already on the root logger and does nothing at all: its level=INFO and its format are both ignored, and no error or warning is raised.

• log.info(...): the orders.sync logger has no level of its own, so its effective level comes from the root: WARNING. INFO is below that, so it is dropped.
• log.warning(...) passes and is printed with the first call's format.
• log.debug(...) is dropped. The last line confirms the root level is still WARNING.

Fix: configure logging once, in the application's entry point; library modules should only call logging.getLogger(__name__). If you must override an existing setup, pass force=True (3.8+) or use logging.config.dictConfig.

Takeaway: basicConfig is a one-shot convenience; the second call is silently ignored.

Follow-ups:

1. "Without changing the basicConfig calls, how do you get DEBUG logs from orders.sync only?" logging.getLogger("orders.sync").setLevel(logging.DEBUG). The logger's own level now allows DEBUG, the record propagates to the root's handler, and that handler has no level filter (NOTSET), so it is printed. Other loggers stay at WARNING.
2. "Why logging.getLogger(__name__) rather than one global logger?" Each module gets a logger named after its import path (orders.sync). You can tune levels per package, and the %(name)s field shows where a message came from.
3. "log.info(f"synced {n} orders") or log.info("synced %d orders", n)?" The % form: the string is only formatted if the record is actually emitted, and log aggregators can group messages by the constant template. It matters most in hot loops with DEBUG logs that are usually off.

Scoring: Strong: Only the WARNING line with the first format; explains the one-shot rule and the default WARNING level; names "configure once in main" or force=True. Acceptable: Knows INFO is hidden by default but expects the second call's format or level to apply. Red flag: Expects all three messages to print, or doesn't know logging levels at all.

JR-ET-O04 · Employee IDs read from a CSV with pandas

Easy & Tricky · Output · Junior (1–3 years) · pandas, read_csv, dtype inference · 3 min

Question: What does this print?

import io
import pandas as pd

csv_text = """emp_id,name,phone
00731,Asha,09840012345
01204,Ravi,09812300011
"""

df = pd.read_csv(io.StringIO(csv_text))
print(df["emp_id"].tolist())
print(df["phone"].tolist())
print(df.dtypes.astype(str).to_dict())
print(df[df["emp_id"] == "00731"].shape)

Expected output:

[731, 1204]
[9840012345, 9812300011]
{'emp_id': 'int64', 'name': 'object', 'phone': 'int64'}
(0, 3)

The trap:

['00731', '01204'], the phone numbers with their leading zeros, and (1, 3). Tempting because the file shows the zeros and nothing in the code asks for numbers.

Real-world bug it maps to: an HR or KYC file is loaded with read_csv, IDs lose their leading zeros, and the join with the payroll system (which stores "00731") silently matches nothing. No error is raised; the report just shows fewer employees.

Explanation:

read_csv infers a type for each column. A column whose values all look like whole numbers becomes int64, and the conversion drops the leading zeros: "00731" becomes 731, and the phone numbers lose their leading 0. Only name stays as strings (object).

The last line compares an int64 column with the string "00731". pandas doesn't raise; every comparison is simply False, so the filter returns an empty frame with 0 rows and 3 columns.

Fix: tell pandas which columns are identifiers, pd.read_csv(..., dtype={"emp_id": str, "phone": str}), or dtype=str for everything and convert numeric columns explicitly.

Takeaway: codes that happen to be made of digits (IDs, phone numbers, PIN codes, account numbers) are text; read them as str.

Follow-ups:

1. "What happens to emp_id if one row has an empty ID?" The column becomes float64: [731.0, nan]. Missing values are NaN, a float, so the whole column is upcast. Now the IDs print as 731.0. With dtype=str the empty cell is NaN but the others stay "00731".
2. "How would you find this problem in a large file you didn't write?" Check df.dtypes right after loading and compare with what you expect, assert ID lengths (df.emp_id.str.len().eq(5).all() after reading as str), and count rows matched by joins.
3. "Is df["emp_id"].astype(str).str.zfill(5) a good fix after loading?" It only works if every ID has the same known width. A zero-padded code with a variable width can't be recovered. Fix it at read time instead.

Scoring: Strong: Predicts the int conversion, lost zeros, and the empty result with no error; fixes with dtype=. Acceptable: Knows pandas infers types but expects the string comparison to raise or to match. Red flag: Assumes read_csv keeps every value as text, and doesn't check dtypes even after seeing the output.

JR-ET-O05 · Returning a lazy reader from inside a with block

Easy & Tricky · Output · Junior (1–3 years) · context managers, files, generators, laziness · 4 min

Question: What does this print?

from pathlib import Path

Path("orders.txt").write_text("ORD-101\nORD-102\nORD-103\n")

def read_ids_list(path):
    with open(path) as f:
        return [line.strip() for line in f]

def read_ids(path):
    with open(path) as f:
        return (line.strip() for line in f)

print(read_ids_list("orders.txt"))
ids = read_ids("orders.txt")
print(type(ids).__name__)
print(list(ids))

Expected output:

['ORD-101', 'ORD-102', 'ORD-103']
generator
ValueError: I/O operation on closed file.

The trap:

The list twice: ['ORD-101', 'ORD-102', 'ORD-103'], generator, ['ORD-101', 'ORD-102', 'ORD-103']. Tempting because the two functions differ only in [...] versus (...), and switching to a generator "to save memory" looks like a safe refactor.

Real-world bug it maps to: a refactor changes a loader to return a generator "for large files", and every caller now fails with I/O operation on closed file. The same pattern happens with a database cursor or an HTTP streaming response that is returned from inside its with block.

Explanation:

Both functions open the file in a with block, and with closes the file as soon as the block is left, including by return.

• read_ids_list builds a list inside the block, so every line is read while the file is open. Then the file closes and the finished list is returned.
• read_ids returns a generator expression. A generator expression reads nothing when it is created; it only holds on to f. The return leaves the with block and the file is closed.
• list(ids) then asks the generator for its first line. It tries to read from the closed file and raises ValueError: I/O operation on closed file.

Fix: keep the file open for as long as the data is consumed by making the function itself a generator, def read_ids(path): with open(path) as f: yield from (line.strip() for line in f). Or return a list when the file is small.

Takeaway: anything lazy that reads from a resource must be consumed before the with block closes that resource.

Follow-ups:

1. "With the yield from fix, when is the file closed?" When the generator finishes (all lines read), or when it is closed early: gen.close(), the caller's for loop ending with break followed by garbage collection, or the program exiting. If a caller stops halfway and keeps a reference, the file stays open; for strict control, let the caller own the with.
2. "Why didn't the error happen when read_ids was called?" Creating a generator expression evaluates only its outermost iterable (iter(f), which succeeds while the file is still open). Nothing is read until next() is called, which happens later, inside list(ids).
3. "Where else does this pattern appear?" Returning a query result iterator from inside with conn: or a session block; returning response.iter_lines() from inside with httpx.stream(...); a pandas read_csv(..., chunksize=...) reader whose file handle was closed.

Scoring: Strong: Predicts the ValueError and explains that the generator expression reads lazily after the with has closed the file; gives the yield fix. Acceptable: Suspects the generator version is different but can't name the error; explains it once told when the file closes. Red flag: Predicts the same list twice and can't explain the error after seeing it.

JR-ET-O06 · An API client that saves error responses

Easy & Tricky · Output · Junior (1–3 years) · HTTP, httpx, status codes, exceptions · 4 min

Question: What does this print?

import httpx

def handler(request):
    if request.url.path == "/orders/42":
        return httpx.Response(200, json={"id": 42, "total": 1499})
    return httpx.Response(404, json={"detail": "order not found"})

client = httpx.Client(transport=httpx.MockTransport(handler),
                      base_url="https://api.shop.example")

for order_id in (42, 99):
    try:
        response = client.get(f"/orders/{order_id}")
        data = response.json()
        print("saved", data)
    except httpx.HTTPError as exc:
        print("failed", type(exc).__name__)

try:
    client.get("/orders/99").raise_for_status()
except httpx.HTTPStatusError as exc:
    print("failed", exc.response.status_code)

Expected output:

saved {'id': 42, 'total': 1499}
saved {'detail': 'order not found'}
failed 404

The trap:

saved {'id': 42, 'total': 1499} then failed HTTPStatusError for order 99. Tempting because the except httpx.HTTPError block looks like it covers "any HTTP failure", and many people assume a 404 raises.

Real-world bug it maps to: a nightly job syncs orders from a partner API and writes {"detail": "order not found"} rows into the warehouse, or, during a partner outage, stores {"error": "service unavailable"} as data for thousands of orders.

Explanation:

httpx.MockTransport lets the client run without a network: the handler returns 200 for order 42 and 404 with a JSON error body for anything else.

The key point: httpx does not raise for 4xx or 5xx responses. A 404 is a successful HTTP exchange; the server answered. client.get returns a normal Response, .json() parses the error body, and the loop "saves" it as if it were an order.

httpx.HTTPError is raised only for transport problems (connection refused, timeouts: httpx.RequestError) or when you ask for a status check: response.raise_for_status() raises httpx.HTTPStatusError for 4xx and 5xx. That is what the last block does, so it prints failed 404.

Fix: call response.raise_for_status() before using the body, or check response.status_code / response.is_success and handle 404 explicitly.

Takeaway: an HTTP client returns error responses as ordinary responses; check the status before trusting the body.

Follow-ups:

1. "Which errors would you retry, and which not?" Retry transport errors (httpx.ConnectError, httpx.TimeoutException), 429 Too Many Requests (respect Retry-After) and 502/503/504, with a limit and backoff. Don't retry 400, 401, 403, 404 or 422: repeating the same request gives the same answer.
2. "Why is MockTransport useful in tests?" Tests run without a network and are deterministic, and you can make the "server" return any status, body or exception to test your error handling. The production code under test still uses a real httpx.Client.
3. "Does httpx follow redirects by default?" No. httpx returns the 301/302 response unless you pass follow_redirects=True (the requests library follows them by default). A client migrated from requests can suddenly see 3xx responses.

Scoring: Strong: Predicts that the 404 body is "saved"; separates transport errors from status errors; uses raise_for_status. Acceptable: Unsure whether a 404 raises, but immediately proposes checking status_code once told it doesn't. Red flag: Insists a 404 raises an exception, or would store whatever .json() returns without any status check.

JR-ET-C01 · Pick the latest release tag

Easy & Tricky · Coding · Junior (1–3 years) · strings, sorting, regex, packaging, versions · 10 min

Problem:

A deploy script must pick the newest release from a repository's Git tags. Release tags look like vMAJOR.MINOR.PATCH (for example v1.10.0); other tags such as nightly, v1.4 or v1.10.1-rc1 must be ignored. Return the newest release tag exactly as written, or None if there are none.

"Newest" means compare MAJOR first, then MINOR, then PATCH, as numbers.

Signature: def latest_release(tags: list[str]) -> str | None:

Constraints: Up to 10^4 tags. Release tags look like v1.10.0 (three numeric parts). Anything else is ignored.

Examples:

• ["v1.2.10", "v1.9.2", "nightly", "v1.10.0"] → "v1.10.0"
• ["v2.0.0", "v10.0.0"] → "v10.0.0"
• ["nightly", "v2"] → None

Hints:

1. What does "v1.9.2" < "v1.10.0" evaluate to, and why?
2. Turn each tag into something that compares the way versions do.
3. Tuples compare element by element, left to right.
4. Use re.fullmatch so v1.3.0-rc1 and v1.2.3 don't sneak through.

Reference solution:

import re

TAG = re.compile(r"v(\d+)\.(\d+)\.(\d+)")


def latest_release(tags: list[str]) -> str | None:
    """Return the highest release tag of the form vMAJOR.MINOR.PATCH.

    Components compare as numbers, so v1.10.0 is newer than v1.9.2.
    Tags that don't match exactly (nightly, v1.2, v1.3.0-rc1) are ignored.
    Returns None when no tag matches.
    """
    best: str | None = None
    best_key: tuple[int, int, int] | None = None
    for tag in tags:
        match = TAG.fullmatch(tag)
        if match is None:
            continue
        major, minor, patch = (int(part) for part in match.groups())
        key = (major, minor, patch)
        if best_key is None or key > best_key:
            best, best_key = tag, key
    return best

Complexity: O(n · L) time for n tags of length L (one pass, no sort); O(1) extra memory.

Tests:

tags = ["v1.2.10", "v1.9.2", "nightly", "v1.10.0", "v1.10.1-rc1", "v1.4"]
assert latest_release(tags) == "v1.10.0"                        # 10 > 9 as numbers
assert latest_release(["v2.0.0", "v10.0.0", "v9.9.9"]) == "v10.0.0"
assert latest_release(["v1.0.9", "v1.0.10"]) == "v1.0.10"       # patch compared numerically too
assert latest_release(["v3.1.0", "v3.0.12"]) == "v3.1.0"        # minor beats patch
assert latest_release([]) is None
assert latest_release(["nightly", "latest", "v2"]) is None
assert latest_release(["v0.0.1"]) == "v0.0.1"
assert latest_release(["v1.2.3 ", "x-v9.9.9"]) is None          # exact match only

A common wrong solution (the tests catch it):

import re

def latest_release(tags):
    valid = [t for t in tags if re.fullmatch(r"v\d+\.\d+\.\d+", t)]
    return max(valid) if valid else None

Alternatives and tradeoffs:

• max(valid, key=parse) with a small parse function returning (major, minor, patch) is the shortest correct version; equivalent to the loop.
• sorted(..., key=parse)[-1] works but is O(n log n) to find one maximum.
• packaging.version.Version (the library pip uses) understands pre-releases (1.3.0rc1), post-releases, epochs and PEP 440 ordering. Use it when tags follow Python packaging rules; it isn't in the standard library.

Pick: max with a tuple key for this simple format; packaging.version for real Python package versions.

Follow-ups:

1. "Where does this bug show up in practice?" Deploy scripts that pick "the latest" Docker image or Git tag with sort or max, so v1.9.2 is deployed instead of v1.10.0. The same happens with files named report_9.csv / report_10.csv and with invoice numbers stored as strings.
2. "Now v1.10.0-rc1 should count, but rank below v1.10.0. How would you change the key?" Parse the suffix and add a fourth key element that sorts pre-releases first, for example (1, 10, 0, 0, 1) for rc1 and (1, 10, 0, 1, 0) for the final release. Or use packaging.version, which already implements these rules.
3. "How does pip decide that numpy>=2.0,<3 allows 2.10.1 but not 3.0.0?" It parses versions into comparable objects (PEP 440) and compares them numerically per component, exactly the idea here, never as plain strings.

Scoring: Strong: Notices the string-comparison trap before coding, compares numeric tuples, and validates with fullmatch. Acceptable: Writes max(tags) first but finds the bug with the v1.10.0 example and fixes it with a tuple key. Red flag: Ships sorted(tags)[-1] and argues it's fine because the tags "look sorted".

JR-ET-C02 · Summarise product ratings where 0 stars is valid

Easy & Tricky · Coding · Junior (1–3 years) · truthiness, None, feature engineering, aggregation · 10 min

Problem:

A product page and a recommendation model both need a summary of a product's star ratings. Each rating is 0–5 stars, or None when the customer bought the product but didn't rate it. 0 stars is a real rating.

Return a dict with: - count: number of ratings given, - missing: number of None entries, - average: mean of the given ratings rounded to 2 decimals, or None if there are none, - lowest: the smallest given rating, or None if there are none.

Signature: def summarise_ratings(ratings: list[int | None]) -> dict[str, int | float | None]:

Constraints: Ratings are integers from 0 to 5, or None for "not rated". Up to 10^6 entries.

Examples:

• [5, 4, None, 3] → {"count": 3, "missing": 1, "average": 4.0, "lowest": 3}
• [5, 0, None, 4] → {"count": 3, "missing": 1, "average": 3.0, "lowest": 0}
• [None, None] → {"count": 0, "missing": 2, "average": None, "lowest": None}

Hints:

1. Which values are falsy in Python? Is 0 one of them?
2. How do you test specifically for "this value is missing"?
3. What should average be when nothing was rated, and how do you avoid dividing by zero?

Reference solution:

def summarise_ratings(ratings: list[int | None]) -> dict[str, int | float | None]:
    """Summarise 0-5 star ratings for a product page and a model feature.

    None means "not rated" and is skipped; 0 stars is a real rating.
    Returns count (ratings given), missing (None entries), average
    (rounded to 2 decimals) and lowest; average and lowest are None
    when nothing was rated.
    """
    given = [r for r in ratings if r is not None]
    return {
        "count": len(given),
        "missing": len(ratings) - len(given),
        "average": round(sum(given) / len(given), 2) if given else None,
        "lowest": min(given) if given else None,
    }

Complexity: O(n) time, O(n) extra memory for the filtered list (O(1) with a single running loop).

Tests:

assert summarise_ratings([5, 4, None, 3]) == {"count": 3, "missing": 1, "average": 4.0, "lowest": 3}
assert summarise_ratings([5, 0, None, 4]) == {"count": 3, "missing": 1, "average": 3.0, "lowest": 0}  # 0 counts
assert summarise_ratings([0, 0]) == {"count": 2, "missing": 0, "average": 0.0, "lowest": 0}
assert summarise_ratings([None, None]) == {"count": 0, "missing": 2, "average": None, "lowest": None}
assert summarise_ratings([]) == {"count": 0, "missing": 0, "average": None, "lowest": None}
assert summarise_ratings([4, 5, 5])["average"] == 4.67
for sample in ([5, 0, None], [0], [None, 0, 0, 3]):
    s = summarise_ratings(sample)
    assert s["count"] + s["missing"] == len(sample)        # every entry accounted for

A common wrong solution (the tests catch it):

def summarise_ratings(ratings):
    given = [r for r in ratings if r]
    return {
        "count": len(given),
        "missing": ratings.count(None),
        "average": round(sum(given) / len(given), 2) if given else None,
        "lowest": min(given) if given else None,
    }

Alternatives and tradeoffs:

• One loop with running totals (count, total, lowest) uses O(1) memory, which matters for very large inputs; the list version is easier to read.
• pandas: s = pd.Series(ratings, dtype="Float64"); s.count(), s.isna().sum(), s.mean() and s.min() all skip missing values and treat 0 as a value. Good when the data is already in a DataFrame.
• statistics.fmean on the filtered list is fine, but still needs the empty-list check (StatisticsError).

Pick: the filtered list for clarity; the running loop for streams.

Follow-ups:

1. "Where else does if x: silently drop valid data?" Quantity or discount 0, an empty string that is a legitimate value, 0.0 sensor readings, page number 0 in an API, a flag that is False. Any time None means "missing", test is None, not truthiness.
2. "This summary becomes a model feature. What do you do for products with no ratings?" Don't silently use 0: it means "terrible" to the model. Use a fill value computed on training data (such as the global mean) and add a has_ratings or count feature so the model can tell the cases apart.
3. "Why is the count + missing == len(ratings) test useful?" It's an invariant that catches any entry that was neither counted nor reported missing, which is exactly what happens to the zeros in the buggy version. Invariant checks like this are cheap and catch whole classes of bugs.

Scoring: Strong: Uses is not None, explains why if r is wrong for 0, handles the empty case, adds an invariant check. Acceptable: Writes if r first but fixes it as soon as the 0-star example is mentioned. Red flag: Treats 0 as missing and defends it, or divides by zero on an all-None list.

JR-ET-C03 · Fill missing features at inference time

Easy & Tricky · Coding · Junior (1–3 years) · pandas, missing values, feature engineering, training/inference split · 12 min

Problem:

A credit-scoring model was trained on data where missing numeric features were filled with each column's median. The same filling must happen when the model scores new applications, which arrive in batches of any size, often one row at a time.

Write two functions: - fit_medians(train, cols) learns the median of each listed column from the training data (ignoring NaN) and returns them as a dict. Raise ValueError if a column has no non-missing values. - impute(batch, medians) returns a new DataFrame with NaNs in those columns filled with the stored medians. Other columns are left as they are, and batch itself is not modified.

Signature: import pandas as pd def fit_medians(train: pd.DataFrame, cols: list[str]) -> dict[str, float]: def impute(batch: pd.DataFrame, medians: dict[str, float]) -> pd.DataFrame:

Constraints: train can be large; batch at inference is often a single row. Only numeric columns are listed in cols. Don't modify the input DataFrames.

Examples:

• train income_lakh = [4, 6, NaN, 10, 12]; batch has one row with income_lakh NaN → the row gets 8.0 (training median)
• batch = income_lakh [NaN, 50, 60] → [8.0, 50.0, 60.0] (not the batch median 55.0)
• a training column that is all NaN → fit_medians raises ValueError

Hints:

1. Which data should the fill value come from, the batch you're scoring or the data the model was trained on?
2. What is the median of a one-row batch whose only value is NaN?
3. Split the work: learn the numbers once (fit), apply them many times (transform).
4. DataFrame.fillna accepts a dict of {column: value} and returns a new frame.

Reference solution:

import pandas as pd


def fit_medians(train: pd.DataFrame, cols: list[str]) -> dict[str, float]:
    """Learn one fill value per column from the TRAINING data only."""
    medians: dict[str, float] = {}
    for col in cols:
        values = train[col].dropna()
        if values.empty:
            raise ValueError(f"column {col!r} has no values in training data")
        medians[col] = float(values.median())
    return medians


def impute(batch: pd.DataFrame, medians: dict[str, float]) -> pd.DataFrame:
    """Fill missing values in `batch` with the stored training medians.

    Returns a new DataFrame; `batch` is not modified. Columns without a
    stored median are left as they are.
    """
    return batch.fillna(value=medians)

Complexity: fit_medians: O(n) per column (median needs a selection pass). impute: O(m · c) for m rows and c columns; returns a new frame, O(m · c) memory.

Tests:

import numpy as np

train = pd.DataFrame({
    "income_lakh": [4.0, 6.0, np.nan, 10.0, 12.0],
    "age": [25, 31, 40, np.nan, 52],
    "city": ["Pune", "Delhi", None, "Pune", "Mumbai"],
})
stats = fit_medians(train, ["income_lakh", "age"])
assert stats == {"income_lakh": 8.0, "age": 35.5}

# inference: one request at a time
one = pd.DataFrame({"income_lakh": [np.nan], "age": [29.0], "city": [None]})
out = impute(one, stats)
assert out.loc[0, "income_lakh"] == 8.0          # training median, not the batch's own
assert out.loc[0, "age"] == 29.0                  # present values untouched
assert out.loc[0, "city"] is None                 # columns without a median left alone
assert np.isnan(one.loc[0, "income_lakh"])       # input batch not modified

# the same row must get the same value whatever else is in the batch
batch = pd.DataFrame({"income_lakh": [np.nan, 50.0, 60.0], "age": [np.nan, 70.0, 80.0]})
filled = impute(batch, stats)
assert filled["income_lakh"].tolist() == [8.0, 50.0, 60.0]
assert filled["age"].tolist() == [35.5, 70.0, 80.0]

try:
    fit_medians(pd.DataFrame({"x": [np.nan, np.nan]}), ["x"])
    raise AssertionError("expected ValueError")
except ValueError:
    pass

A common wrong solution (the tests catch it):

import math
import pandas as pd

def fit_medians(train, cols):
    medians = {}
    for col in cols:
        value = train[col].median()
        if math.isnan(value):
            raise ValueError(f"column {col!r} has no values in training data")
        medians[col] = float(value)
    return medians

def impute(batch, medians):
    cols = list(medians)
    return batch.fillna(batch[cols].median())

Alternatives and tradeoffs:

• scikit-learn SimpleImputer(strategy="median") inside a Pipeline does exactly this split (fit on train, transform at inference) and is saved together with the model. Prefer it when you already use scikit-learn.
• Storing medians in a JSON file next to the model makes the values visible and versioned; just make sure the serving code loads the file from the same model version.
• Filling with the batch's own median is the wrong approach this question targets: results change with batch size, and single-row batches aren't filled at all.

Pick: whatever your stack uses for a fitted preprocessing step, saved with the model artifact.

Follow-ups:

1. "Where does this bug come from in practice?" Notebook code does df.fillna(df.median()) on the whole dataset, and the same line is copied into the serving code. Offline scores look fine; online, single-row requests keep NaN and the model errors or predicts garbage. The fix is a fit/transform split.
2. "Should the medians be computed before or after the train/test split?" After, on the training part only. Computing them on all data leaks information from the test set into training and makes offline scores look better than they are.
3. "Why raise when a training column is entirely missing?" The median would be NaN, so impute would silently do nothing. It's better to fail at training time than to discover at serving time that a feature is never filled.
4. "How would you test that training and serving give the same features?" Save a few training rows with their expected features, run them through the serving code path, and assert they match. Include a single-row request with missing values, which is what this question's tests do.

Scoring: Strong: Separates fit and transform without being told, explains why batch statistics are wrong, doesn't mutate input, handles the all-missing training column. Acceptable: Starts with batch.fillna(batch.median()) but switches to stored training medians once asked about a one-row batch. Red flag: Recomputes statistics at inference and argues it's "more up to date", or mutates the caller's DataFrame.

JR-M-O01 · Logger levels, handler levels and propagation in a billing service

Medium · Output · Junior (1–3 years) · logging, logger hierarchy, log levels, handlers, propagation · 6 min

Question: What does this print? (The handler writes to stdout so you can see every record that gets through.)

import logging
import sys

handler = logging.StreamHandler(sys.stdout)
handler.setFormatter(logging.Formatter("%(levelname)s %(name)s: %(message)s"))

app_log = logging.getLogger("billing")
app_log.addHandler(handler)
app_log.setLevel(logging.INFO)

gst_log = logging.getLogger("billing.gst")
gst_log.setLevel(logging.DEBUG)

gst_log.debug("rate lookup for HSN 8471")
gst_log.info("GST 18% applied to INV-204")
app_log.debug("cache warm")
app_log.info("invoice INV-204 total ₹11,800")

handler.setLevel(logging.WARNING)
gst_log.info("GST 5% applied to INV-205")
gst_log.warning("missing GSTIN for customer C-17")

print(logging.getLogger("billing.upi").getEffectiveLevel())
print(gst_log.parent.name, gst_log.handlers)

Expected output:

DEBUG billing.gst: rate lookup for HSN 8471
INFO billing.gst: GST 18% applied to INV-204
INFO billing: invoice INV-204 total ₹11,800
WARNING billing.gst: missing GSTIN for customer C-17
20
billing []

The trap: Many candidates leave out the first line, reasoning that billing is at INFO, so a DEBUG message "can't get through the parent". That is wrong because propagation checks parent handlers, not parent logger levels. A second common slip is to print the INV-205 INFO line, forgetting that the handler now filters at WARNING.

Explanation:

Loggers form a tree by their dotted names: billing.gst and billing.upi are children of billing, which is a child of the root logger. A record goes through two separate filters:

1. The logger's level, checked once, on the logger you called. gst_log is set to DEBUG, so its debug(...) record is created. app_log.debug("cache warm") is dropped at once because billing is at INFO.
2. Each handler's own level. After the logger accepts a record, the record propagates up the tree and is offered to every handler it meets. billing.gst has no handlers of its own ([]), so the record reaches the handler attached to billing. The parent logger's level is not checked again during propagation. That is why a DEBUG record from billing.gst is printed even though billing is at INFO.

Once the handler is raised to WARNING, the INFO record about INV-205 is created by the logger but rejected by the handler; the warning gets through. billing.upi has no level set (NOTSET), so its effective level is inherited from the nearest ancestor that has one: billing's INFO, which is 20.

Takeaway: logger level decides whether a record is created; handler level decides where it is written. Attach handlers high up the tree (usually only on the root, in the application's entry point) and set levels on loggers.

Follow-ups:

1. "In a library you ship to other teams, should you call logging.basicConfig() or add a handler?" No. A library does logger = logging.getLogger(__name__) and only logs. The application decides handlers, format and levels, usually once at start-up with basicConfig or dictConfig. A library that adds its own handler causes duplicated lines and ignores the app's settings.
2. "If you also called logging.basicConfig(level=logging.INFO) at the top, what would change?" The root logger gets a stderr handler as well. Every record that reaches billing's handler keeps propagating to root and is printed a second time, on stderr. Fix: attach handlers in one place only, or set app_log.propagate = False.
3. "Why write log.info("order %s", order_id) instead of an f-string?" With %s arguments, the message is only formatted if a handler will actually emit the record, so suppressed debug logs cost almost nothing. Log aggregators can also group records by the constant template. An f-string is formatted every time, before logging even looks at the level.

Scoring: Strong: All six lines, and explains the two filters (logger level once, then handler level) and propagation to the parent's handler. Acceptable: Gets the level filtering right but drops the first DEBUG line or the effective level 20; corrects it after a hint about where the handler lives. Red flag: Thinks setLevel on a logger also filters its children's records during propagation, or can't say what a handler is.

JR-M-O02 · loc vs iloc after filtering an orders DataFrame

Medium · Output · Junior (1–3 years) · pandas, indexing, loc, iloc, boolean filtering, reset_index · 6 min

Question: What does this print on pandas 2.2?

import pandas as pd

orders = pd.DataFrame({
    "order_id": ["A1", "A2", "A3", "A4", "A5"],
    "city": ["Pune", "Delhi", "Pune", "Chennai", "Pune"],
    "amount": [450, 1200, 300, 800, 950],
})

pune = orders[orders["city"] == "Pune"]
print(pune.index.tolist())
print(pune.iloc[1]["order_id"], pune.loc[2, "order_id"])
print(orders.loc[1:3, "order_id"].tolist(), orders.iloc[1:3]["order_id"].tolist())

top = pune.sort_values("amount", ascending=False)
print(top.iloc[0]["order_id"], top.loc[0, "order_id"])

clean = pune.reset_index(drop=True)
print(clean.index.tolist(), clean.loc[1, "order_id"])
print(pune.loc[1, "order_id"])

Expected output:

[0, 2, 4]
A3 A3
['A2', 'A3', 'A4'] ['A2', 'A3']
A5 A1
[0, 1, 2] A3
KeyError: 1

Explanation:

A DataFrame row has two "addresses": its label in the index and its position. .loc uses labels; .iloc uses positions.

• Boolean filtering keeps the original labels, so pune has index [0, 2, 4]. Position 1 in pune is the row labelled 2, which is why iloc[1] and loc[2] both give A3.
• Label slices with .loc include the end label (1:3 gives labels 1, 2, 3), while position slices with .iloc exclude the end, like Python lists.
• Sorting moves rows but keeps their labels. After sorting by amount, the first position is A5 (₹950), but the label 0 still belongs to A1.
• reset_index(drop=True) renumbers labels 0..n-1 and throws the old index away. That changes clean, not pune: pune still has no label 1, so pune.loc[1, ...] raises KeyError: 1.

Takeaway: after filtering or sorting, use .iloc for "the first row" and .loc for "the row with this label"; call reset_index(drop=True) when the old labels have no meaning.

Follow-ups:

1. "What does pune["order_id"][1] do?" On a Series with an integer index, [] is a label lookup, so it raises KeyError: 1 here. On a string index, s[1] falls back to position, and pandas 2.2 warns that this fallback is deprecated. Because [] means different things depending on the index, be explicit with .loc or .iloc.
2. "Why does reset_index() without drop=True surprise people?" It moves the old index into a new column called index. If you then write the DataFrame to CSV or a table, you get an extra meaningless column.
3. "How do you get the order with the highest amount in one call?" orders.loc[orders["amount"].idxmax()]: idxmax returns the label of the maximum, so it pairs with .loc. Or orders.nlargest(1, "amount").

Scoring: Strong: All six lines, including the inclusive loc slice and KeyError: 1, and states the label-vs-position rule. Acceptable: One slip (usually the inclusive slice or top.loc[0]), fixed after re-reading which accessor is used. Red flag: Thinks filtering renumbers the index, or treats loc and iloc as interchangeable.

JR-M-O03 · Which day does a midnight order belong to in IST?

Medium · Output · Junior (1–3 years) · datetime, time zones, IST, aware datetimes, astimezone, reporting · 6 min

Question: Orders arrive from two systems: the payments service sends UTC timestamps, the mobile app sends IST. Finance wants totals per IST calendar day (31 March is also the last day of the Indian financial year). What does this print?

from datetime import datetime, timedelta, timezone

IST = timezone(timedelta(hours=5, minutes=30), "IST")

orders = [
    ("ORD-1", "2026-03-31T17:45:00+00:00", 1200),   # from the payments service (UTC)
    ("ORD-2", "2026-03-31T19:10:00+00:00", 800),
    ("ORD-3", "2026-04-01T00:40:00+05:30", 450),    # from the mobile app (IST)
]

for order_id, ts, amount in orders:
    placed = datetime.fromisoformat(ts)
    local = placed.astimezone(IST)
    print(order_id, placed.date(), local.date(), local.strftime("%H:%M %Z"))

by_ist_day: dict[str, int] = {}
for order_id, ts, amount in orders:
    day = datetime.fromisoformat(ts).astimezone(IST).date().isoformat()
    by_ist_day[day] = by_ist_day.get(day, 0) + amount
print(by_ist_day)

a = datetime.fromisoformat(orders[1][1])
b = datetime.fromisoformat(orders[2][1])
print(a == b, a.isoformat() == b.isoformat(), b - a)
print(b.astimezone(timezone.utc).isoformat())
print(b.replace(tzinfo=timezone.utc).isoformat(), b.replace(tzinfo=timezone.utc) - b)

Expected output:

ORD-1 2026-03-31 2026-03-31 23:15 IST
ORD-2 2026-03-31 2026-04-01 00:40 IST
ORD-3 2026-04-01 2026-04-01 00:40 IST
{'2026-03-31': 1200, '2026-04-01': 1250}
True False 0:00:00
2026-03-31T19:10:00+00:00
2026-04-01T00:40:00+00:00 5:30:00

Explanation:

Each ISO string carries an offset, so fromisoformat returns an aware datetime: a precise instant plus the offset it was written in.

• .date() returns the calendar date in the datetime's own offset. For ORD-2 that is the UTC date, 31 March, but in India it is already 00:40 on 1 April. Grouping by placed.date() would put ORD-2 in the wrong day and in the wrong financial year.
• astimezone(IST) converts: same instant, different wall-clock reading. Converting everything to one zone first, then taking .date(), gives the correct per-day totals: 800 + 450 = 1250 on 1 April.
• Aware datetimes compare and subtract by instant, so ORD-2 (19:10 UTC) and ORD-3 (00:40 IST) are equal and 0 seconds apart, even though their ISO strings differ. That's why comparing timestamp strings from different systems is unreliable.
• replace(tzinfo=...) does not convert; it keeps the wall-clock time and just swaps the label. b.replace(tzinfo=timezone.utc) claims 00:40 UTC, a different instant 5 h 30 min later. Use astimezone to convert and replace only to label a naive value whose zone you know.

Takeaway: store and compare instants in UTC, convert to the business time zone (astimezone) right before you take .date() or format for people.

Follow-ups:

1. "Why did we build IST with a fixed offset? When would you use zoneinfo.ZoneInfo("Asia/Kolkata") instead?" India has no daylight saving, so a fixed +05:30 is correct for IST. For zones with DST (Europe, US) a fixed offset is wrong for half the year; use ZoneInfo, which knows the rules (it needs the system tz database or the tzdata package).
2. "What happens if one system sends "2026-03-31 19:10:00" without an offset?" fromisoformat returns a naive datetime. Comparing or subtracting naive and aware values raises TypeError, and astimezone on a naive value assumes the server's local zone, which differs between a laptop and a UTC container. Decide the zone at the boundary and attach it explicitly.
3. "In pandas, how would you get IST dates from a column of UTC strings?" pd.to_datetime(s, utc=True).dt.tz_convert("Asia/Kolkata").dt.date (or .dt.normalize() to keep a datetime). tz_localize is the pandas equivalent of replace: it labels naive values, it doesn't convert.

Scoring: Strong: All seven lines; explains convert-then-take-date, instant-based equality, and replace vs astimezone. Acceptable: Gets the IST dates right but expects a == b to be False or thinks replace converts; corrects it once asked whether the two values are the same instant. Red flag: Groups by .date() of the raw timestamps without converting, or treats ISO strings as safely comparable across offsets.

JR-M-O04 · Status codes from a FastAPI customer endpoint

Medium · Output · Junior (1–3 years) · FastAPI, Pydantic, request validation, HTTP status codes, CRUD · 7 min

Question: What does this print? TestClient sends real HTTP requests to the app in memory, so you see what an API client would see. (It may print a deprecation warning on stderr; ignore that, only stdout is shown.)

from fastapi import FastAPI, HTTPException
from fastapi.testclient import TestClient
from pydantic import BaseModel, Field

app = FastAPI()
customers: dict[int, dict] = {}


class CustomerIn(BaseModel):
    name: str = Field(min_length=1)
    phone: str = Field(pattern=r"^[6-9]\d{9}$")
    city: str = "Bengaluru"


@app.post("/customers", status_code=201)
def create_customer(body: CustomerIn):
    new_id = len(customers) + 1
    customers[new_id] = body.model_dump()
    return {"id": new_id, **customers[new_id]}


@app.get("/customers/{customer_id}")
def get_customer(customer_id: int):
    if customer_id not in customers:
        raise HTTPException(status_code=404, detail="customer not found")
    return customers[customer_id]


client = TestClient(app)

r = client.post("/customers", json={"name": "Asha Rao", "phone": "9876543210"})
print(r.status_code, r.json())

r = client.post("/customers", json={"name": "Vikram", "phone": "12345"})
print(r.status_code, [e["loc"] for e in r.json()["detail"]])

r = client.post("/customers", json={"phone": "9123456789", "city": 560001})
print(r.status_code, [(e["loc"], e["type"]) for e in r.json()["detail"]])

print(client.get("/customers/1").json()["city"])
r = client.get("/customers/2")
print(r.status_code, r.json())
r = client.get("/customers/abc")
print(r.status_code, r.json()["detail"][0]["type"])

Expected output:

201 {'id': 1, 'name': 'Asha Rao', 'phone': '9876543210', 'city': 'Bengaluru'}
422 [['body', 'phone']]
422 [(['body', 'name'], 'missing'), (['body', 'city'], 'string_type')]
Bengaluru
404 {'detail': 'customer not found'}
422 int_parsing

Explanation:

FastAPI validates the request before your function runs, using the type hints:

• A parameter typed as a Pydantic model (body: CustomerIn) is read from the JSON body. If validation fails, FastAPI returns 422 Unprocessable Content with a detail list, one entry per problem. Each loc says where the problem is (body → field), and type is a stable error code you can test against.
• Pydantic reports all errors at once: the third request is missing name and has a bad city. In Pydantic v2's default (lax) mode, an integer is not converted to a str field, so 560001 gives string_type. (The reverse, "42" to an int field, is allowed.)
• The city default fills in when the field is omitted.
• status_code=201 on the decorator sets the success code for creation; HTTPException(404) turns into a JSON body {"detail": ...}.
• A path parameter typed int is validated too: /customers/abc never reaches get_customer; FastAPI returns 422 with type int_parsing.

Takeaway: 422 means "your request didn't match the schema", 404 means "valid request, no such resource". Declare types and constraints and let the framework reject bad input before your code runs.

Follow-ups:

1. "The ID is len(customers) + 1. What goes wrong once you add DELETE?" After deleting customer 1 of 2, len is 1, so the next create reuses ID 2 and overwrites an existing customer. Use a counter that only increases (or let the database assign IDs). With several worker processes, an in-memory dict also isn't shared between workers.
2. "Should a duplicate phone number return 422, 409 or 400?" 409 Conflict is the usual choice: the request is well-formed but clashes with existing state. 422 is for schema/validation errors. Be consistent and document it.
3. "How do you stop the API from returning a field like password_hash?" Declare a separate output model and set response_model=CustomerOut (or a return type annotation). FastAPI filters the response to that model's fields. Never return the stored dict directly.

Scoring: Strong: All six lines, including both errors on the third request and the 422 for /customers/abc; can explain 201 vs 404 vs 422. Acceptable: Gets the status codes right but expects Pydantic to stop at the first error or to turn 560001 into "560001". Red flag: Expects the bad phone to reach the function and fail there, or says invalid input should return 500.

JR-M-O05 · An event-handler registry and a decorator that forgets to return

Medium · Output · Junior (1–3 years) · decorators, decorator factories, registration pattern, import time · 6 min

Question: What does this print?

HANDLERS = {}


def on_event(name):
    print(f"factory called for {name}")

    def register(func):
        print(f"registering {name}")
        HANDLERS[name] = func
        return func

    return register


def audit(func):
    print(f"auditing {func.__name__}")

    def wrapper(*args):
        print(f"audit: {func.__name__}{args}")
        return func(*args)


@on_event("order.paid")
def send_receipt(order_id):
    return f"receipt for {order_id}"


@on_event("order.refunded")
@audit
def reverse_ledger(order_id):
    return f"ledger reversed for {order_id}"


print("--- app ready")
print(sorted(HANDLERS))
print(HANDLERS["order.paid"]("ORD-11"), send_receipt is HANDLERS["order.paid"])
print(reverse_ledger, HANDLERS["order.refunded"])
print(HANDLERS["order.refunded"]("ORD-12"))

Expected output:

factory called for order.paid
registering order.paid
factory called for order.refunded
auditing reverse_ledger
registering order.refunded
--- app ready
['order.paid', 'order.refunded']
receipt for ORD-11 True
None None
TypeError: 'NoneType' object is not callable

Explanation:

A decorator is just a function call that happens when the def runs, which for module-level code means at import time. @d above def f means f = d(f).

• @on_event("order.paid") first calls the factory on_event("order.paid"), which returns register; then register(send_receipt) runs, stores the function in HANDLERS and returns it unchanged. So send_receipt is HANDLERS["order.paid"] is True. This is how Flask/FastAPI routes, pytest fixtures and Celery tasks get registered.
• With two decorators, Python evaluates the decorator expressions top to bottom (so the factory prints first), then applies them bottom to top: reverse_ledger = on_event("order.refunded")(audit(reverse_ledger)).
• audit builds wrapper but never returns it, so audit(...) returns None. register then stores None in the registry, and the module-level name reverse_ledger becomes None too. Nothing fails at import time; the bug only shows up when an event fires and None("ORD-12") raises TypeError.

Takeaway: decorators run once at definition time and must return a callable; a missing return wrapper silently replaces your function with None.

Follow-ups:

1. "Fix audit properly." Add return wrapper at the end, decorate wrapper with @functools.wraps(func) so it keeps the name and docstring, and accept *args, **kwargs so keyword calls work too.
2. "With audit fixed, swap the order: @audit on top, @on_event(...) below it. What gets registered, and is auditing applied when the handler runs from HANDLERS?" on_event runs first and registers the original, undecorated function. audit wraps what register returned, so only the module-level name is audited; calls made through HANDLERS skip the audit. Order matters for registration decorators.
3. "A handler module is never imported. What happens to its handlers?" They are never registered, because registration happens when the module's code runs. Frameworks solve this with explicit imports, entry points or auto-discovery.

Scoring: Strong: Exact output, including the order of the first five lines and the final TypeError; explains f = d(f) and the top-down evaluate / bottom-up apply rule. Acceptable: Spots the missing return but gets the import-time print order wrong. Red flag: Thinks decorators run when the function is called, or can't explain why reverse_ledger is None.

JR-M-O06 · What happens when a package is imported

Medium · Output · Junior (1–3 years) · imports, packages, sys.modules, __name__, main guard, from-import binding · 7 min

Question: What does this print? The first block writes a small package to disk (shop/__init__.py, shop/tax.py, shop/cli.py) next to the script, exactly as if it were part of your repo.

import importlib
import pathlib
import sys

# Build a tiny package on disk next to this script:
#   shop/__init__.py, shop/tax.py, shop/cli.py
pkg = pathlib.Path("shop")
pkg.mkdir(exist_ok=True)
(pkg / "__init__.py").write_text('print("init shop")\n')
(pkg / "tax.py").write_text(
    'print(f"loading tax as {__name__}")\n'
    "GST_RATE = 0.18\n"
    "def with_gst(amount):\n"
    "    return round(amount * (1 + GST_RATE), 2)\n"
    'if __name__ == "__main__":\n'
    '    print("self-test", with_gst(100))\n'
)
(pkg / "cli.py").write_text(
    "from .tax import with_gst\n"
    'print(f"loading cli as {__name__}")\n'
)
importlib.invalidate_caches()  # we just created files; tell the import system

import shop.tax
import shop.cli
from shop import tax as tax_again
from shop.tax import GST_RATE

print(shop.tax.with_gst(1000), tax_again is shop.tax)
shop.tax.GST_RATE = 0.05
print(shop.tax.with_gst(1000), GST_RATE)
print("shop.cli" in sys.modules, __name__)

Expected output:

init shop
loading tax as shop.tax
loading cli as shop.cli
1180.0 True
1050.0 0.18
True __main__

Explanation:

Importing a module runs its top-level code once and caches the module object in sys.modules. Every later import of the same name just looks it up there.

• import shop.tax first imports the package shop (running __init__.py, which prints init shop), then runs tax.py. Inside an imported module, __name__ is its dotted name, "shop.tax", so the if __name__ == "__main__": self-test does not run.
• shop/cli.py does from .tax import with_gst. shop.tax is already in sys.modules, so tax.py is not run again: there is no second "loading tax" line. from shop import tax as tax_again also returns the same cached object (True).
• from shop.tax import GST_RATE copies the current value into a new name in this script. Reassigning shop.tax.GST_RATE = 0.05 later changes the module's attribute (so with_gst, which reads its own module's global, now gives 1050.0) but not our separate name GST_RATE, which still holds 0.18.
• The script being run directly always has __name__ == "__main__".

Takeaway: module code runs once per process; if __name__ == "__main__": keeps script-only code from running on import; from x import name copies a binding, import x + x.name always sees the current value.

Follow-ups:

1. "Why is python shop/cli.py likely to fail, while python -m shop.cli works?" Run as a file, cli.py is __main__ with no parent package, so the relative import from .tax raises ImportError: attempted relative import with no known parent package. -m shop.cli imports it as part of the shop package from the current directory, so relative imports resolve.
2. "You pip install -e . your project and import shop still loads an old copy. How do you check which file was imported?" print(shop.__file__) or python -c "import shop; print(shop.__file__)" and check sys.path. Usually it is the wrong virtual environment (which python, python -m pip) or a stray shop.py / old install shadowing it.
3. "Why is printing or connecting to a database at import time a bad idea in a real package?" It runs for every importer, including tests and tools that only need one helper, slows start-up and can fail in CI with no network. Put side effects in functions or a main() called from the __main__ guard.

Scoring: Strong: All six lines; explains sys.modules caching, __name__ for imported vs run modules, and why GST_RATE stays 0.18. Acceptable: Gets the import lines right but expects GST_RATE to change, or prints "loading tax" twice; fixes it after a hint about caching. Red flag: Thinks the __main__ block runs on import, or that every import statement re-executes the file.

JR-M-C01 · Check installed packages against requirements.txt pins

Medium · Coding · Junior (1–3 years) · packaging, virtual environments, requirements.txt, string parsing, regex, PEP 503 names · 20 min

Problem:

"It works on my machine" bugs often come from a virtual environment that has drifted from requirements.txt. Write check_pins(requirements, installed) for a CI step. requirements is the text of a requirements file; installed maps package names to installed versions (as importlib.metadata would report them). Return a dict with three sorted lists:

• missing: required packages that aren't installed;
• mismatched: packages pinned with exactly one == whose installed version differs, formatted "<name>: want <pinned>, have <installed>";
• unpinned: installed packages whose requirement is not a single == pin (>=, ranges, or no version).

Parsing rules:

• Ignore blank lines, comment lines, trailing comments (# ...) and option lines starting with - (such as -r other.txt or --index-url ...).
• Ignore extras (uvicorn[standard]) and environment markers (; python_version >= "3.8").
• Package names are compared the way pip does (PEP 503): case-insensitive, and runs of -, _ and . are equivalent, so Zope_Interface, zope.interface and zope-interface are the same package. Report names in this normalised form.
• A line that isn't a requirement raises ValueError containing the line.

Also expose normalize(name).

Signature: def normalize(name: str) -> str: def check_pins(requirements: str, installed: dict[str, str]) -> dict[str, list[str]]:

Constraints: Standard library only. Versions are compared as exact strings (no version ordering needed).

Examples:

• 'pydantic_core == 2.27.1 # transitive' with installed {'pydantic-core': '2.27.1'} → nothing reported
• 'uvicorn[standard]==0.30.6' with installed {'Uvicorn': '0.30.1'} → mismatched: ['uvicorn: want 0.30.6, have 0.30.1']
• 'Requests>=2.31' with installed {'requests': '2.32.3'} → unpinned: ['requests']
• 'numpy==2.1.3' with numpy not installed → missing: ['numpy']

Hints:

1. Normalise names on both sides before comparing; build a normalised view of installed once.
2. Strip things in a fixed order: comment, then marker, then split name / extras / version spec. A regex with groups for name, optional [extras] and the rest keeps it readable.
3. pandas>=2.0,==2.2.3 contains == but is a range, not a pin.

Reference solution:

import re

_SEPARATORS = re.compile(r"[-_.]+")
_REQUIREMENT = re.compile(r"^([A-Za-z0-9][A-Za-z0-9._-]*)\s*(\[[^\]]*\])?\s*(.*)$")


def normalize(name: str) -> str:
    """PEP 503 name normalisation: case-insensitive, runs of - _ . are equivalent."""
    return _SEPARATORS.sub("-", name).lower()


def check_pins(requirements: str, installed: dict[str, str]) -> dict[str, list[str]]:
    """Compare a requirements.txt against installed versions."""
    have = {normalize(name): version for name, version in installed.items()}
    report: dict[str, list[str]] = {"missing": [], "mismatched": [], "unpinned": []}
    for raw in requirements.splitlines():
        line = raw.split(" #", 1)[0].strip()
        if not line or line.startswith(("#", "-")):
            continue
        line = line.split(";", 1)[0].strip()          # drop environment markers
        match = _REQUIREMENT.match(line)
        if match is None:
            raise ValueError(f"cannot parse requirement: {raw!r}")
        name, _extras, spec = match.groups()
        key = normalize(name)
        spec = spec.replace(" ", "")
        if key not in have:
            report["missing"].append(key)
        elif spec.startswith("==") and "," not in spec:
            if have[key] != spec[2:]:
                report["mismatched"].append(f"{key}: want {spec[2:]}, have {have[key]}")
        else:
            report["unpinned"].append(key)
    return {kind: sorted(items) for kind, items in report.items()}

Complexity: O(total length of the requirements text + number of installed packages). Memory O(number of packages).

Tests:

REQS = """
# web
fastapi==0.115.0
pydantic_core == 2.27.1   # transitive pin, written with an underscore
uvicorn[standard]==0.30.6
Requests>=2.31
python-dateutil==2.9.0.post0 ; python_version >= "3.8"
-r dev-requirements.txt
--index-url https://pypi.example.in/simple

numpy==2.1.3
zope.interface==7.0
httpx
"""

installed = {
    "FastAPI": "0.115.0",
    "pydantic-core": "2.27.1",
    "Uvicorn": "0.30.1",
    "requests": "2.32.3",
    "python_dateutil": "2.9.0.post0",
    "Zope_Interface": "7.0",
    "httpx": "0.28.1",
}

assert check_pins(REQS, installed) == {
    "missing": ["numpy"],
    "mismatched": ["uvicorn: want 0.30.6, have 0.30.1"],
    "unpinned": ["httpx", "requests"],
}

# name normalisation follows PEP 503
assert normalize("Zope_Interface") == normalize("zope.interface") == "zope-interface"
assert normalize("Pydantic__Core") == "pydantic-core"

# a range is not a pin, even if it includes ==
assert check_pins("pandas>=2.0,==2.2.3", {"pandas": "2.2.3"})["unpinned"] == ["pandas"]

# empty input, comments only
assert check_pins("", {}) == {"missing": [], "mismatched": [], "unpinned": []}
assert check_pins("# nothing\n\n   \n", {"x": "1"}) == {"missing": [], "mismatched": [], "unpinned": []}

# a line that isn't a requirement must fail loudly, not be skipped
try:
    check_pins("==1.0", {})
    raise AssertionError("expected ValueError")
except ValueError as exc:
    assert "==1.0" in str(exc)

A common wrong solution (the tests catch it):

def check_pins(requirements, installed):
    report = {"missing": [], "mismatched": [], "unpinned": []}
    for raw in requirements.splitlines():
        line = raw.split("#", 1)[0].strip()
        if not line or line.startswith("-"):
            continue
        if "==" in line:
            name, version = line.split("==", 1)
            name = name.split("[", 1)[0].strip().lower()
            version = version.split(";", 1)[0].strip()
            if name not in installed:
                report["missing"].append(name)
            elif installed[name] != version:
                report["mismatched"].append(f"{name}: want {version}, have {installed[name]}")
        else:
            name = line.split(">", 1)[0].split("<", 1)[0].split("[", 1)[0].strip().lower()
            if name not in installed:
                report["missing"].append(name)
            else:
                report["unpinned"].append(name)
    return {k: sorted(v) for k, v in report.items()}

Alternatives and tradeoffs:

• Use the real parser: packaging.requirements.Requirement(line) handles every PEP 508 detail (extras, markers, URLs), and packaging.utils.canonicalize_name does PEP 503 normalisation. In production prefer it over a hand-written regex; it isn't in the standard library, but pip vendors it and most environments have it.
• Get installed versions with {d.metadata["Name"]: d.version for d in importlib.metadata.distributions()}, or pip freeze / pip list --format=json in a subprocess.
• Avoid drift instead of detecting it: lock files (pip-tools, uv lock, Poetry) and pip install --require-hashes, and rebuild the venv in CI from the lock file every time.

Follow-ups:

1. "Why does pip treat pydantic_core and Pydantic-Core as the same package?" PEP 503 defines a normalised name (lowercase, runs of -_. become -) used by package indexes and installers, so different spellings in different files can't install two copies or fail to match. Any tool comparing names must normalise the same way.
2. "Should a library's pyproject.toml pin exact versions like an application's requirements file?" No. A library declares compatible ranges (pandas>=2.0,<3) so it can be installed alongside other packages; an application pins exact versions (usually in a lock file) so every deploy is reproducible.
3. "The CI check passes, but production still behaves differently. What else can differ?" The Python version, OS-level libraries (e.g. different wheels for Linux/macOS), packages installed outside the requirements file, environment variables, and transitive dependencies that weren't pinned at all. A lock file with hashes and a container image built once and promoted across environments close most of these gaps.

Scoring: Strong: Clean parsing in a fixed order, PEP 503 normalisation on both sides, correct handling of extras, markers, trailing comments, option lines and ranges; mentions packaging and lock files as the production answer. Acceptable: Works for the simple cases; needs a hint for name normalisation or for == inside a range. Red flag: Splits on == and compares raw names, or doesn't know why a venv and pinned requirements matter.

JR-M-C02 · A context manager that writes a report file atomically

Medium · Coding · Junior (1–3 years) · context managers, contextlib, files, exceptions, tempfile, os.replace · 15 min

Problem:

A nightly job writes gst_report.csv, which the finance team's tool picks up. If the job crashes half-way (a query times out, the pod is killed), today's code leaves a half-written file and finance files GST on partial data.

Write a context manager atomic_write(path) that yields a text file object. Readers of path must only ever see either the old complete file or the new complete file:

• On a clean exit, the new content replaces path (creating it if it didn't exist).
• If the with body raises, path is left exactly as it was (or still doesn't exist), no temporary file is left behind, and the exception propagates unchanged.
• Text is written as UTF-8 by default.

Signature: def atomic_write(path: str | os.PathLike[str], encoding: str = "utf-8") -> Iterator[TextIO]:

Constraints: Standard library only. path may be a str or a Path. Use as with atomic_write(p) as f: f.write(...). Writing it with @contextlib.contextmanager (hence the Iterator[TextIO] return type) or as a class are both fine.

Examples:

• with atomic_write("r.csv") as f: f.write("a,b\n") → r.csv contains 'a,b\n'
• with atomic_write("r.csv") as f: f.write("x"); raise RuntimeError("timeout") → RuntimeError propagates; r.csv still has its old content; no temp file in the folder

Hints:

1. Write somewhere else first. Where must that "somewhere else" be for a rename to be atomic?
2. os.replace(src, dst) renames over an existing file in one step on the same filesystem.
3. With @contextmanager, code after yield doesn't run if the body raises unless you use try. What must happen in each case?

Reference solution:

import os
import tempfile
from collections.abc import Iterator
from contextlib import contextmanager
from pathlib import Path
from typing import TextIO


@contextmanager
def atomic_write(path: str | os.PathLike[str], encoding: str = "utf-8") -> Iterator[TextIO]:
    """Write text to `path` so readers see either the old file or the complete new one."""
    target = Path(path)
    fd, tmp_name = tempfile.mkstemp(dir=target.parent, prefix=f".{target.name}.", suffix=".tmp")
    try:
        with os.fdopen(fd, "w", encoding=encoding) as f:
            yield f
        os.replace(tmp_name, target)
    except BaseException:
        Path(tmp_name).unlink(missing_ok=True)
        raise

Complexity: O(size of the content) time; O(1) extra memory (data streams to the temporary file). Needs disk space for one extra copy while writing.

Tests:

import os
import tempfile
from pathlib import Path

with tempfile.TemporaryDirectory() as d:
    report = Path(d) / "gst_report.csv"

    # creates a new file
    with atomic_write(report) as f:
        f.write("invoice,gst\nINV-1,180\n")
    assert report.read_text() == "invoice,gst\nINV-1,180\n"

    # replaces an existing file
    with atomic_write(str(report)) as f:
        f.write("invoice,gst\nINV-2,90\n")
    assert report.read_text() == "invoice,gst\nINV-2,90\n"

    # a failure half-way leaves the old content untouched and re-raises
    try:
        with atomic_write(report) as f:
            f.write("invoice,gst\n")
            raise RuntimeError("export query timed out")
    except RuntimeError as exc:
        assert str(exc) == "export query timed out"
    else:
        raise AssertionError("exception was swallowed")
    assert report.read_text() == "invoice,gst\nINV-2,90\n"

    # a failure when the file didn't exist yet leaves no file behind
    fresh = Path(d) / "new.csv"
    try:
        with atomic_write(fresh) as f:
            f.write("partial")
            raise ValueError("bad row")
    except ValueError:
        pass
    assert not fresh.exists()

    # no temporary files are left lying around
    assert sorted(p.name for p in Path(d).iterdir()) == ["gst_report.csv"]

    # non-ASCII text round-trips with the default encoding
    with atomic_write(report) as f:
        f.write("total,₹1,180\n")
    assert report.read_text(encoding="utf-8") == "total,₹1,180\n"

A common wrong solution (the tests catch it):

from contextlib import contextmanager


@contextmanager
def atomic_write(path, encoding="utf-8"):
    with open(path, "w", encoding=encoding) as f:
        yield f

Alternatives and tradeoffs:

• Class-based manager with __enter__/__exit__: same logic; __exit__ checks exc_type to decide between replace and cleanup, and returns False so exceptions propagate.
• Build the content in memory, then write once: shrinks the window but isn't atomic; a crash during the write still leaves a partial file.
• Write to report.csv.tmp with a fixed name: two concurrent jobs would clobber each other's temp file; tempfile.mkstemp gives a unique name.
• For durability across a power cut, also f.flush(); os.fsync(f.fileno()) before the replace, and fsync the directory.

Follow-ups:

1. "Why must the temporary file be in the same directory as the target, not in /tmp?" os.replace is only atomic within one filesystem. /tmp is often a different filesystem (tmpfs), and then the rename fails with OSError (cross-device link) instead of being atomic.
2. "mkstemp creates the file with permissions 0600. Why might the finance tool suddenly be unable to read the report?" The replaced file keeps the temporary file's permissions, so it is readable only by the job's user. Copy the old file's mode (os.chmod(tmp, os.stat(path).st_mode)) or set the intended mode explicitly before replacing.
3. "How would you test the 'crash half-way' case in pytest?" Use the tmp_path fixture, write an initial file, then with pytest.raises(RuntimeError): with atomic_write(p) as f: f.write(...); raise RuntimeError(...), and assert the old content and that list(tmp_path.iterdir()) has only the report.

Scoring: Strong: Temp file in the same directory, os.replace only on success, cleanup plus re-raise on failure (try/except BaseException or finally), and can explain why the rename is atomic. Acceptable: Correct happy path and cleanup, but uses a fixed temp name or /tmp; fixes it after the cross-device or concurrency question. Red flag: Opens the target directly with 'w' (which truncates it immediately), or swallows the exception so the job reports success.

JR-M-C03 · Point-in-time customer features with pandas

Medium · Coding · Junior (1–3 years) · pandas, groupby, feature engineering, dates, data leakage, reindex · 20 min

Problem:

For a churn model, build one row of features per customer as of a given date. orders has columns customer_id, order_date (ISO date strings), amount (₹, float) and status ("delivered" or "cancelled").

Using only orders placed strictly before as_of and not cancelled, compute per customer:

• n_orders: number of orders (int)
• total_spend: sum of amount (float)
• avg_order_value: mean amount, rounded to 2 decimals
• days_since_last_order: whole days from the latest order to as_of

Every customer that appears anywhere in orders must be in the result (index customer_id, sorted). A customer with no eligible orders gets n_orders = 0, total_spend = 0.0 and NaN for the other two. Don't modify orders.

Signature: def customer_features(orders: pd.DataFrame, as_of: str) -> pd.DataFrame:

Constraints: pandas 2.2. Columns in this order: n_orders, total_spend, avg_order_value, days_since_last_order.

Examples:

• C1 orders: 2026-01-10 ₹450, 2026-02-01 ₹300, 2026-03-05 ₹5000; as_of='2026-03-01' → C1 → n_orders 2, total_spend 750.0, avg_order_value 375.0, days_since_last_order 28
• C3 has only a cancelled order → C3 → 0, 0.0, NaN, NaN

Hints:

1. Filter first (date and status), then group. Which rows must never be seen when you train on data 'as of 1 March'?
2. groupby(...).size(), .sum(), .mean() and .max() each give a Series indexed by customer; a dict of them makes a DataFrame.
3. Customers who disappear after filtering can be brought back with reindex; then decide what each missing value should be.

Reference solution:

import pandas as pd


def customer_features(orders: pd.DataFrame, as_of: str) -> pd.DataFrame:
    """Per-customer features using only orders placed before `as_of` and not cancelled."""
    cutoff = pd.Timestamp(as_of)
    dates = pd.to_datetime(orders["order_date"])
    eligible = orders[(dates < cutoff) & (orders["status"] != "cancelled")].assign(
        order_date=dates
    )
    grouped = eligible.groupby("customer_id")
    features = pd.DataFrame({
        "n_orders": grouped.size(),
        "total_spend": grouped["amount"].sum(),
        "avg_order_value": grouped["amount"].mean().round(2),
        "days_since_last_order": (cutoff - grouped["order_date"].max()).dt.days,
    })
    all_customers = pd.Index(sorted(orders["customer_id"].unique()), name="customer_id")
    features = features.reindex(all_customers)
    features["n_orders"] = features["n_orders"].fillna(0).astype("int64")
    features["total_spend"] = features["total_spend"].fillna(0.0).astype("float64")
    return features

Complexity: O(n) to filter and O(n) hash-based groupby (plus sorting the customer ids). Memory O(n) for the filtered copy.

Tests:

import math

import pandas as pd

orders = pd.DataFrame({
    "customer_id": ["C2", "C1", "C1", "C2", "C3", "C1", "C4"],
    "order_date": ["2026-01-05", "2026-01-10", "2026-02-01", "2026-02-20",
                   "2026-01-15", "2026-03-05", "2026-03-02"],
    "amount": [1200.0, 450.0, 300.0, 800.0, 999.0, 5000.0, 150.0],
    "status": ["delivered", "delivered", "delivered", "delivered",
               "cancelled", "delivered", "delivered"],
})
original = orders.copy()

f = customer_features(orders, "2026-03-01")

assert list(f.index) == ["C1", "C2", "C3", "C4"]
assert f.index.name == "customer_id"
assert list(f.columns) == ["n_orders", "total_spend", "avg_order_value", "days_since_last_order"]

# C1: the 2026-03-05 order is after as_of and must not leak into the features
assert f.loc["C1", "n_orders"] == 2
assert f.loc["C1", "total_spend"] == 750.0
assert f.loc["C1", "avg_order_value"] == 375.0
assert f.loc["C1", "days_since_last_order"] == 28

assert f.loc["C2", "n_orders"] == 2
assert f.loc["C2", "total_spend"] == 2000.0
assert f.loc["C2", "days_since_last_order"] == 9

# C3 only cancelled, C4 only ordered after as_of: still present, with zero counts
for cid in ["C3", "C4"]:
    assert f.loc[cid, "n_orders"] == 0
    assert f.loc[cid, "total_spend"] == 0.0
    assert math.isnan(f.loc[cid, "avg_order_value"])
    assert math.isnan(f.loc[cid, "days_since_last_order"])

assert f["n_orders"].dtype == "int64"

# an order ON the as_of date is excluded (strictly before)
g = customer_features(orders, "2026-02-20")
assert g.loc["C2", "n_orders"] == 1

# the input is not modified
pd.testing.assert_frame_equal(orders, original)

A common wrong solution (the tests catch it):

import pandas as pd


def customer_features(orders, as_of):
    cutoff = pd.Timestamp(as_of)
    eligible = orders[orders["status"] != "cancelled"].assign(
        order_date=pd.to_datetime(orders["order_date"])
    )
    grouped = eligible.groupby("customer_id")
    features = pd.DataFrame({
        "n_orders": grouped.size(),
        "total_spend": grouped["amount"].sum(),
        "avg_order_value": grouped["amount"].mean().round(2),
        "days_since_last_order": (cutoff - grouped["order_date"].max()).dt.days,
    })
    all_customers = pd.Index(sorted(orders["customer_id"].unique()), name="customer_id")
    features = features.reindex(all_customers)
    features["n_orders"] = features["n_orders"].fillna(0).astype("int64")
    features["total_spend"] = features["total_spend"].fillna(0.0).astype("float64")
    return features

Alternatives and tradeoffs:

• Named aggregation: eligible.groupby("customer_id").agg(n_orders=("amount", "size"), total_spend=("amount", "sum"), ...): one pass, readable; add the days column afterwards.
• SQL (WHERE order_date < :as_of AND status <> 'cancelled' GROUP BY customer_id, then a LEFT JOIN from the customer table) when the data lives in a warehouse.
• For many as_of dates (one per training example), loop over dates or use a merge-as-of style join; recomputing from scratch per date is simplest to get right.

Follow-ups:

1. "Why 'strictly before' as_of, and what goes wrong if you use all orders?" The label (did the customer churn after as_of?) is decided by what happens from as_of onwards. Using later orders leaks the answer into the features: the model looks great offline and fails in production, where future orders don't exist yet.
2. "Is NaN the right value for days_since_last_order when there is no order?" It is honest, but many models can't take NaN. Options: a large sentinel (days since signup), a separate has_ordered flag, or leave NaN for models such as gradient-boosted trees that handle missing values. Decide together with whoever trains the model, and use the same rule at inference.
3. "order_date arrives as strings like '05/01/2026' from another source. What do you check?" Parse explicitly with format="%d/%m/%Y" (or dayfirst=True). Otherwise 5 January can be read as 1 May. Assert that the parsed min/max dates are plausible.

Scoring: Strong: Filters by date and status before grouping, keeps customers with no eligible orders via reindex, gets dtypes and NaN handling right, and explains the leakage reason unprompted. Acceptable: Correct features for active customers but drops the inactive ones or forgets the date filter until asked about leakage. Red flag: Loops over rows in Python to build dicts, or uses orders after as_of without seeing a problem.

JR-MT-O01 · A discount generator built in one notebook cell and used in another

Medium & Tricky · Output · Junior (1–3 years) · generator expressions, lazy evaluation, name lookup, generator exhaustion · 6 min

Question: What does this print?

prices = [100, 250, 400]
discount = 0.10

discounted = (round(p * (1 - discount)) for p in prices)

prices = [999, 999]     # a later cell reloads prices
discount = 0.50         # ...and someone tries a festive-sale discount

print(list(discounted))
print(list(discounted))

prices = [100, 250, 400]
discount = 0.10
eager = [round(p * (1 - discount)) for p in prices]
lazy = (round(p * (1 - discount)) for p in prices)
prices.append(1000)
discount = 0.0
print(eager, list(lazy))

Expected output:

[50, 125, 200]
[]
[90, 225, 360] [100, 250, 400, 1000]

The trap: The two usual wrong answers are [90, 225, 360] ("the generator remembers the values from when it was created") and [500, 500] ("everything is lazy, so it uses the new prices too"). Each is half right. Candidates also often print the first list twice, forgetting that a generator can only be consumed once.

Explanation:

Two rules combine:

1. The first iterable of a generator expression is evaluated immediately. for p in prices calls iter(prices) when the generator is created, so the generator holds the original list object. Rebinding the name prices to a new list later has no effect on it. Mutating that same list (the append in the second part) is seen, because the generator iterates the object it captured.
2. Everything else is evaluated lazily, when items are pulled. discount inside the expression is looked up each time the generator produces a value, which only happens during list(discounted). By then discount is 0.50, so the original prices are halved: [50, 125, 200].

A generator is also single-use: the second list(discounted) finds it exhausted and returns []. The list comprehension eager is computed on the spot with discount = 0.10; lazy is computed only when printed, with discount = 0.0 and the appended 1000.

Real-world bug: in a notebook or a feature pipeline, a generator built in one place is consumed later, after a config value changed, so features are computed with the wrong threshold or rate. Nothing errors and the numbers look plausible.

Takeaway: when the values must be fixed now, build a list; when you keep a generator, pass what it needs as arguments (def apply(prices, discount): ...) so later changes to globals can't leak in.

Follow-ups:

1. "How would you make discounted freeze the 10% rate but still stay lazy?" Wrap it in a function with parameters: def discount_all(prices, rate): return (round(p * (1 - rate)) for p in prices). Arguments are bound at call time, so later changes to the global don't matter.
2. "Why does Python evaluate the first iterable eagerly?" So that errors such as iterating over None or a misspelled name surface where the generator is created, not at some distant consumer. Only the outermost for is evaluated early; nested for clauses and if filters are lazy.
3. "How can a function that receives an iterable protect itself from being given a one-shot generator?" If it needs two passes, convert once: items = list(items). Or type the parameter as Sequence instead of Iterable to say it needs something re-iterable.

Scoring: Strong: All three lines, and names both rules: the first iterable is captured at creation, other names are looked up at consumption time. Mentions exhaustion for line 2. Acceptable: Gets one of the two rules right (usually prints [90, 225, 360]), and reasons to the correct answer when asked when discount is read. Red flag: Can't explain the difference between a list comprehension and a generator expression, or expects a generator to be re-iterable.

JR-MT-O02 · Assigning a sorted or filtered Series to a DataFrame column

Medium & Tricky · Output · Junior (1–3 years) · pandas, index alignment, column assignment, sort_values, reset_index, NaN · 7 min

Question: What does this print on pandas 2.2?

import pandas as pd

df = pd.DataFrame({
    "sku": ["rice", "dal", "ghee", "atta"],
    "price": [60, 120, 550, 45],
})

df["gst"] = (df["price"] * 0.05).sort_values()
print(df["gst"].tolist())

premium = df[df["price"] > 100]
df["premium_price"] = premium["price"] * 0.9
print(df["premium_price"].tolist())

ranked = df.sort_values("price", ascending=False).reset_index(drop=True)
df["rank_label"] = ranked["sku"]
print(df[["sku", "rank_label"]].values.tolist())

df["rank_pos"] = df["price"].rank(ascending=False).astype(int)
print(df["rank_pos"].tolist(), df["premium_price"].dtype)

Expected output:

[3.0, 6.0, 27.5, 2.25]
[nan, 108.0, 495.0, nan]
[['rice', 'ghee'], ['dal', 'dal'], ['ghee', 'rice'], ['atta', 'atta']]
[3, 2, 1, 4] float64

The trap: People who think of a column as a Python list expect assignment to be positional: [2.25, 3.0, 6.0, 27.5] for the sorted GST, a length-mismatch error for premium_price, and rank_label to be "the sku ranked first, second, ..." as intended. Each guess is wrong for a different reason.

Explanation:

Two mechanisms work together:

1. Assigning a Series to a column aligns on the index labels, not on position. pandas matches each value to the row with the same label.
2. Sorting keeps labels, so (price * 0.05).sort_values() is the same label→value pairs in a different order. Assigning it puts every value back in its own row: the column looks unsorted, and is correct.
3. premium only has labels 1 and 2. Rows 0 and 3 have no matching label, so they get NaN. No error, no warning. Because NaN is a float, the column is float64.
4. reset_index(drop=True) throws the labels away. ranked is sorted by price and then relabelled 0..3, so label 0 now means "most expensive" (ghee). Alignment then pairs row 0 (rice) with ghee, row 2 (ghee) with rice: the values are silently scrambled. Only dal and atta look right, by coincidence.

The last line shows the safe way to get per-row ranks: compute them from the column itself (rank), so the labels never change.

Real-world bug: a feature column such as "rank within category" or "predicted score" is computed on a sorted or filtered copy, the index is reset "to tidy it up", and the result is assigned back. Every row gets some other row's value; the model trains on noise and nothing raises.

Takeaway: column assignment from a Series is label-aligned. Keep labels intact between the computation and the assignment, and use .to_numpy() only when you have guaranteed the order is identical.

Follow-ups:

1. "You want premium_price to be 90% of the price for items above ₹100 and the normal price otherwise. Write it without any alignment risk." df["premium_price"] = df["price"] * np.where(df["price"] > 100, 0.9, 1.0). Everything is computed from the full frame in its own row order, so there is nothing to misalign.
2. "When does df["x"] = some_series.to_numpy() help, and when is it dangerous?" It forces positional assignment. Correct only if some_series has the same length and the same row order as df. After a sort or filter it hides the very bug alignment would have shown as NaN.
3. "How would you write a quick check that a new feature column wasn't misaligned?" Spot-check a few rows by key (df.set_index("sku").loc[["ghee", "rice"]]), or recompute the feature for one key independently and compare. Keeping a stable business key as the index (set_index("sku")) also makes alignment work in your favour.

Scoring: Strong: All four lines; explains label alignment, why the sorted assignment is harmless while the reset one is not, and where the NaNs and float64 come from. Acceptable: Gets line 2 (NaN) but expects positional assignment for line 1 or 3; reasons it through once reminded that sorting keeps labels. Red flag: Expects an error or positional behaviour throughout and can't explain what the index is for.

JR-MT-O03 · Three ways to post an order to a partner API

Medium & Tricky · Output · Junior (1–3 years) · httpx, HTTP, request bodies, form encoding, JSON, double encoding · 7 min

Question: httpx.MockTransport routes requests to a local function instead of the network, so you can see exactly what the client sends. The fake partner API expects a JSON object. What does this print?

import json

import httpx


def handler(request: httpx.Request) -> httpx.Response:
    # a fake partner API: it expects a JSON object
    print(request.headers.get("content-type"))
    try:
        body = json.loads(request.content)
    except ValueError:
        print("  raw body:", request.content)
        return httpx.Response(400, json={"error": "body is not JSON"})
    if not isinstance(body, dict):
        print("  raw body:", request.content)
        return httpx.Response(422, json={"error": f"expected an object, got {type(body).__name__}"})
    return httpx.Response(201, json={"qty": body["qty"], "qty_type": type(body["qty"]).__name__})


client = httpx.Client(transport=httpx.MockTransport(handler), base_url="https://partner.example")
order = {"sku": "ghee-1l", "qty": 2, "gift": False}

for kwargs in ({"data": order}, {"json": json.dumps(order)}, {"json": order}):
    r = client.post("/orders", **kwargs)
    print("->", r.status_code, r.json())

Expected output:

application/x-www-form-urlencoded
  raw body: b'sku=ghee-1l&qty=2&gift=false'
-> 400 {'error': 'body is not JSON'}
application/json
  raw body: b'"{\\"sku\\": \\"ghee-1l\\", \\"qty\\": 2, \\"gift\\": false}"'
-> 422 {'error': 'expected an object, got str'}
application/json
-> 201 {'qty': 2, 'qty_type': 'int'}

The trap: The usual wrong answer is 201 for all three: "it's the same order dict every time". People coming from JavaScript expect data= to send JSON (axios does), and people who know data= is a form often "fix" it with json=json.dumps(order), which looks even more like JSON but isn't an object any more.

Explanation:

The keyword you pass decides how the dict becomes bytes, and the request needs both the right bytes and the right Content-Type:

1. data= sends an HTML-form body (application/x-www-form-urlencoded): sku=ghee-1l&qty=2&gift=false. Every value becomes text (the server would see qty as "2") and nesting is impossible. A JSON API can't parse it: 400.
2. json= serialises whatever you give it. json.dumps(order) is already a string, so json= encodes that string again: the body is a JSON string literal with escaped quotes, not an object. The header says JSON and the body is valid JSON, so the bug gets past the parser and is only caught by the server's shape check: 422. (Without that check the server would crash on body["qty"] with a TypeError.)
3. json=order serialises the dict once: a JSON object with Content-Type: application/json, and qty arrives as a number.

Real-world bug: an integration that works in Postman fails from Python with 400 or 422. The quickest diagnosis is to look at what was actually sent: Content-Type and the raw body. A body that starts with "{\" is the signature of double encoding.

Takeaway: for JSON APIs, pass the Python object to json= exactly once; use data= only for form endpoints.

Follow-ups:

1. "How would you see the raw request against a real API, without a mock?" Inspect r.request.headers and r.request.content on the response, or add an event hook: httpx.Client(event_hooks={"request": [log_request]}). Mask the Authorization header before logging.
2. "You must send content= yourself (for example, a pre-serialised payload you also sign). What else do you need?" Set the header explicitly: client.post(url, content=body_bytes, headers={"Content-Type": "application/json"}). And sign exactly those bytes, because re-serialising may change spacing or key order and break the signature.
3. "When is data= the right choice?" When the server expects a form: OAuth2 token endpoints (grant_type=client_credentials&...), legacy form handlers, and FastAPI endpoints declared with Form(...). File uploads use files= (multipart).

Scoring: Strong: All eight lines; explains form vs JSON encoding, recognises the double-encoded body and why it gets a 422 rather than a 400. Acceptable: Predicts the 400 for data= but expects the json.dumps version to succeed; gets it once asked what type json.dumps returns. Red flag: Believes the three calls send the same body, or can't say what Content-Type is for.

JR-MT-O04 · The last error in a UPI retry loop

Medium & Tricky · Output · Junior (1–3 years) · exceptions, except-as, scope, UnboundLocalError, retries · 6 min

Question: What does this print?

def charge(attempt):
    if attempt < 3:
        raise ConnectionError(f"UPI gateway timeout (attempt {attempt})")
    return "TXN-9001"


def pay_with_retries(max_attempts):
    err = None
    for attempt in range(1, max_attempts + 1):
        try:
            return charge(attempt)
        except ConnectionError as err:
            print(f"retrying after: {err}")
    print("giving up")
    return f"failed: {err}"


print(pay_with_retries(3))
print(pay_with_retries(2))

Expected output:

retrying after: UPI gateway timeout (attempt 1)
retrying after: UPI gateway timeout (attempt 2)
TXN-9001
retrying after: UPI gateway timeout (attempt 1)
retrying after: UPI gateway timeout (attempt 2)
giving up
UnboundLocalError: cannot access local variable 'err' where it is not associated with a value

The trap: The natural answer for the second call is failed: UPI gateway timeout (attempt 2), because "err was set to the last exception". The more careful wrong answer is failed: None, assuming except ... as err creates a separate variable that disappears and leaves the outer err = None alone.

Explanation:

Two rules combine:

1. except E as name binds an ordinary local variable in the function. There is no separate block scope in Python, so it is the same err that was initialised to None; the handler overwrites it.
2. At the end of the except block, Python deletes that name (as if del err ran). It does this so the exception, which holds its traceback and through it every local variable of the frames involved, doesn't stay alive in a reference cycle.

So after the first failed attempt, err is not "the last exception" and not None: it is unbound. The first call succeeds on attempt 3 and never reads err. The second call runs out of attempts, reaches return f"failed: {err}", and gets UnboundLocalError. The error message says local variable because err is local to pay_with_retries; it was deleted, not never assigned.

Fix: use a different name for the handler and copy it:

except ConnectionError as exc:
    last_error = exc

Real-world bug: the "keep the last error and report it after retries" pattern is common in API clients and payment integrations. It works in every test where a retry eventually succeeds, and crashes only on the path where all retries fail, which is exactly when you need the error message.

Takeaway: never reuse an outer variable's name as the except ... as target; copy the exception into a different name if you need it after the block.

Follow-ups:

1. "Rewrite the function so the caller can tell what went wrong instead of getting a string." Keep last_error = exc in the handler and after the loop raise PaymentFailed(f"gave up after {max_attempts} attempts") from last_error. The caller catches a domain exception and the original cause is in __cause__ and the traceback.
2. "Would this happen at module level too, outside a function?" Yes. At module level the name is a global and it is still deleted at the end of the handler, so a later print(err) raises NameError: name 'err' is not defined.
3. "What would a linter tell you?" A type checker such as Pyright reports err as possibly unbound at the final return. That warning is the hint: the code path where every attempt fails has no binding for err.

Scoring: Strong: Exact output; explains both that the handler rebinds the same local and that it is deleted at the end of the except block, and gives the last_error = exc fix. Acceptable: Predicts an error on the second call but can't say why, or answers failed: None and gets to the right answer after a hint about what happens to the name. Red flag: Thinks except ... as err creates a block-scoped variable like in Java/JavaScript and never considers that err might be unbound.

JR-MT-O05 · Caching stock levels as JSON

Medium & Tricky · Output · Junior (1–3 years) · json, serialization, dict keys, tuples vs lists, caching, APIs · 6 min

Question: A quick-commerce service caches store data as JSON strings (as you would in Redis) and reads it back. What does this print?

import json

stock = {101: 5, 102: 0, "103": 7}
slot = {"store": "Indiranagar", "window": (9, 12)}

cache = {}
cache["stock"] = json.dumps(stock)
cache["slot"] = json.dumps(slot)

stock_back = json.loads(cache["stock"])
slot_back = json.loads(cache["slot"])

print(stock_back)
print(101 in stock_back, stock_back.get(101, "missing"), stock_back["101"])
print(slot_back == slot, slot_back["window"])
print(slot_back["window"] == (9, 12), tuple(slot_back["window"]) == (9, 12))

print(json.loads(json.dumps({1: "a", "1": "b"})))

Expected output:

{'101': 5, '102': 0, '103': 7}
False missing 5
False [9, 12]
False True
{'1': 'b'}

The trap: The tempting answer treats json.loads(json.dumps(x)) as a perfect copy: {101: 5, 102: 0, '103': 7}, True 5 5, True (9, 12). JSON looks so much like a Python dict literal that it's easy to forget it has fewer types.

Explanation:

JSON has fewer types than Python, so a round trip is not always lossless. Two different conversions happen here:

1. Object keys must be strings. json.dumps silently converts int keys (also float, bool, None) to strings, so 101 becomes "101". After loading, 101 in stock_back is False and .get(101) returns the default, while stock_back["101"] works. If a dict has both 1 and "1", both become "1": the JSON text contains the key twice, and json.loads keeps the last one, so one value is silently lost.
2. Tuples become arrays, and arrays load as lists. (9, 12) is written as [9, 12] and comes back as a list. In Python, a list never equals a tuple, so slot_back == slot is False even though the data "looks" the same.

Real-world bug: a service caches {product_id: qty} in Redis. In-memory lookups by integer ID work; after a restart or on another worker, the data comes from the cache and every lookup misses, so the app shows everything as out of stock. Tests pass because they never go through the cache.

Takeaway: JSON is a wire format, not a Python serializer. Decide the shape explicitly at the boundary: convert keys back ({int(k): v ...}) or validate with a schema (for example a Pydantic model with dict[int, int]), and don't compare raw loaded JSON to Python objects with tuples.

Follow-ups:

1. "How would you load stock back with integer keys in one line?" {int(k): v for k, v in json.loads(raw).items()}. Or let Pydantic do it: TypeAdapter(dict[int, int]).validate_json(raw), which also rejects keys that aren't numbers.
2. "What does json.dumps do with a set, a datetime or a Decimal amount like ₹199.50?" It raises TypeError: Object of type ... is not JSON serializable. Convert explicitly (sorted list, ISO-8601 string, string or integer paise) or pass default= to handle them.
3. "Why not just use pickle for the cache?" Pickle keeps Python types, but loading untrusted pickle data can execute arbitrary code, it ties the cache to Python and to your class definitions, and other services can't read it. JSON with explicit conversion is safer and portable.

Scoring: Strong: All five lines; explains string-only keys and tuple-to-list, and names a production consequence such as cache lookups by int ID missing. Acceptable: Knows tuples become lists but expects int keys to survive (or the reverse); corrects it once asked what a JSON object key can be. Red flag: Treats json.loads(json.dumps(x)) as a deep copy of any Python object.

JR-MT-O06 · A green test with a misspelled method on a Mock

Medium & Tricky · Output · Junior (1–3 years) · testing, unittest.mock, Mock, autospec, truthiness · 7 min

Question: can_checkout is the code under test; the Mock objects are what a test would pass in instead of a real risk-service client. What does this print?

from unittest import mock


class RiskClient:
    def is_user_blocked(self, user_id: int) -> bool:
        raise NotImplementedError("calls the risk service over HTTP")


def can_checkout(client, user_id):
    if client.is_blocked(user_id):          # bug: real method is is_user_blocked
        return False
    return True


client = mock.Mock()
client.is_user_blocked.return_value = True
print("blocked user:", can_checkout(client, 1))

client = mock.Mock()
client.is_user_blocked.return_value = False
print("normal user:", can_checkout(client, 2))

print(client.is_blocked.called, client.is_user_blocked.called)
print(bool(client.is_blocked(2)), client.is_blocked(2) is client.is_blocked(3))

strict = mock.create_autospec(RiskClient, instance=True)
strict.is_user_blocked.return_value = False
print("normal user (autospec):", can_checkout(strict, 2))

Expected output:

blocked user: False
normal user: False
True False
True True
AttributeError: Mock object has no attribute 'is_blocked'

The trap: Most candidates answer blocked user: False and normal user: True, assuming that because the test configured is_user_blocked, the code "uses" it. Others expect an AttributeError on the very first call because is_blocked doesn't exist on the real class.

Explanation:

Two behaviours of a plain Mock combine:

1. A Mock creates any attribute you ask for. client.is_blocked didn't exist, so the mock created a new child mock on the spot, and calling it returned yet another Mock (the same return_value object every time, hence is gives True). The test configured is_user_blocked, which the code never calls (called is False).
2. A Mock object is truthy. Like most objects, it has no __bool__ or __len__ returning false, so if client.is_blocked(user_id): is always true and can_checkout returns False for every user.

So the "blocked user" test passes for the wrong reason, and the "normal user" case reveals the bug only if someone wrote that test. In production the real client raises AttributeError immediately.

create_autospec(RiskClient, instance=True) builds a mock that only has the attributes and method signatures of the real class. Accessing is_blocked now raises AttributeError, so the typo fails in the test instead of in production. (Mock(spec=RiskClient) gives the attribute check; autospec also checks call arguments.)

Takeaway: a plain Mock accepts anything, so tests can pass while the code calls methods that don't exist. Use spec/autospec, test both the true and false branches, and assert on the call you expect (client.is_user_blocked.assert_called_once_with(2)).

Follow-ups:

1. "Which single assertion would have caught this bug even with a plain Mock?" client.is_user_blocked.assert_called_once_with(1) after the first call. It fails because the method was never called. Asserting on interactions you rely on is what makes a mock-based test meaningful.
2. "On Python 3.12, client.assret_called_once() and client.called_once_with(1) raise AttributeError instead of returning a Mock. Why does Mock make an exception for these names?" They look like assertion methods. If Mock auto-created them like any other attribute, the misspelled 'assertion' would do nothing and the test would always pass. So Mock refuses names that start with assert (unless it is a real assertion method) or with common misspellings such as assret and asert, and, since 3.12, names like called_once_with that are missing the assert_ prefix. That protects only assertion names; spec/autospec protects every attribute.
3. "When would you avoid mocking the client altogether?" When a small fake is easy: a FakeRiskClient class with an in-memory set of blocked IDs. Fakes break loudly when the interface changes and make tests read like real usage. Mock at the boundary (HTTP) with tools such as httpx.MockTransport or respx.

Scoring: Strong: Exact output; explains attribute auto-creation and Mock truthiness, and fixes the test with spec/autospec plus an assert_called_once_with. Acceptable: Realises is_blocked is auto-created but expects normal user: True; gets it after being asked what bool(Mock()) is. Red flag: Thinks a Mock only has the methods you configured, or that a passing mock-based test proves the code calls the real API correctly.

JR-MT-C01 · A batching writer for bulk inserts, as a context manager

Medium & Tricky · Coding · Junior (1–3 years) · context managers, __exit__, mutability, aliasing, batching, classes · 20 min

Problem:

A loader inserts lakhs of order rows into a warehouse. One INSERT per row is too slow, so rows are sent in batches through a sink(batch) function (a bulk insert). Write a class BatchWriter(sink, size=500) used like this:

with BatchWriter(bulk_insert, size=500) as writer:
    for row in read_rows():
        writer.add(row)

• add(row) buffers the row; when the buffer reaches size, it calls sink with that batch.
• flush() sends any buffered rows (never calls sink with an empty batch).
• On a clean exit from the with block, the remaining rows are flushed.
• If the block raises, the partial batch is discarded (batches already sent stay sent) and the exception propagates.
• writer.flushed counts rows handed to sink.
• The sink may keep a reference to the list it receives (a test double, a queue, a retry buffer). That list must never change afterwards.
• size < 1 raises ValueError.

Signature: class BatchWriter: def __init__(self, sink: Callable[[list[Row]], None], size: int = 500) -> None: ... def add(self, row: Row) -> None: ... def flush(self) -> None: ...

Constraints: Standard library only. Row = dict[str, Any].

Examples:

• size=3, add ORD-1..ORD-7, clean exit → sink receives [1,2,3], [4,5,6], [7]; flushed == 7
• size=2, add ORD-1..ORD-3, then raise ValueError inside the block → sink received only [1,2]; the ValueError propagates

Hints:

1. After sink(self._buffer), how do you empty the buffer? What does .clear() do to the list the sink just stored?
2. __exit__ receives the exception type (or None). What should it do in each case, and what must it return so the exception isn't swallowed?
3. Should the partial batch really be thrown away on error? Think about what a half-validated batch means for the warehouse.

Reference solution:

from collections.abc import Callable
from types import TracebackType
from typing import Any

Row = dict[str, Any]


class BatchWriter:
    """Buffer rows and hand them to `sink` in batches of `size`.

    On a clean exit the remaining rows are flushed. If the with-block raises,
    the unflushed rows are discarded and the exception propagates.
    """

    def __init__(self, sink: Callable[[list[Row]], None], size: int = 500) -> None:
        if size < 1:
            raise ValueError("size must be >= 1")
        self._sink = sink
        self._size = size
        self._buffer: list[Row] = []
        self.flushed = 0

    def add(self, row: Row) -> None:
        self._buffer.append(row)
        if len(self._buffer) >= self._size:
            self.flush()

    def flush(self) -> None:
        if not self._buffer:
            return
        batch, self._buffer = self._buffer, []      # hand over this list, start a new one
        self._sink(batch)
        self.flushed += len(batch)

    def __enter__(self) -> "BatchWriter":
        return self

    def __exit__(
        self,
        exc_type: type[BaseException] | None,
        exc: BaseException | None,
        tb: TracebackType | None,
    ) -> None:
        if exc_type is None:
            self.flush()
        else:
            self._buffer = []

Complexity: add is amortised O(1); each row is copied into exactly one batch. Memory O(size) for the buffer.

Tests:

class ListSink:
    """Stands in for a bulk INSERT: just remembers what it was given."""
    def __init__(self):
        self.batches = []

    def __call__(self, batch):
        self.batches.append(batch)


rows = [{"order_id": f"ORD-{i}", "amount": 100 * i} for i in range(1, 8)]

sink = ListSink()
with BatchWriter(sink, size=3) as writer:
    for row in rows:
        writer.add(row)
    assert len(sink.batches) == 2            # two full batches flushed while adding
assert [[r["order_id"] for r in b] for b in sink.batches] == [
    ["ORD-1", "ORD-2", "ORD-3"], ["ORD-4", "ORD-5", "ORD-6"], ["ORD-7"],
]
assert writer.flushed == 7

# the batches the sink received must not change afterwards
first = sink.batches[0]
writer.add({"order_id": "ORD-8", "amount": 800})
assert [r["order_id"] for r in first] == ["ORD-1", "ORD-2", "ORD-3"]

# an error inside the block: full batches already sent stay sent, the partial
# batch is NOT written, and the exception is not swallowed
sink = ListSink()
try:
    with BatchWriter(sink, size=2) as writer:
        for row in rows[:3]:
            writer.add(row)
        raise ValueError("bad amount in ORD-4")
except ValueError as exc:
    assert str(exc) == "bad amount in ORD-4"
else:
    raise AssertionError("exception was swallowed")
assert [[r["order_id"] for r in b] for b in sink.batches] == [["ORD-1", "ORD-2"]]
assert writer.flushed == 2

# nothing added: the sink is never called with an empty batch
sink = ListSink()
with BatchWriter(sink, size=10):
    pass
assert sink.batches == []

try:
    BatchWriter(ListSink(), size=0)
    raise AssertionError("expected ValueError")
except ValueError:
    pass

A common wrong solution (the tests catch it):

class BatchWriter:
    def __init__(self, sink, size=500):
        if size < 1:
            raise ValueError("size must be >= 1")
        self._sink = sink
        self._size = size
        self._buffer = []
        self.flushed = 0

    def add(self, row):
        self._buffer.append(row)
        if len(self._buffer) >= self._size:
            self.flush()

    def flush(self):
        if not self._buffer:
            return
        self._sink(self._buffer)
        self.flushed += len(self._buffer)
        self._buffer.clear()

    def __enter__(self):
        return self

    def __exit__(self, exc_type, exc, tb):
        self.flush()
        return True

Alternatives and tradeoffs:

• Generator-based batching: itertools.batched(rows, 500) (3.12+) and a plain loop for batch in batched(...): sink(list(batch)). Simpler when you have all rows in one iterable; the class is useful when rows come from many places (callbacks, several loops).
• @contextmanager function yielding an add callable: less code, but no flush() method or flushed counter without extra machinery.
• Copy instead of swap: self._sink(list(self._buffer)) then clear(). Also correct; swapping avoids one copy.

Follow-ups:

1. "Why does the test double that stores batches catch the aliasing bug when the real database sink wouldn't?" A DB driver serialises the rows during the call and never looks at the list again, so later clear() is harmless. A sink that keeps the reference (like a retry queue that re-sends a batch after a timeout) sees the list change under it. Tests should use sinks that keep what they receive, so they catch exactly this.
2. "The job died after 40 of 100 batches were inserted. How do you make a re-run safe?" Make inserts idempotent: upsert by a natural key (order_id) or load into a staging table and swap/merge at the end in one transaction. Then re-running from the start, or from a saved checkpoint, can't create duplicates.
3. "When would you flush the partial batch on error instead of discarding it?" When the rows are independent and already validated, and the error came from something unrelated (e.g. reading the next row). Discarding is the safer default when a failure could mean the batch itself is bad. Either way, log what was dropped.

Scoring: Strong: Hands over the buffer by swapping in a new list (or copying), flushes on clean exit only, returns a falsy value from __exit__, never sends empty batches, and explains why a storing sink exposes the aliasing bug. Acceptable: Correct batching and exit logic but uses clear() on the sent list; fixes it after being asked what the sink holds afterwards. Red flag: __exit__ returns True, or the candidate can't explain why two names for one list both see clear().

JR-MT-C02 · Reconcile split UPI settlements against orders, to the paisa

Medium & Tricky · Coding · Junior (1–3 years) · Decimal, money, parsing, dicts, defaultdict, reconciliation · 20 min

Problem:

Finance downloads the payment gateway's settlement report and wants it matched against the order system every morning.

• orders: list of (order_id, amount) where amounts look like "₹1,25,000.50", "Rs. 499" (Indian digit grouping, optional ₹ or Rs. prefix).
• settlements: list of (order_id, amount) from the gateway's CSV, e.g. "125000.5" or "1,00,000.00". One order can be settled in several rows (split settlements), and the gateway occasionally sends a row twice.

Write to_paise(text) -> int that parses an amount exactly into integer paise (raise ValueError for negative, non-numeric, NaN/infinite, or more than 2 decimal places), and reconcile(orders, settlements) that returns:

• unsettled: order IDs with no settlement rows (sorted);
• unknown: settlement order IDs that aren't in orders (sorted, unique);
• mismatched: (order_id, expected_paise, settled_paise) for orders whose settled total differs from the order amount (sorted).

A duplicate order ID in orders raises ValueError.

Signature: def to_paise(text: str) -> int: def reconcile(orders: list[tuple[str, str]], settlements: list[tuple[str, str]]) -> dict[str, list]:

Constraints: Standard library only. No float anywhere in the money path.

Examples:

• to_paise("₹1,25,000.50") → 12500050
• order ₹1,999.80 settled as 1499.70 + 500.10 → not reported (it matches exactly)
• order ₹2,50,000 settled as 1,00,000.00 + 1,00,000.00 → mismatched: ('ORD-3', 25000000, 20000000)

Hints:

1. What is 1499.70 + 500.10 in floating point? Try it.
2. Decimal("1499.70") is exact. How do you turn it into an integer number of paise, and detect a third decimal place?
3. If you build {order_id: amount for ...} from the settlement rows, what happens to an order settled in two parts?

Reference solution:

from collections import defaultdict
from decimal import Decimal, InvalidOperation


def to_paise(text: str) -> int:
    """'₹1,25,000.50' / 'Rs. 499' / '125000.5' -> integer paise. Exact; no floats."""
    cleaned = text.strip().removeprefix("₹").removeprefix("Rs.").replace(",", "").strip()
    try:
        amount = Decimal(cleaned)
    except InvalidOperation:
        raise ValueError(f"not an amount: {text!r}") from None
    if not amount.is_finite() or amount < 0:
        raise ValueError(f"not an amount: {text!r}")
    paise = amount * 100
    if paise != paise.to_integral_value():
        raise ValueError(f"more than 2 decimal places: {text!r}")
    return int(paise)


def reconcile(
    orders: list[tuple[str, str]], settlements: list[tuple[str, str]]
) -> dict[str, list]:
    """Match gateway settlement rows (possibly several per order) against orders."""
    expected: dict[str, int] = {}
    for order_id, amount in orders:
        if order_id in expected:
            raise ValueError(f"duplicate order id: {order_id}")
        expected[order_id] = to_paise(amount)

    settled: defaultdict[str, int] = defaultdict(int)
    for order_id, amount in settlements:
        settled[order_id] += to_paise(amount)

    return {
        "unsettled": sorted(o for o in expected if o not in settled),
        "unknown": sorted(o for o in settled if o not in expected),
        "mismatched": sorted(
            (o, expected[o], settled[o]) for o in expected if o in settled and settled[o] != expected[o]
        ),
    }

Complexity: O(len(orders) + len(settlements)) to parse and sum, plus O(k log k) to sort the k reported items. Memory O(number of distinct order IDs).

Tests:

assert to_paise("₹1,25,000.50") == 12_500_050
assert to_paise("Rs. 499") == 49_900
assert to_paise(" 125000.5 ") == 12_500_050
assert to_paise("0.10") == 10

for bad in ["12.345", "abc", "-5", "", "NaN", "Infinity"]:
    try:
        to_paise(bad)
        raise AssertionError(f"accepted {bad!r}")
    except ValueError:
        pass

orders = [
    ("ORD-1", "₹1,999.80"),
    ("ORD-2", "₹499.00"),
    ("ORD-3", "₹2,50,000"),
    ("ORD-4", "₹99.90"),
]
settlements = [
    ("ORD-1", "1499.70"),     # ORD-1 settled in two parts
    ("ORD-1", "500.10"),
    ("ORD-2", "499"),
    ("ORD-3", "1,00,000.00"),  # ORD-3 settled in three parts, one part missing
    ("ORD-3", "1,00,000.00"),
    ("ORD-9", "10.00"),        # not one of ours
]

report = reconcile(orders, settlements)
assert report == {
    "unsettled": ["ORD-4"],
    "unknown": ["ORD-9"],
    "mismatched": [("ORD-3", 25_000_000, 20_000_000)],
}, report

# all good
assert reconcile([("A", "0.30")], [("A", "0.10"), ("A", "0.20")]) == {
    "unsettled": [], "unknown": [], "mismatched": [],
}

# a duplicated settlement row shows up as an over-payment, not silently ignored
assert reconcile([("A", "100")], [("A", "100"), ("A", "100")])["mismatched"] == [("A", 10_000, 20_000)]

try:
    reconcile([("A", "1"), ("A", "2")], [])
    raise AssertionError("expected ValueError")
except ValueError as exc:
    assert "A" in str(exc)

A common wrong solution (the tests catch it):

import math


def _to_rupees(text):
    cleaned = text.strip().removeprefix("₹").removeprefix("Rs.").replace(",", "").strip()
    try:
        value = float(cleaned)
    except ValueError:
        raise ValueError(f"not an amount: {text!r}") from None
    if not math.isfinite(value) or value < 0 or round(value, 2) != value:
        raise ValueError(f"not an amount: {text!r}")
    return value


def to_paise(text):
    return round(_to_rupees(text) * 100)


def reconcile(orders, settlements):
    expected = {}
    for order_id, amount in orders:
        if order_id in expected:
            raise ValueError(f"duplicate order id: {order_id}")
        expected[order_id] = _to_rupees(amount)
    settled = {}
    for order_id, amount in settlements:
        settled[order_id] = settled.get(order_id, 0.0) + _to_rupees(amount)
    return {
        "unsettled": sorted(o for o in expected if o not in settled),
        "unknown": sorted(o for o in settled if o not in expected),
        "mismatched": sorted(
            (o, round(expected[o] * 100), round(settled[o] * 100))
            for o in expected if o in settled and settled[o] != expected[o]
        ),
    }

Alternatives and tradeoffs:

• pandas: parse amounts to integer paise first, then groupby("order_id").sum() on settlements and an outer merge(..., indicator=True) with orders; _merge gives unsettled/unknown directly. Good for millions of rows; keep money as int64 paise, never float64.
• SQL in the warehouse: FULL OUTER JOIN of orders with SELECT order_id, SUM(amount_paise) ... GROUP BY order_id.
• collections.Counter works as the accumulator too (settled[o] += paise), the same as defaultdict(int).

Follow-ups:

1. "Why convert to integer paise instead of keeping Decimal everywhere?" Integers are exact, fast, serialise to JSON and databases without surprises, and sum in pandas/SQL without precision settings. Decimal is ideal for parsing and for arithmetic with rates (GST at 18%), followed by an explicit rounding rule (quantize(Decimal("0.01"), ROUND_HALF_UP)) back to paise.
2. "The gateway deducts its fee (say 2%) before settling. How does the reconciliation change?" Compare settled + fee with the order amount, where the fee comes from the report's fee column, not recomputed with your own rounding. If you must compute it, agree on the rounding rule with finance, because a paisa of difference per order becomes real money across lakhs of orders.
3. "How do you tell a duplicated row from a genuine split settlement?" Use the gateway's unique settlement or transaction ID: dedupe on it first, then sum. Without such an ID you can only flag over-payments for a person to review, as this function does.

Scoring: Strong: Exact parsing with Decimal into paise, rejects bad input, sums split settlements with defaultdict(int), reports all three categories correctly, and can explain the float failure with a concrete example. Acceptable: Uses Decimal but keeps only one settlement row per order (or vice versa: sums correctly with floats); fixes it once shown the split or the 1499.70 + 500.10 case. Red flag: Uses float for money and compares with ==, or 'fixes' it with round(..., 2) without understanding why floats are wrong.

JR-MT-C03 · Apply payment-gateway webhooks: retries and out-of-order delivery

Medium & Tricky · Coding · Junior (1–3 years) · idempotency, webhooks, dicts and sets, mutability, deepcopy, state machines · 20 min

Problem:

A payment gateway (think Razorpay or Cashfree) calls your webhook with events. Gateways retry deliveries, so the same event can arrive more than once, and they don't guarantee order, so payment.authorized can arrive after payment.captured.

Each event is a dict: {"id": "evt_1", "order_id": "ORD-1", "type": ..., "amount": ...} where type is payment.authorized, payment.captured or refund.processed (which also has an amount in paise).

Write apply_events(orders, seen, events) that returns a new (orders, seen) pair:

• orders maps order ID to {"status": ..., "refunded": <paise>}. An order seen for the first time starts as {"status": "created", "refunded": 0}.
• An event whose id is in seen (or already processed in this batch) is skipped.
• Status only moves forward: created → authorized → captured. An older status arriving late is ignored.
• refund.processed adds amount to refunded (a single order can have several partial refunds).
• An unknown event type raises ValueError naming it.
• The orders and seen passed in must not be modified, including the inner order dicts.

Signature: def apply_events(orders: dict[str, dict[str, Any]], seen: set[str], events: list[dict[str, Any]]) -> tuple[dict[str, dict[str, Any]], set[str]]:

Constraints: Standard library only. Amounts are integers in paise (no floats for money).

Examples:

• authorized(evt_1), captured(evt_2), authorized(evt_1 again) for ORD-1 → ORD-1 status 'captured'
• captured(evt_3) then authorized(evt_4) for ORD-2 → ORD-2 status stays 'captured'
• refund 20000 (evt_5), the same evt_5 again, refund 5000 (evt_6) → ORD-1 refunded 25000

Hints:

1. Two different problems: duplicates (same event twice) and reordering (an old event after a new one). Which rule handles which?
2. A duplicate refund would be wrong; a duplicate captured would be harmless. Why must you still dedupe by event ID?
3. dict(orders) copies the outer dict only. What happens to the caller's data when you do order["refunded"] += ...?

Reference solution:

import copy
from typing import Any

STATUS_RANK = {"created": 0, "authorized": 1, "captured": 2}
EVENT_STATUS = {"payment.authorized": "authorized", "payment.captured": "captured"}


def apply_events(
    orders: dict[str, dict[str, Any]],
    seen: set[str],
    events: list[dict[str, Any]],
) -> tuple[dict[str, dict[str, Any]], set[str]]:
    """Apply gateway webhook events; return NEW (orders, seen) without mutating the inputs.

    - an event id is applied at most once (gateways retry deliveries)
    - status only moves forward: created -> authorized -> captured
    - refund.processed adds its amount (in paise) to the order's refunded total
    """
    orders = copy.deepcopy(orders)
    seen = set(seen)
    for event in events:
        if event["id"] in seen:
            continue
        kind = event["type"]
        if kind not in EVENT_STATUS and kind != "refund.processed":
            raise ValueError(f"unknown event type: {kind}")
        seen.add(event["id"])
        order = orders.setdefault(event["order_id"], {"status": "created", "refunded": 0})
        if kind == "refund.processed":
            order["refunded"] += event["amount"]
        elif STATUS_RANK[EVENT_STATUS[kind]] > STATUS_RANK[order["status"]]:
            order["status"] = EVENT_STATUS[kind]
    return orders, seen

Complexity: O(len(events)) time plus O(size of orders) for the deep copy; O(len(seen) + len(events)) memory.

Tests:

import copy

events = [
    {"id": "evt_1", "order_id": "ORD-1", "type": "payment.authorized"},
    {"id": "evt_2", "order_id": "ORD-1", "type": "payment.captured"},
    {"id": "evt_1", "order_id": "ORD-1", "type": "payment.authorized"},   # retried delivery
    {"id": "evt_3", "order_id": "ORD-2", "type": "payment.captured"},     # authorized arrives late
    {"id": "evt_4", "order_id": "ORD-2", "type": "payment.authorized"},
    {"id": "evt_5", "order_id": "ORD-1", "type": "refund.processed", "amount": 20_000},
    {"id": "evt_5", "order_id": "ORD-1", "type": "refund.processed", "amount": 20_000},  # retry
    {"id": "evt_6", "order_id": "ORD-1", "type": "refund.processed", "amount": 5_000},
]

orders, seen = apply_events({}, set(), events)
assert orders == {
    "ORD-1": {"status": "captured", "refunded": 25_000},
    "ORD-2": {"status": "captured", "refunded": 0},
}
assert seen == {"evt_1", "evt_2", "evt_3", "evt_4", "evt_5", "evt_6"}

# replaying the whole batch (e.g. after a crash) changes nothing
again, seen_again = apply_events(orders, seen, events)
assert again == orders and seen_again == seen

# inputs are never mutated, including the nested order dicts
before_orders, before_seen = copy.deepcopy(orders), set(seen)
after, _ = apply_events(orders, seen, [
    {"id": "evt_7", "order_id": "ORD-2", "type": "refund.processed", "amount": 1_000},
    {"id": "evt_8", "order_id": "ORD-3", "type": "payment.authorized"},
])
assert orders == before_orders and seen == before_seen
assert after["ORD-2"]["refunded"] == 1_000
assert after["ORD-3"] == {"status": "authorized", "refunded": 0}

# a status never moves backwards, even across batches
later, _ = apply_events(after, set(), [{"id": "evt_9", "order_id": "ORD-1", "type": "payment.authorized"}])
assert later["ORD-1"]["status"] == "captured"

# unknown event types are rejected loudly
try:
    apply_events({}, set(), [{"id": "evt_x", "order_id": "ORD-9", "type": "payment.teleported"}])
    raise AssertionError("expected ValueError")
except ValueError as exc:
    assert "payment.teleported" in str(exc)

A common wrong solution (the tests catch it):

STATUS_RANK = {"created": 0, "authorized": 1, "captured": 2}
EVENT_STATUS = {"payment.authorized": "authorized", "payment.captured": "captured"}


def apply_events(orders, seen, events):
    orders = dict(orders)            # shallow copy: inner dicts are still shared
    seen = set(seen)
    for event in events:
        if event["id"] in seen:
            continue
        kind = event["type"]
        if kind not in EVENT_STATUS and kind != "refund.processed":
            raise ValueError(f"unknown event type: {kind}")
        seen.add(event["id"])
        order = orders.setdefault(event["order_id"], {"status": "created", "refunded": 0})
        if kind == "refund.processed":
            order["refunded"] += event["amount"]
        elif STATUS_RANK[EVENT_STATUS[kind]] > STATUS_RANK[order["status"]]:
            order["status"] = EVENT_STATUS[kind]
    return orders, seen

Alternatives and tradeoffs:

• In a database: a unique constraint on event_id in a processed_events table, inserted in the same transaction as the order update, so a retry hits the constraint and is skipped. Status moves with a conditional update: UPDATE orders SET status = 'captured' WHERE id = :id AND status IN ('created', 'authorized').
• Re-fetch instead of trusting the event: on any event, call the gateway's API for the payment's current state. This handles reordering for free at the cost of an API call.
• Mutate in place for speed, if the function owns the state; then document it and don't also return it, so callers aren't confused about aliasing.

Follow-ups:

1. "seen grows forever. What would you do in production?" Keep event IDs for a window longer than the gateway's retry period (for example, 7 days), in a table with a timestamp or a Redis set with TTL, and delete older ones. After the window, a duplicate is no longer possible.
2. "How do you check the webhook really came from the gateway?" Verify the signature header: the gateway sends an HMAC of the raw request body using a shared webhook secret. Compute it over the raw bytes (before JSON parsing) and compare with hmac.compare_digest; reject on mismatch.
3. "Why does the handler return 200 even when it skipped a duplicate event?" From the gateway's point of view the event was delivered successfully. Returning an error would make it retry again and again. Return non-2xx only when you couldn't process the event and want a retry.

Scoring: Strong: Dedupes by event ID, moves status forward only via a rank, accumulates refunds, deep-copies (or rebuilds) inner dicts, and explains why both rules are needed. Acceptable: Handles duplicates and ordering but mutates the caller's nested dicts; fixes it after the shallow-copy hint. Red flag: Last-write-wins, no dedupe of refunds, or floats for money.

JR-H-O01 · What type hints, TypedDict and NewType do at runtime

Hard · Output · Junior (1–3 years) · typing, TypedDict, NewType, annotations, runtime behaviour · 8 min

Question: What does this print?

from typing import NewType, TypedDict

OrderId = NewType("OrderId", int)

class Order(TypedDict):
    id: OrderId
    amount: float

def with_gst(orders: list[Order], rate: float = 0.18) -> float:
    return round(sum(o["amount"] for o in orders) * (1 + rate), 2)

o = Order(id="A-7", amount=100)
print(o, type(o).__name__)
print(with_gst([o]), with_gst([o], rate=1))

oid = OrderId(42)
print(oid, type(oid).__name__, oid + 1)
print(with_gst.__annotations__["orders"], with_gst.__annotations__["return"])

try:
    with_gst([o], rate="0.05")
except TypeError as exc:
    print("TypeError:", exc)
try:
    print(isinstance([o], list[Order]))
except TypeError as exc:
    print("TypeError:", exc)

Expected output:

{'id': 'A-7', 'amount': 100} dict
118.0 200
42 int 43
list[__main__.Order] <class 'float'>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
TypeError: isinstance() argument 2 cannot be a parameterized generic

Explanation:

Python stores type hints but never checks them. They are read by type checkers (mypy, pyright), IDEs, and libraries that choose to look at them (Pydantic, FastAPI, dataclasses).

• TypedDict only describes the shape of a dict for the type checker. Calling Order(...) just builds a plain dict: id="A-7" is accepted although the hint says OrderId, and type(o) is dict.
• Return hints are not enforced either. with_gst([o]) gives round(118.0, 2) = 118.0. With rate=1, the sum is the int 100, 100 * 2 is the int 200, and round(200, 2) returns an int. The function promised float and returned 200; nothing complained.
• NewType is an identity function at runtime: OrderId(42) returns the very same int. The distinct type exists only for the checker, so type(oid) is int and oid + 1 is an ordinary 43.
• The hints are kept in __annotations__ as real objects: list[Order] is a types.GenericAlias (its repr shows the module, __main__.Order) and the return hint is the class float.
• Passing rate="0.05" is not rejected at the call. It fails later, inside the function, when 1 + "0.05" runs, with an error that says nothing about the parameter.
• You can't use a parameterised generic like list[Order] with isinstance; checking element types would mean walking the whole container, so Python refuses.

Takeaway: hints document intent and power tools; if you need checks at runtime, validate explicitly (Pydantic, a TypeAdapter, or your own checks) at the boundary where untrusted data enters.

Follow-ups:

1. "Which of these lines would mypy flag, and which would it accept?" It flags Order(id="A-7", ...) (str is not OrderId) and rate="0.05" (str is not float). It accepts rate=1, because PEP 484 lets an int be passed where float is expected. It also accepts OrderId(42) + 1; the result is typed as plain int, not OrderId.
2. "How would you get real validation of the incoming order dicts without rewriting them as classes?" Pydantic v2 can validate a TypedDict directly: TypeAdapter(list[Order]).validate_python(payload). It raises a ValidationError naming the bad field ("A-7" cannot be parsed as an int), which is far easier to debug than a TypeError deep inside the arithmetic.
3. "What changes with from __future__ import annotations at the top of the module?" Annotations are stored as strings ('list[Order]') and not evaluated at definition time, so forward references work and imports are cheaper. Tools that need the real objects call typing.get_type_hints(with_gst), which evaluates the strings.

Scoring: Strong: All six lines right; states plainly that hints aren't enforced, knows TypedDict builds a plain dict and NewType is an identity function, and spots that rate=1 returns an int despite -> float. Acceptable: Knows hints aren't enforced and gets most lines; unsure about the NewType line or the isinstance error until talked through it. Red flag: Expects Order(id="A-7", ...) or rate="0.05" to be rejected at the call because of the annotations.

JR-H-O02 · A three-stage generator pipeline hits a bad row

Hard · Output · Junior (1–3 years) · generators, lazy evaluation, itertools.islice, exceptions in generators, data pipelines · 8 min

Question: What does this print? Read carefully which stage runs when.

from itertools import islice

def read_lines(lines):
    for line in lines:
        print(f"read  {line!r}")
        yield line

def parse(rows):
    for row in rows:
        name, amount = row.split(",")
        print(f"parse {name}")
        yield name, int(amount)

def large(orders, minimum):
    for name, amount in orders:
        if amount >= minimum:
            yield name

raw = ["asha,1200", "ravi,300", "meera,5000", "bad-row", "kiran,9000"]
pipeline = large(parse(read_lines(raw)), 1000)
print("built")
print(list(islice(pipeline, 2)))
try:
    next(pipeline)
except ValueError as exc:
    print("ValueError:", exc)
print(next(pipeline, "exhausted"))

Expected output:

built
read  'asha,1200'
parse asha
read  'ravi,300'
parse ravi
read  'meera,5000'
parse meera
['asha', 'meera']
read  'bad-row'
ValueError: not enough values to unpack (expected 2, got 1)
exhausted

Explanation:

Calling a generator function runs none of its body; it only creates a generator object. Building the three-stage pipeline therefore prints nothing, and built comes first.

Values are pulled from the outside in. islice(pipeline, 2) asks large for an item; large asks parse, which asks read_lines, which reads one line. So each row travels through every stage before the next row is read, and the read/parse lines interleave. ravi is read and parsed, but large drops it (300 < 1000) and simply pulls the next row. Once islice has two names it stops asking, so bad-row has not been read yet.

The next next(pipeline) resumes the chain: read_lines yields "bad-row", and row.split(",") gives a one-element list, so the unpacking in parse raises ValueError. The exception travels up through large to the caller. A generator that lets an exception escape is finished for good: parse and large are both closed, so the next call gets the default "exhausted" and kiran is never processed.

Takeaway: a generator pipeline streams one record through all stages at a time, using memory for one record rather than the whole file, but one unhandled bad record kills the whole chain. Handle bad rows inside the stage (catch, log, count, skip) if the pipeline must keep going.

Follow-ups:

1. "Change parse so a bad row is logged and skipped instead of killing the pipeline. Where exactly does the try go?" Around the per-row work, inside the loop: try: name, amount = row.split(","); value = int(amount) / except ValueError: log.warning("bad row %r", row); continue / then yield name, value. Putting the try around the whole for loop would still end the generator at the first bad row.
2. "Roughly how much memory does this pipeline use on a 10 GB file, and what would ruin that?" About one line at a time plus whatever the consumer keeps, because nothing materialises the data. Calling list() on any stage, or a stage that collects rows (for example to sort them), loads everything into memory.
3. "Why didn't islice(pipeline, 2) read the whole input to find two matches 'efficiently'?" It can't look ahead; it only calls next() until it has two items, then stops. That laziness is exactly why bad-row wasn't touched until the following next().

Scoring: Strong: Exact interleaving, explains that bad-row isn't read during the islice and that the generator is dead after the exception, so kiran is never seen. Acceptable: Gets the laziness and interleaving but expects kiran to be returned by the last next; corrects it when asked what state a generator is in after raising. Red flag: Prints all read lines before any parse line (thinks each stage runs to completion), or expects the error at pipeline = ....

JR-H-O03 · @contextmanager that swallows one error and skips cleanup on another

Hard · Output · Junior (1–3 years) · context managers, contextlib.contextmanager, exceptions, try/finally · 8 min

Question: What does this print?

from contextlib import contextmanager

@contextmanager
def transaction(name):
    print(f"BEGIN {name}")
    try:
        yield name.upper()
    except KeyError as exc:
        print(f"ROLLBACK {name}: {exc}")
    else:
        print(f"COMMIT {name}")
    finally:
        print(f"END {name}")

@contextmanager
def audit(name):
    print(f"open audit {name}")
    yield
    print(f"close audit {name}")

with transaction("orders") as tx:
    print("inside", tx)

with transaction("refunds"):
    {}["order_42"]
print("after refunds")

try:
    with audit("wallet"), transaction("wallet"):
        raise ValueError("negative balance")
except ValueError as exc:
    print("caught:", exc)

Expected output:

BEGIN orders
inside ORDERS
COMMIT orders
END orders
BEGIN refunds
ROLLBACK refunds: 'order_42'
END refunds
after refunds
open audit wallet
BEGIN wallet
END wallet
caught: negative balance

Explanation:

@contextmanager turns a generator into a context manager. The code before yield is the setup, and the yielded value is what as binds (ORDERS). When the with body finishes normally, the generator resumes after the yield, so the else branch commits. When the body raises, the exception is re-raised inside the generator at the yield, so ordinary try/except/finally around the yield decides what happens.

• refunds: the KeyError is caught by except KeyError, which prints and does not re-raise. The generator then finishes normally, and contextmanager takes that to mean "handled", so the exception is suppressed and after refunds prints. (str() of a KeyError is the repr of the key, hence the quotes.)
• wallet: in with audit(...), transaction(...) the managers are entered left to right and exited right to left. The ValueError reaches transaction first: it is not a KeyError, so there is no rollback message and no commit, finally prints END wallet, and the exception continues outward. Then it is raised inside audit at its bare yield. With no try/finally there, the generator just dies, close audit wallet never prints, and the exception reaches the outer except.

Takeaway: in a generator-based context manager, put yield inside try/finally for cleanup that must always run, and end every except with raise unless you really mean to swallow the error.

Follow-ups:

1. "Rewrite transaction so it rolls back on any exception but never hides it from the caller." try: yield ... / except BaseException: rollback(); raise / else: commit() / finally: release(). The bare raise re-raises the original exception with its traceback; catching BaseException also rolls back on KeyboardInterrupt.
2. "What is the class-based equivalent of 'swallowing' here?" __exit__(self, exc_type, exc, tb) returning a truthy value suppresses the exception. Returning None (the default) or False lets it propagate, which is what you want almost always.
3. "When is suppressing an exception in a context manager actually correct?" When it is the whole point and is explicit, like contextlib.suppress(FileNotFoundError) around deleting a temp file that may already be gone. Hiding a KeyError inside a 'transaction' helper, so the caller thinks the work succeeded, is a bug.

Scoring: Strong: All lines right; explains that the exception is raised at the yield, that a non-re-raising except suppresses it, the right-to-left exit order, and why close audit is missing. Acceptable: Gets orders and refunds right, but expects close audit wallet to print; understands why after being reminded there is no finally. Red flag: Expects the KeyError to propagate and crash the script, or thinks the code after yield always runs.

JR-H-O04 · Missing ratings in groupby aggregations

Hard · Output · Junior (1–3 years) · pandas, missing values, NaN, groupby, count vs size, aggregations · 8 min

Question: Store ratings come from a feedback form where most customers skip the rating. What does this print?

import pandas as pd

ratings = pd.DataFrame({
    "store": ["Pune", "Pune", "Pune", "Delhi", "Delhi"],
    "rating": [4.0, None, 5.0, None, None],
})
g = ratings.groupby("store")["rating"]
print(g.size().to_dict())
print(g.count().to_dict())
print(g.mean().to_dict())
print(g.sum().to_dict())
print(ratings["rating"].mean(), ratings["rating"].fillna(0).mean())
print((ratings["rating"] == None).sum(), ratings["rating"].isna().sum())
print(g.sum(min_count=1).to_dict())

Expected output:

{'Delhi': 2, 'Pune': 3}
{'Delhi': 0, 'Pune': 2}
{'Delhi': nan, 'Pune': 4.5}
{'Delhi': 0.0, 'Pune': 9.0}
4.5 1.8
0 3
{'Delhi': nan, 'Pune': 9.0}

Explanation:

None in a float column becomes NaN. Most pandas reductions skip NaN by default, and that one default explains every line:

• size() counts rows per group, missing or not: Delhi 2, Pune 3. groupby sorts keys, so Delhi comes first.
• count() counts non-missing values: Delhi has none, Pune has two.
• mean() averages only the values that are present: Pune is (4 + 5) / 2 = 4.5. Delhi has nothing to average, so it gets NaN.
• sum() of nothing is 0 (the default min_count=0), so Delhi shows a total of 0.0. A report built from sums would show Delhi as "rated zero" when it was never rated at all.
• The overall mean skips the three missing values (9 / 2 = 4.5). fillna(0) turns "no rating" into "rated 0" and drags the average down to 9 / 5 = 1.8, a very different business claim.
• == None compares element by element, and NaN == None is False, so it counts 0. Use isna(), which finds all 3.
• sum(min_count=1) returns NaN when a group has fewer than one real value, which keeps "no data" distinct from "zero".

Takeaway: decide on purpose what a missing value means (unknown, zero, or excluded), check count() next to every mean()/sum(), and test for missing data with isna().

Follow-ups:

1. "Product asks for 'average rating per store' on the dashboard. What would you show for Delhi?" Not 0 and not a bare NaN. Show the mean together with the number of ratings (g.agg(['mean', 'count'])) and render Delhi as 'no ratings yet'. Also consider hiding means based on very few ratings, because one 5-star review isn't a reliable average.
2. "Why does ratings['rating'] == np.nan also find nothing?" NaN is not equal to anything, itself included (IEEE 754). That's why pandas provides isna()/notna(), and why np.isnan exists.
3. "Would this change if store itself had missing values?" Yes: by default groupby drops rows whose key is NaN, so their ratings disappear from every group. Pass dropna=False to keep them as their own group.

Scoring: Strong: All seven lines; clearly separates size from count, knows an all-NaN sum is 0 but an all-NaN mean is NaN, and gives the business consequence of fillna(0). Acceptable: Gets the skip-NaN behaviour and size vs count, but expects the all-NaN sum to be NaN; accepts the min_count explanation. Red flag: Thinks mean() treats missing values as 0, or uses == None to find missing values.

JR-H-O05 · lru_cache returns the same list every time

Hard · Output · Junior (1–3 years) · decorators, functools.lru_cache, mutability, aliasing, hashing · 8 min

Question: pincodes_for stands in for a slow lookup, so someone added @lru_cache. What does this print?

from functools import lru_cache

calls = []

@lru_cache(maxsize=None)
def pincodes_for(city):
    calls.append(city)
    return ["411001", "411002"] if city == "Pune" else []

a = pincodes_for("Pune")
a.append("999999")
b = pincodes_for("Pune")
print(b, a is b, calls)

pincodes_for("Delhi")
pincodes_for(city="Delhi")
print(pincodes_for.cache_info())

try:
    pincodes_for(["Pune"])
except TypeError as exc:
    print("TypeError:", exc)

pincodes_for.cache_clear()
print(pincodes_for("Pune"), len(calls))

Expected output:

['411001', '411002', '999999'] True ['Pune']
CacheInfo(hits=1, misses=3, maxsize=None, currsize=3)
TypeError: unhashable type: 'list'
['411001', '411002'] 4

Explanation:

lru_cache stores the object the function returned and hands back that same object on every hit; it doesn't copy anything. The caller who did a.append("999999") mutated the cached list, so the second call returns the corrupted list (a is b is True) and the function body never ran again (calls == ['Pune']). Every later caller in the process now sees a fake pincode.

The cache key is built from the arguments as passed. pincodes_for("Delhi") and pincodes_for(city="Delhi") produce different keys, so both are misses. Total: Pune miss, Pune hit, Delhi miss, city="Delhi" miss, giving hits=1, misses=3, currsize=3.

Building the key means hashing the arguments, so an unhashable argument such as a list fails with TypeError before the function runs.

cache_clear() empties the cache; the next call recomputes and returns a fresh, clean list, and calls has grown to 4.

Takeaway: only cache functions whose results are immutable (return a tuple/frozenset, or copy on the way out), and remember the cache is shared by the whole process.

Follow-ups:

1. "How would you fix this without dropping the cache?" Return an immutable value: return ("411001", "411002") or a frozenset. Callers that need a list do list(pincodes_for(city)), which gives them their own copy. A wrapper that copies on every hit also works but costs an allocation per call.
2. "What's the risk of @lru_cache on an instance method?" self becomes part of the key, so the cache holds a strong reference to every instance it has seen and they are never garbage-collected (a memory leak in a long-running service). It also mixes per-instance results into one global cache. Prefer a module-level function, functools.cached_property, or a dict owned by the instance.
3. "maxsize=None vs the default maxsize=128: when does it matter?" None (or functools.cache) never evicts, so the cache grows with every distinct argument. That's fine for a small fixed set such as city names, and a memory leak for something like user IDs. A bounded size evicts the least recently used entries.

Scoring: Strong: All lines right, including hits=1, misses=3; explains the shared returned object and that positional vs keyword calls make different keys; proposes returning tuples. Acceptable: Spots the aliasing bug and the unhashable error; miscounts the cache stats until asked to walk through each call. Red flag: Believes the cache returns a fresh copy, or expects pincodes_for(["Pune"]) to work.

JR-H-O06 · Redirects, raise_for_status and query params in httpx

Hard · Output · Junior (1–3 years) · HTTP, httpx, redirects, status codes, query parameters, testing with MockTransport · 8 min

Question: The orders API moved from /v1 to /v2. Using httpx's MockTransport to fake the server, what does this print?

import httpx

def handler(request: httpx.Request) -> httpx.Response:
    if request.url.path == "/v1/orders":
        return httpx.Response(301, headers={"Location": "/v2/orders"})
    if request.url.path == "/v2/orders":
        return httpx.Response(200, json={"query": request.url.query.decode()})
    return httpx.Response(404, json={"detail": "not found"})

client = httpx.Client(transport=httpx.MockTransport(handler), base_url="https://api.shop.in")

r = client.get("/v1/orders")
print(r.status_code, r.is_success, r.next_request.url)
try:
    r.raise_for_status()
except httpx.HTTPStatusError as exc:
    print("raised for", exc.response.status_code)

params = {"city": "Navi Mumbai", "tag": ["new", "cod"], "page": 2}
r = client.get("/v1/orders", params=params, follow_redirects=True)
print(r.history[0].request.url.query.decode())
print(r.status_code, r.url.path, r.json())

Expected output:

301 False https://api.shop.in/v2/orders
raised for 301
city=Navi+Mumbai&tag=new&tag=cod&page=2
200 /v2/orders {'query': ''}

Explanation:

• httpx does not follow redirects by default (unlike requests). The first get returns the 301 response itself. is_success is true only for 2xx, so it's False. next_request holds the request httpx would send next, with the relative Location resolved against the base URL.
• httpx's raise_for_status() raises for anything that isn't 2xx, redirects included. (requests raises only for 4xx/5xx.) Code that calls raise_for_status() without enabling redirects will fail on a harmless 301.
• Query encoding: a space becomes +, a list becomes repeated keys (tag=new&tag=cod), and the int is turned into a string. Order is preserved.
• With follow_redirects=True the final response is the 200, and r.history holds the 301. The server's Location was /v2/orders with no query string, and a redirect goes exactly where Location points, so all the query parameters were dropped. The /v2 handler saw an empty query: the client asked for page 2 of COD orders in Navi Mumbai and silently got the default listing.

Takeaway: know your client's redirect policy, check status codes deliberately, and after following a redirect check r.url and r.history, because a redirect can change what you are actually asking for.

Follow-ups:

1. "What happens to a POST that gets a 302 redirect?" httpx, like browsers, re-sends it as a GET without the body for 301/302 (on a POST) and for 303. Only 307 and 308 keep the method and body. So a redirected POST /v1/orders can silently turn into a GET and never create the order. APIs that move endpoints should use 308.
2. "Why test HTTP code with MockTransport instead of calling the real API?" Tests become fast, deterministic and work offline, and you can produce any status code, header or malformed body on demand. It's the same httpx.Client code path. Inject the client (or transport) into your code so tests can swap it.
3. "Your client sends an Authorization header and the server redirects to another host. What should happen?" The token must not be forwarded to a different origin. httpx strips the Authorization header when a redirect goes to a different host. That's also a reason not to follow redirects blindly to hosts you don't control.

Scoring: Strong: All four lines; knows httpx doesn't follow redirects by default and raises for 3xx, and notices that the query string was dropped. Acceptable: Gets the status lines but expects the query to survive the redirect; understands once shown the Location header. Red flag: Assumes any non-200 response raises an exception automatically, or can't explain what a 301 response means.

JR-H-C01 · Lazy iterator over a cursor-paginated API

Hard · Coding · Junior (1–3 years) · generators, HTTP APIs, pagination, defensive coding, httpx · 25 min

Problem:

Your team pulls orders from a partner's REST API that pages with a cursor. Each call returns {"items": [...], "next": "<cursor>" | None}, and you pass the previous next value to get the following page (the first call uses None).

Write a generator iter_records(fetch_page, max_pages=1000) that yields every record, one page fetched at a time. fetch_page(cursor) is injected: in production it wraps an httpx call, and in tests it's a fake.

The partner API has known quirks you must handle:

• It sometimes returns an empty page that still has a next cursor. Keep going.
• When data shifts between calls, a record can appear on two pages. Yield each "id" once.
• A bug on their side once returned the same cursor forever. Detect a repeated cursor and raise RuntimeError, so the job fails instead of looping forever.
• Never fetch more than max_pages pages (raise RuntimeError).
• If a response isn't shaped like a page (for example {"error": "rate limited"}), raise ValueError. Never treat it as "no more data".

Signature: def iter_records(fetch_page: Callable[[str | None], dict], max_pages: int = 1000) -> Iterator[dict]:

Constraints:

• Must be lazy: if the consumer stops after the first page's items, the second page must never be requested.
• Records are dicts with a hashable "id".
• Standard library only (the tests use httpx just to show it works over HTTP).

Examples:

• pages: None -> ids [1, 2], next 'c2'; 'c2' -> [], next 'c3'; 'c3' -> ids [2, 3], next None → yields ids 1, 2, 3 (three fetches: None, 'c2', 'c3')
• list(islice(iter_records(fetch), 2)) on the pages above → ids [1, 2], with only ONE fetch made
• an API whose 'next' is always 'x' → RuntimeError (repeated cursor)

Hints:

1. Write it as a generator function with yield; laziness then comes for free.
2. Which condition actually means 'no more pages': an empty items list, or next being None?
3. Keep two sets: cursors already used and ids already yielded.

Reference solution:

from collections.abc import Callable, Iterator
from typing import Any

Page = dict[str, Any]


def iter_records(fetch_page: Callable[[str | None], Page], max_pages: int = 1000) -> Iterator[dict]:
    """Yield every record from a cursor-paginated API, one page fetched at a time.

    `fetch_page(cursor)` returns {"items": [...], "next": str | None}; the first
    call gets cursor=None. Records are de-duplicated by "id". Raises RuntimeError
    if the API repeats a cursor or more than `max_pages` pages are needed.
    """
    cursor: str | None = None
    seen_cursors: set[str] = set()
    seen_ids: set[Any] = set()
    for _ in range(max_pages):
        page = fetch_page(cursor)
        if not isinstance(page, dict) or not isinstance(page.get("items"), list):
            raise ValueError(f"unexpected page shape: {page!r}")
        for item in page["items"]:
            if item["id"] in seen_ids:
                continue
            seen_ids.add(item["id"])
            yield item
        cursor = page.get("next")
        if cursor is None:
            return
        if cursor in seen_cursors:
            raise RuntimeError(f"API repeated cursor {cursor!r}")
        seen_cursors.add(cursor)
    raise RuntimeError(f"gave up after {max_pages} pages")

Complexity: Time: O(P + N) for P pages and N records, plus whatever fetch_page costs (in practice the network dominates). Space: O(N) for the set of seen ids and O(P) for seen cursors. Records themselves are not kept; one page is in memory at a time.

Tests:

from itertools import islice

import httpx

def fake_api(pages: dict, log: list):
    def fetch(cursor):
        log.append(cursor)
        return pages[cursor]
    return fetch

pages = {
    None: {"items": [{"id": 1}, {"id": 2}], "next": "c2"},
    "c2": {"items": [], "next": "c3"},                       # empty page in the middle
    "c3": {"items": [{"id": 2}, {"id": 3}], "next": None},   # id 2 repeated after a shift
}
log: list = []
gen = iter_records(fake_api(pages, log))
assert log == []                                            # nothing fetched until iterated
assert list(islice(gen, 2)) == [{"id": 1}, {"id": 2}]
assert log == [None]                                        # lazy: page 2 not fetched yet
assert list(gen) == [{"id": 3}]
assert log == [None, "c2", "c3"]

# Single page, no next
assert list(iter_records(lambda c: {"items": [{"id": "a"}], "next": None})) == [{"id": "a"}]
assert list(iter_records(lambda c: {"items": [], "next": None})) == []

# A buggy API that hands back the same cursor forever must not hang
loop = {None: {"items": [{"id": 1}], "next": "x"}, "x": {"items": [], "next": "x"}}
try:
    list(iter_records(fake_api(loop, [])))
    raise AssertionError("expected RuntimeError")
except RuntimeError:
    pass

# max_pages guard (cursors never repeat, but there are too many pages)
endless = lambda c: {"items": [], "next": str(int(c or 0) + 1)}
try:
    list(iter_records(endless, max_pages=50))
    raise AssertionError("expected RuntimeError")
except RuntimeError:
    pass

# Error payloads are not silently treated as "no more data"
try:
    list(iter_records(lambda c: {"error": "rate limited"}))
    raise AssertionError("expected ValueError")
except ValueError:
    pass

# Works over real HTTP calls (httpx with a mock transport)
def handler(request: httpx.Request) -> httpx.Response:
    cursor = request.url.params.get("cursor")
    data = {None: ([{"id": "ORD-1"}], "abc"), "abc": ([{"id": "ORD-2"}], None)}[cursor]
    return httpx.Response(200, json={"items": data[0], "next": data[1]})

with httpx.Client(transport=httpx.MockTransport(handler), base_url="https://api.shop.in") as http:
    def fetch(cursor):
        params = {"cursor": cursor} if cursor else {}
        r = http.get("/orders", params=params)
        r.raise_for_status()
        return r.json()
    assert [o["id"] for o in iter_records(fetch)] == ["ORD-1", "ORD-2"]

A common wrong solution (the tests catch it):

def iter_records(fetch_page, max_pages=1000):
    cursor = None
    seen_ids = set()
    for _ in range(max_pages):
        page = fetch_page(cursor)
        items = page.get("items", [])
        if not items:                 # "empty page means we're done"
            return
        for item in items:
            if item["id"] not in seen_ids:
                seen_ids.add(item["id"])
                yield item
        cursor = page.get("next")
        if cursor is None:
            return
    raise RuntimeError("too many pages")

Alternatives and tradeoffs:

• No de-duplication (yield as-is) uses O(1) extra memory. That's fine if the API guarantees a stable snapshot, but our partner doesn't.
• Bounded de-dup (only remember ids from the last k pages) caps memory for very large exports, at the cost of missing far-apart duplicates. The warehouse load can also de-duplicate downstream with an upsert keyed on id.
• Collecting everything into a list is simpler to write, but it holds the whole export in memory and fetches every page even when the caller only needs the first few records.

Follow-ups:

1. "Where would retries for timeouts and 429 responses go, inside iter_records or inside fetch_page?" Inside fetch_page (or the HTTP client), because retrying is about one request. iter_records stays about paging logic. A retry wrapper with backoff, honouring Retry-After on 429, keeps both pieces small and separately testable.
2. "The job crashes after page 300 of 500. How would you resume without starting over?" Persist the last successful cursor (and ideally the max updated_at seen) after each page is processed, and accept a start_cursor argument. Downstream writes must be idempotent (upserts keyed on id), because the page being processed at the crash will be processed again.
3. "Why does the solution check for a repeated cursor before fetching rather than after?" It records each cursor as it is handed out and refuses to request one it has already used, so the duplicate page is never fetched. Checking afterwards would cost one extra network call and might yield duplicates before noticing.

Scoring: Strong: Generator with correct stop condition (next is None), keeps going over empty pages, de-duplicates ids, guards against repeated cursors and runaway paging, rejects error payloads, and explains why laziness matters. Acceptable: Correct generator for the happy path and empty pages; adds the loop guards once the interviewer describes the repeating-cursor incident. Red flag: Stops at the first empty page, builds a full list before returning, or has no protection against an infinite loop.

JR-H-C02 · A logging filter that redacts PII

Hard · Coding · Junior (1–3 years) · logging, logging.Filter, regular expressions, PII, security basics · 25 min

Problem:

A KYC service logs lines such as log.info("user %s uploaded PAN %s", email, pan). Compliance says no email address, PAN or Indian mobile number may ever reach the log files. Write a logging.Filter subclass, RedactingFilter, that masks them in every record that passes through it:

• emails become <email>;
• PAN numbers (5 capital letters, 4 digits, 1 capital letter, e.g. ABCDE1234F) become <pan>;
• 10-digit mobile numbers starting with 6–9, optionally prefixed by +91 with an optional space or hyphen, become <phone>. Longer digit runs (order references) must not be touched.

PII often arrives in the arguments (%s values), not in the message template, and sometimes inside an exception message logged with log.exception(...). The filter must never drop a record and must not modify the caller's objects. A redact(text) helper is part of the reference solution.

Signature: class RedactingFilter(logging.Filter): def filter(self, record: logging.LogRecord) -> bool: ...

Constraints:

• Attach it to a handler with handler.addFilter(RedactingFilter()).
• Messages may be non-strings (log.info(12345)) or contain a literal % with no args ("100% done").
• Standard library only.

Examples:

• log.info("user %s uploaded PAN %s", "ravi@corp.in", "ABCDE1234F") → INFO user <email> uploaded PAN <pan>
• log.info("call +91-9123456789 or 9123456789; ref 12345678901") → INFO call <phone> or <phone>; ref 12345678901
• log.info("order %d total ₹%.2f", 42, 1499.5) → INFO order 42 total ₹1499.50

Hints:

1. Where in a LogRecord do the %s values live, and when are they merged into the message?
2. record.getMessage() does the msg % args merge for you.
3. After you've merged and redacted, what must record.args become so the formatter doesn't merge again?
4. With log.exception, the traceback text is produced later by the formatter from record.exc_info.

Reference solution:

import logging
import re

PATTERNS = [
    (re.compile(r"\b[\w.+-]+@[\w-]+(?:\.[\w-]+)+\b"), "<email>"),
    (re.compile(r"\b[A-Z]{5}[0-9]{4}[A-Z]\b"), "<pan>"),
    (re.compile(r"(?<!\d)(?:\+91[\s-]?)?[6-9]\d{9}(?!\d)"), "<phone>"),
]


def redact(text: str) -> str:
    for pattern, label in PATTERNS:
        text = pattern.sub(label, text)
    return text


class RedactingFilter(logging.Filter):
    """Mask emails, PAN numbers and Indian mobile numbers in every record.

    Works on the *formatted* message, so PII passed as %-style args is caught too.
    Never drops a record.
    """

    def filter(self, record: logging.LogRecord) -> bool:
        message = record.getMessage()          # applies record.args
        record.msg = redact(message)
        record.args = None                     # already merged into msg
        if record.exc_info and not record.exc_text:
            record.exc_text = logging.Formatter().formatException(record.exc_info)
        if record.exc_text:
            record.exc_text = redact(record.exc_text)
        return True

Complexity: O(L) per record for message length L, times the number of patterns (three regex passes). That's negligible next to the I/O of writing the log line. No extra memory beyond the formatted string.

Tests:

import io

def make_logger(name: str) -> tuple[logging.Logger, io.StringIO]:
    stream = io.StringIO()
    handler = logging.StreamHandler(stream)
    handler.setFormatter(logging.Formatter("%(levelname)s %(message)s"))
    handler.addFilter(RedactingFilter())
    logger = logging.getLogger(name)
    logger.handlers[:] = [handler]
    logger.setLevel(logging.INFO)
    logger.propagate = False
    return logger, stream

log, out = make_logger("kyc")

log.info("signup from asha.rao@example.co.in phone 9876543210")
log.info("user %s uploaded PAN %s", "ravi@corp.in", "ABCDE1234F")
log.warning("OTP sent to %s", "+91 9876543210")
log.info("order %d total ₹%.2f", 42, 1499.5)
log.info("call +91-9123456789 or 9123456789; ref 12345678901")
user = {"email": "neha@x.in"}
log.info("profile %s", user)
try:
    raise ValueError("invalid email meera@x.in")
except ValueError:
    log.exception("KYC failed for %s", "AAAPZ9999Q")

lines = out.getvalue().splitlines()
assert lines[0] == "INFO signup from <email> phone <phone>"
assert lines[1] == "INFO user <email> uploaded PAN <pan>"
assert lines[2] == "WARNING OTP sent to <phone>"
assert lines[3] == "INFO order 42 total ₹1499.50"
assert lines[4] == "INFO call <phone> or <phone>; ref 12345678901"
assert lines[5] == "INFO profile {'email': '<email>'}"
assert lines[6] == "ERROR KYC failed for <pan>"
text = out.getvalue()
assert "meera@x.in" not in text and "<email>" in "\n".join(lines[7:])
assert "ValueError" in text                         # traceback still logged
assert user == {"email": "neha@x.in"}               # caller's objects untouched

# A message that isn't a string and a record with no args still work
log.info(12345)
log.info("100% done")
assert out.getvalue().splitlines()[-2:] == ["INFO 12345", "INFO 100% done"]

A common wrong solution (the tests catch it):

import logging
import re

PATTERNS = [
    (re.compile(r"\b[\w.+-]+@[\w-]+(?:\.[\w-]+)+\b"), "<email>"),
    (re.compile(r"\b[A-Z]{5}[0-9]{4}[A-Z]\b"), "<pan>"),
    (re.compile(r"(?<!\d)(?:\+91[\s-]?)?[6-9]\d{9}(?!\d)"), "<phone>"),
]


def redact(text: str) -> str:
    for pattern, label in PATTERNS:
        text = pattern.sub(label, text)
    return text


class RedactingFilter(logging.Filter):
    def filter(self, record: logging.LogRecord) -> bool:
        record.msg = redact(str(record.msg))   # only the template; args are merged later
        return True

Alternatives and tradeoffs:

• Redact at the source (log.info("user %s", mask(email))) is precise, but it depends on every developer remembering every time. A filter is the safety net.
• Structured logging (JSON logs with named fields) lets you drop or hash known-sensitive fields by name, which is more reliable than regex. Keep the regex filter for free text.
• Filter on the logger vs on the handler: a logger's filters only see records created on that logger, not those propagated from child loggers. Filters on the handler see everything that handler writes.

Follow-ups:

1. "Why attach the filter to the handler rather than with logging.getLogger('kyc').addFilter(...)?" Logger filters are applied only to records logged directly on that logger. A record from kyc.upload propagates to kyc's handlers without passing kyc's logger filters. Handler filters run for every record the handler emits, whichever logger it came from.
2. "What can a regex-based redactor still miss?" Formats it doesn't know: numbers with internal spaces (98765 43210), PII in other languages or encodings, data inside nested structures that a third-party library formats differently, or values written to stdout instead of through logging. Treat it as a safety net next to not logging sensitive fields in the first place.
3. "Your filter mutates record.msg and record.args. Is that safe when two handlers (console and file) share the record?" Yes for this purpose: both handlers see the redacted record, which is what you want, and the second run of the filter is harmless (args is already None). It would be a problem only if one handler had to see the raw message. Then you'd redact a copy in a custom Formatter instead.

Scoring: Strong: Redacts the merged message via getMessage(), clears args, handles exception text, never returns False, and explains handler vs logger filters. Acceptable: Works for messages and args but misses the exception traceback, or needs a hint that args are merged later. Red flag: Redacts only record.msg (the template), so PII passed as arguments leaks; or drops records by returning False.

JR-H-C03 · Deep-merge layered config without aliasing

Hard · Coding · Junior (1–3 years) · mutability, aliasing, copy.deepcopy, recursion, configuration · 20 min

Problem:

A service builds its settings from layers: base.yaml, then prod.yaml, then environment overrides. Write deep_merge(base, override) that returns a new dict with override layered on top of base:

• if both sides have a dict under the same key, merge them recursively;
• any other override value (lists included) replaces the base value;
• an override value of the sentinel DELETE removes the key;
• neither input may be changed, and the result must not share any mutable object (nested dicts or lists) with the inputs. The same base is reused to build configs for several environments, so a later change to one result must never leak into another.

Signature: def deep_merge(base: dict[str, Any], override: dict[str, Any]) -> dict[str, Any]:

Constraints:

• Values are JSON-like: dicts, lists, strings, numbers, booleans, None.
• DELETE = object() is defined next to the function.
• Standard library only.

Examples:

• deep_merge({"db": {"host": "localhost", "port": 5432}}, {"db": {"host": "prod-db"}}) → {"db": {"host": "prod-db", "port": 5432}}
• deep_merge({"features": ["upi", "cod"]}, {"features": ["upi"]}) → {"features": ["upi"]}
• deep_merge({"debug": True, "a": 1}, {"debug": DELETE}) → {"a": 1}

Hints:

1. dict(base) copies only the top level. What do the nested dicts in the copy point to?
2. Start from copy.deepcopy(base) and then recurse for keys where both sides are dicts.
3. Values taken from override need copying too: think about the lists.

Reference solution:

import copy
from typing import Any

DELETE = object()   # sentinel: an override value that removes the key


def deep_merge(base: dict[str, Any], override: dict[str, Any]) -> dict[str, Any]:
    """Return a NEW dict: `override` layered on top of `base`.

    - nested dicts are merged key by key;
    - any other value (lists included) in `override` replaces the base value;
    - the sentinel DELETE removes the key;
    - neither input is mutated, and the result shares no mutable objects with them.
    """
    result = copy.deepcopy(base)
    for key, value in override.items():
        if value is DELETE:
            result.pop(key, None)
        elif isinstance(value, dict) and isinstance(result.get(key), dict):
            result[key] = deep_merge(result[key], value)
        else:
            result[key] = copy.deepcopy(value)
    return result

Complexity: O(size of base + size of override) time and space: every value is visited and copied once. Recursion depth equals the nesting depth of the config, which is small.

Tests:

import copy

base = {
    "db": {"host": "localhost", "port": 5432, "pool": {"min": 1, "max": 5}},
    "features": ["upi", "cod"],
    "region": "ap-south-1",
    "debug": True,
}
prod = {
    "db": {"host": "prod-db.internal", "pool": {"max": 50}},
    "features": ["upi"],
    "debug": DELETE,
    "sentry": {"dsn": "https://x@sentry.example/1"},
}
base_snapshot = copy.deepcopy(base)
prod_snapshot = {k: v for k, v in prod.items() if v is not DELETE}

merged = deep_merge(base, prod)
assert merged == {
    "db": {"host": "prod-db.internal", "port": 5432, "pool": {"min": 1, "max": 50}},
    "features": ["upi"],
    "region": "ap-south-1",
    "sentry": {"dsn": "https://x@sentry.example/1"},
}
# Inputs untouched
assert base == base_snapshot
assert {k: v for k, v in prod.items() if v is not DELETE} == prod_snapshot

# No shared mutable objects: mutating the result must not leak back
merged["db"]["pool"]["min"] = 99
merged["features"].append("emi")
merged["sentry"]["dsn"] = "changed"
assert base["db"]["pool"]["min"] == 1 and base["features"] == ["upi", "cod"]
assert prod["features"] == ["upi"] and prod["sentry"]["dsn"] == "https://x@sentry.example/1"

# Untouched nested sections are copies too
only_region = deep_merge(base, {"region": "ap-south-2"})
only_region["db"]["port"] = 1
assert base["db"]["port"] == 5432

# Type changes: a dict replaces a scalar and vice versa
assert deep_merge({"cache": "off"}, {"cache": {"ttl": 60}}) == {"cache": {"ttl": 60}}
assert deep_merge({"cache": {"ttl": 60}}, {"cache": None}) == {"cache": None}
assert deep_merge({}, {"gone": DELETE}) == {}
assert deep_merge({"a": 1}, {}) == {"a": 1}

A common wrong solution (the tests catch it):

DELETE = object()


def deep_merge(base, override):
    result = dict(base)                       # shallow copy
    for key, value in override.items():
        if value is DELETE:
            result.pop(key, None)
        elif isinstance(value, dict) and isinstance(result.get(key), dict):
            result[key].update(deep_merge(result[key], value))   # mutates base's nested dict
        else:
            result[key] = value
    return result

Alternatives and tradeoffs:

• Copy only on write (build new dicts along the merged path and share untouched subtrees) is cheaper for huge configs, but the result then aliases the inputs. That's acceptable only if everyone treats configs as read-only, which is hard to enforce in Python.
• collections.ChainMap layers dicts for lookups without copying, but it is shallow: nested dicts aren't merged.
• Freezing the result (e.g. converting to types.MappingProxyType/tuples, or loading into a frozen Pydantic settings model) prevents later mutation altogether and turns aliasing bugs into immediate errors.

Follow-ups:

1. "Why does the broken version pass a simple equality test on the merged result but still cause a production bug?" Its output is correct, but it achieves it by mutating base's nested dicts in place (result[key].update(...) on a shallow copy). The first environment's overrides leak into base, so the second config built from the same base silently contains production hosts or pool sizes. Only a test that checks the inputs afterwards catches it.
2. "Should lists be merged (concatenated) instead of replaced?" Usually not by default: you can't remove an item via concatenation, and order or duplicates become ambiguous. Replacing is predictable. If a key genuinely needs appending, make it explicit (a special +features key or a documented per-key rule).
3. "When is copy.deepcopy the wrong tool?" For objects holding resources (locks, open files, sockets, DB connections), which can't or shouldn't be copied, and for very large structures where the cost matters. For plain JSON-like config it is the simplest correct choice.

Scoring: Strong: Recursive merge on a deep copy, copies override values too, handles DELETE and type changes, and explains the shared-nested-dict bug without prompting. Acceptable: Correct merge results but mutates or aliases one input; fixes it once shown the test that mutates the result. Red flag: Uses dict.update at the top level only (no recursion), or doesn't see why mutating base is a problem.

JR-HT-O01 · `+=` on a list inside a "constant" tuple

Hard & Tricky · Output · Junior (1–3 years) · mutability, aliasing, tuples, augmented assignment, exceptions · 10 min

Question: DEFAULT_ROUTE is meant to be a constant: origin airport plus a list of stops. What does this print?

DEFAULT_ROUTE = ("BLR", ["MAA"])

route = DEFAULT_ROUTE
try:
    route[1] += ["HYD"]
except TypeError as exc:
    print("TypeError:", exc)
print(route)
print(DEFAULT_ROUTE)

stops = route[1]
stops = stops + ["PNQ"]
print(route[1], stops)

frozen = ("DEL", ("JAI",))
backup = frozen
try:
    frozen[1] += ("AGR",)
except TypeError as exc:
    print("TypeError:", exc)
print(frozen, backup is frozen)

Expected output:

TypeError: 'tuple' object does not support item assignment
('BLR', ['MAA', 'HYD'])
('BLR', ['MAA', 'HYD'])
['MAA', 'HYD'] ['MAA', 'HYD', 'PNQ']
TypeError: 'tuple' object does not support item assignment
('DEL', ('JAI',)) True

The trap: Two tempting answers, both wrong. (1) "It raises TypeError, so nothing changed: ('BLR', ['MAA'])." (2) "Tuples hold lists fine, so += just works with no error." In fact it both raises and mutates the list.

Explanation:

route[1] += ["HYD"] is not one operation. Python runs it as:

1. tmp = route[1]: fetch the list;
2. tmp = tmp.__iadd__(["HYD"]): for a list, += extends it in place and returns the same list;
3. route[1] = tmp: store the result back into the tuple, which raises TypeError because tuples don't support item assignment.

Step 2 already happened before step 3 failed, so the list now contains HYD even though you saw an exception. route and DEFAULT_ROUTE are two names for one tuple, so the "constant" is changed for every user of it.

stops = stops + ["PNQ"] is different: + builds a new list and rebinds only the local name stops, so the tuple's list is untouched.

With a tuple inside the tuple, += has no in-place version (tuples are immutable), so step 2 builds a new tuple, and step 3 fails before anything is stored. Nothing changes, and backup is frozen is still True.

Takeaway: a tuple freezes which objects it holds, not the objects themselves. x += y means "maybe mutate, then always assign back", and it can do the first half and fail on the second.

Follow-ups:

1. "How would you make DEFAULT_ROUTE genuinely immutable?" Use immutable contents all the way down: ("BLR", ("MAA",)), a frozenset for unordered data, or a @dataclass(frozen=True) whose fields are tuples. For dict-shaped constants, types.MappingProxyType gives a read-only view. Code that needs to modify it builds a new value: stops = [*DEFAULT_ROUTE[1], "HYD"].
2. "Would route[1].extend(["HYD"]) behave differently?" It mutates the same list but raises no error, because there's no assignment back into the tuple. That's worse in a way: the += version at least makes noise, while .extend corrupts the shared default silently.
3. "Can ("BLR", ["MAA"]) be used as a dict key or put in a set?" No. Hashing a tuple hashes its elements, and a list is unhashable: TypeError: unhashable type: 'list'. It's another sign that this 'constant' isn't really immutable.

Scoring: Strong: Predicts both the TypeError and the mutation, explains the fetch / __iadd__ / store-back steps, and contrasts + with += and the tuple-in-tuple case. Acceptable: Gets the mutation after some thought but is unsure about the nested-tuple case; reasons it out when asked whether tuples have an in-place +=. Red flag: Insists the error means nothing changed, or that the tuple itself was modified.

JR-HT-O02 · Class attributes inside a comprehension in the class body

Hard & Tricky · Output · Junior (1–3 years) · scope, LEGB, class body scope, comprehensions, configuration classes · 10 min

Question: A settings class pre-computes GST-inclusive prices. What does this print?

class PriceConfig:
    GST = 0.18
    BASE = [100, 250, 400]
    WITH_GST = [round(p * (1 + 0.18)) for p in BASE]
    LABELS = {p: "low" if p < 200 else "high" for p in BASE}
    try:
        TOTALS = [round(p * (1 + GST)) for p in BASE]
    except NameError as exc:
        print("NameError:", exc)
        TOTALS = None

print(PriceConfig.WITH_GST)
print(PriceConfig.LABELS)
print(PriceConfig.TOTALS)

Expected output:

NameError: name 'GST' is not defined
[118, 295, 472]
{100: 'low', 250: 'high', 400: 'high'}
None

The trap: "[118, 295, 472] for TOTALS too: GST is defined two lines above, in the same block." The usual second mistake is expecting BASE to fail as well, or the NameError line to be printed last.

Explanation:

A class body runs once, top to bottom, when the class statement executes. That's why the NameError line appears first, before any of the print calls below the class.

The class body has its own namespace, but it is not an enclosing scope for anything nested inside it. Functions, lambdas and comprehensions defined in the body can't see the class's names; LEGB lookup goes local → enclosing function scopes → global → builtins and skips the class. (That's why methods have to say self.GST or cls.GST.)

A comprehension behaves like a nested function, with one exception: its outermost iterable (BASE in for p in BASE) is evaluated in the surrounding scope, the class body, before the comprehension starts. So:

• WITH_GST works: BASE is the outermost iterable, and the body uses only p and literals.
• LABELS works for the same reason.
• TOTALS fails: GST is used inside the comprehension, looked up from the comprehension's scope, which skips the class body. It isn't a global, so NameError.

Python 3.12 made comprehensions faster by inlining them (PEP 709) but deliberately kept this behaviour.

Takeaway: inside a class body, only the first for ... in X of a comprehension can see class attributes; compute derived constants at module level or in a method instead.

Follow-ups:

1. "Would [round(p * (1 + g)) for g in [GST] for p in BASE] fix it?" No. Only the first iterable ([GST]) is evaluated in the class body. The second for p in BASE is evaluated inside the comprehension, so it now raises NameError: name 'BASE' is not defined. The trick works for exactly one name, which is a sign you shouldn't rely on it.
2. "What are the clean fixes?" Define the constants at module level (GST = 0.18 then use it in the class), compute TOTALS after the class (PriceConfig.TOTALS = [...]), or make it a method or property that uses self.GST and self.BASE. For real settings, a Pydantic settings model with a computed field is clearer.
3. "Does a plain for loop in the class body have the same problem?" No: a for statement isn't a new scope, so for p in BASE: totals.append(round(p * (1 + GST))) works in the class body. The catch is that the loop variable p then becomes a class attribute (PriceConfig.p == 400).

Scoring: Strong: Correct output including the order of lines; explains that class bodies aren't enclosing scopes and that the outermost iterable is the one exception. Acceptable: Spots that TOTALS fails but can't explain why BASE works; gets there when asked when the iterable is evaluated. Red flag: Expects all three to work, or thinks the comprehension sees class attributes the same way a method sees globals.

JR-HT-O03 · Closures that mutate fine but break on `+=`

Hard & Tricky · Output · Junior (1–3 years) · closures, scope, nonlocal, UnboundLocalError, augmented assignment · 10 min

Question: A tracker factory returns three small closures. What does this print?

def make_tracker():
    count = 0
    seen = []

    def track_append(order_id):
        seen.append(order_id)
        return len(seen)

    def track_count(order_id):
        print("tracking", order_id)
        count += 1
        return count

    def track_extend(order_id):
        seen += [order_id]
        return len(seen)

    return track_append, track_count, track_extend, seen

track_append, track_count, track_extend, seen = make_tracker()
print(track_append("ORD-1"), track_append("ORD-2"))
for fn in (track_count, track_extend):
    try:
        fn("ORD-3")
    except NameError as exc:
        print(type(exc).__name__, "-", exc)
print(seen)

Expected output:

1 2
tracking ORD-3
UnboundLocalError - cannot access local variable 'count' where it is not associated with a value
UnboundLocalError - cannot access local variable 'seen' where it is not associated with a value
['ORD-1', 'ORD-2']

The trap: "track_count returns 1 and track_extend works, because list += mutates in place, so seen ends as ['ORD-1', 'ORD-2', 'ORD-3']." A second common slip is expecting the error when the function is defined, so "tracking ORD-3" is left out.

Explanation:

Whether a name is local is decided when the function is compiled, not when the line runs: any assignment to a name anywhere in a function makes it local to the whole function, unless it is declared nonlocal or global.

• track_append only reads seen and calls a method on it. There's no assignment, so seen is the closure variable from make_tracker, and appending mutates that shared list: 1 2.
• track_count contains count += 1, which is an assignment, so count is local to track_count. The function starts normally (hence tracking ORD-3), then count += 1 must first read the local count, which has no value yet, so UnboundLocalError.
• track_extend is the subtle one. seen += [x] is also an assignment (load, __iadd__, store back), so seen is local to track_extend too. The read fails before __iadd__ runs, so no mutation happens and seen is unchanged.
• UnboundLocalError is a subclass of NameError, which is why except NameError catches both.

Fixes: declare nonlocal count in track_count; in track_extend, either nonlocal seen or, better, seen.extend([order_id]), which mutates without assigning.

Takeaway: in a closure, calling methods on a captured object is fine; any assignment to the captured name (=, +=, even on a list) needs nonlocal.

Follow-ups:

1. "Why does seen.append(x) work but seen += [x] doesn't, when both mutate the same list?" Scope is about names, not objects. seen.append only looks the name up. seen += ... also rebinds the name (the store-back step), and any rebinding makes the name local unless declared nonlocal.
2. "Where does the same mechanism bite in everyday code outside closures?" With module-level globals: a function that does total += amount on a global total raises UnboundLocalError unless it says global total. A function that only reads the global, or does cache[key] = value on a global dict, works fine.
3. "Rewrite the counter so no nonlocal is needed. Is that better?" A small class with self.count += 1, or itertools.count() with next(counter), avoids rebinding a captured name. A class is clearer once there's more than one piece of state; nonlocal is fine for a tiny closure.

Scoring: Strong: All five lines; explains the compile-time local decision, why += on a list still fails, why seen is unchanged, and that UnboundLocalError is a NameError. Acceptable: Gets track_count right (knows the nonlocal rule) but expects track_extend to work; understands once += is spelled out as read, extend, store back. Red flag: Thinks closures copy variables at creation time, or can't say why track_append works.

JR-HT-O04 · Mock side_effect lists, DEFAULT and reset_mock in a retry test

Hard & Tricky · Output · Junior (1–3 years) · testing, unittest.mock, side_effect, return_value, retries · 10 min

Question: A test drives a retry helper with a mocked HTTP client. What does this print?

from unittest.mock import DEFAULT, Mock

def order_status(client, order_id, attempts=3):
    for _ in range(attempts):
        try:
            return client.get(f"/orders/{order_id}")["status"]
        except TimeoutError as exc:
            print("retrying:", exc)
    return "UNKNOWN"

client = Mock()
client.get.return_value = {"status": "SHIPPED"}
client.get.side_effect = [TimeoutError("gateway slow"), {"status": "PAID"}]
print(order_status(client, 7))
print(client.get.call_count, client.get.call_args)

try:
    order_status(client, 8)
except StopIteration:
    print("StopIteration")

client.get.side_effect = lambda path: DEFAULT if path.endswith("9") else {"status": "NEW"}
print(order_status(client, 9), order_status(client, 10))

client.get.side_effect = TimeoutError("bank down")
client.get.reset_mock()
print(order_status(client, 11), client.get.call_count)

Expected output:

retrying: gateway slow
PAID
2 call('/orders/7')
StopIteration
SHIPPED NEW
retrying: bank down
retrying: bank down
retrying: bank down
UNKNOWN 3

The trap: "SHIPPED on the first call, since return_value is set", then "order_status(client, 8) falls back to return_value" once the list runs out, and "reset_mock() clears the side effect, so the last line is SHIPPED 1". All three are wrong.

Explanation:

side_effect takes priority over return_value. Its meaning depends on what you assign:

• An iterable: each call takes the next item. An item that is an exception (instance or class) is raised; anything else is returned. Call 1 raises TimeoutError (the helper prints and retries), call 2 returns {"status": "PAID"}. That's 2 calls, the last with '/orders/7'.
• When the iterable is used up, the next call raises StopIteration. It does not fall back to return_value. StopIteration isn't a TimeoutError, so it escapes order_status entirely. In a real test suite this shows up as a baffling StopIteration far from the cause: the code made one more call than the test planned for.
• A function: it is called with the same arguments and its result is returned, unless it returns the sentinel mock.DEFAULT, in which case return_value is used. So order 9 gets SHIPPED and order 10 gets NEW.
• An exception: raised on every call, so all three attempts fail and the helper returns UNKNOWN.
• reset_mock() clears call history (call_count, call_args) but by default keeps return_value and side_effect. The count restarts at 0 and ends at 3, and the side effect is still active.

Takeaway: use side_effect lists to script sequences such as "fail, then succeed", and remember that running past the end raises StopIteration and that reset_mock() doesn't undo configuration.

Follow-ups:

1. "How would you assert that the helper retried exactly three times with the same path?" assert client.get.call_args_list == [call('/orders/11')] * 3 (with from unittest.mock import call), or client.get.assert_called_with('/orders/11') plus client.get.call_count == 3. call_args_list is the most precise because it checks every call, not just the last.
2. "How do you clear the configuration too?" client.get.reset_mock(return_value=True, side_effect=True), or simply create a fresh Mock() per test, which is cleaner. pytest fixtures make that natural.
3. "A teammate's test passes even though the code calls client.fetch(...) instead of client.get(...). Why, and what prevents it?" A bare Mock invents any attribute you ask for, so client.fetch silently exists. create_autospec(RealClient, instance=True) or Mock(spec=RealClient) makes unknown attributes raise AttributeError and checks call signatures.

Scoring: Strong: Every line right; explains side_effect precedence, iterable exhaustion raising StopIteration, the DEFAULT sentinel, and that reset_mock keeps configuration. Acceptable: Gets the first block and the exception side effect; misses StopIteration or the reset_mock detail but reasons correctly once told. Red flag: Believes return_value wins over side_effect, or doesn't know how to make a mock raise an exception.

JR-HT-O05 · Operator precedence in a pandas filter: `&` before `>`

Hard & Tricky · Output · Junior (1–3 years) · pandas, boolean indexing, operator precedence, bitwise operators, chained comparisons · 10 min

Question: A dashboard wants "orders above ₹500 paid by cash on delivery". What does this print?

import pandas as pd

df = pd.DataFrame({
    "city": ["Pune", "Delhi", "Pune", "Chennai"],
    "amount": [1200, 300, 4500, 800],
    "is_cod": [True, False, False, True],
})

print(df[(df.amount > 500) & df.is_cod].index.tolist())
print(df[df.amount > 500 & df.is_cod].index.tolist())
print((500 & df.is_cod).tolist())

try:
    df[df.amount > 500 & df.amount < 2000]
except ValueError as exc:
    print("ValueError:", exc)
print(df[(df.amount > 500) & (df.amount < 2000)].index.tolist())

Expected output:

[0, 3]
[0, 1, 2, 3]
[False, False, False, False]
ValueError: The truth value of a Series is ambiguous. Use a.empty, a.bool(), a.item(), a.any() or a.all().
[0, 3]

The trap: "The second line is the same as the first, [0, 3]" (reading it the way a person would), or "it raises an error". It runs without complaint and returns every row.

Explanation:

In Python, & and | bind more tightly than comparison operators. pandas overloads them for element-wise AND/OR, but it can't change their precedence.

• df.amount > 500 & df.is_cod parses as df.amount > (500 & df.is_cod). 500 & True is a bitwise AND of 500 and 1. 500 is even, so its lowest bit is 0 and the result is 0; 500 & False is also 0. pandas returns these as a boolean Series of all False, as the third line shows. Then df.amount > False compares every amount with 0, which is true for every row. The filter silently returns all orders.
• df.amount > 500 & df.amount < 2000 parses as df.amount > (500 & df.amount) < 2000, which is a chained comparison: Python expands a > b < c into (a > b) and (b < c). and calls bool() on the first Series, and pandas refuses to decide whether a whole Series is "true", so you get the ValueError.
• With parentheses around each comparison, both filters give [0, 3] (Pune ₹1,200 COD and Chennai ₹800 COD).

This is also why and/or don't work on Series at all: they can't be overloaded, so they always call bool().

Takeaway: in pandas masks, parenthesise every comparison, or build named masks first. A wrong mask doesn't always raise; sometimes it just returns the wrong rows.

Follow-ups:

1. "How would you write this filter so the mistake can't happen?" Named masks: high = df.amount > 500 and then df[high & df.is_cod]. Or df.query("amount > 500 and is_cod"), where and works because query parses its own expression language. For ranges, df.amount.between(500, 2000) (inclusive at both ends by default).
2. "What does ~ do on a column of 0/1 integers instead of booleans?" Bitwise NOT: ~1 is -2 and ~0 is -1, both truthy. Using such a column as a mask then fails, or misbehaves after a cast. Convert flags to bool dtype on load (df['is_cod'].astype(bool)) before using ~, & or |.
3. "How would a test have caught the silent version?" Assert on the result for a tiny fixture where you know the answer, e.g. assert filter_orders(df).index.tolist() == [0, 3], and include rows that should be excluded (a small COD order, a large prepaid one). A test with only matching rows can't tell the right mask from 'everything'.

Scoring: Strong: Gets line 2 as all rows and explains it via precedence plus bitwise 500 & True == 0; recognises the chained comparison behind the ValueError. Acceptable: Knows parentheses are required and predicts an error or a wrong result, but can't explain exactly which; follows the precedence explanation once given. Red flag: Expects and to work on Series, or reads line 2 as "COD orders above 500".

JR-HT-O06 · A local statistics.py shadows the standard library, but os.py doesn't

Hard & Tricky · Output · Junior (1–3 years) · imports, sys.path, sys.modules, module shadowing, project layout · 10 min

Question: A teammate left two scratch files, statistics.py and os.py, in the same folder as this script. The snippet creates them so it is self-contained. What does it print?

import importlib
import pathlib
import sys

# A teammate left two scratch files next to this script
pathlib.Path("statistics.py").write_text(
    'print("loading local statistics.py")\n'
    "def mean(values):\n"
    "    return 'not the real mean'\n"
)
pathlib.Path("os.py").write_text('print("loading local os.py")\n')
importlib.invalidate_caches()

print("os" in sys.modules, "statistics" in sys.modules)
import os
import statistics

print(statistics.mean([10, 20, 60]))
print(os.path.basename(statistics.__file__), os.sep)
try:
    from statistics import median
except ImportError as exc:
    print(type(exc).__name__, "-", exc.name)

del sys.modules["statistics"]
sys.path.remove(sys.path[0])
import statistics
print(statistics.mean([10, 20, 60]))

Expected output:

True False
loading local statistics.py
not the real mean
statistics.py /
ImportError - statistics
30

The trap: Either "the standard library always wins, so mean returns 30 and nothing local loads", or "both local files are picked up, so loading local os.py prints and os.sep fails". Only statistics is shadowed.

Explanation:

import x looks in two places, in this order:

1. sys.modules, the cache of modules already imported in this process. If x is there, Python reuses it and searches nothing.
2. Otherwise, the directories on sys.path, in order. When you run a script, sys.path[0] is the script's own directory, so it is searched before the standard library.

os was already imported while the interpreter started up (the site module needs it), so it is in sys.modules and import os returns the real module; the local os.py is never even looked at. statistics wasn't imported yet, so the search starts at the script's folder, finds the scratch statistics.py, and runs it, printing its message. mean is now the fake one.

from statistics import median fails with ImportError because the local module has no median; exc.name is the module that was searched. In real projects the message often mentions a "partially initialized module ... (most likely due to a circular import)", which sends people hunting for circular imports that don't exist.

Removing the cached module and the script directory from sys.path makes the next import find the real standard library, so mean is 30.

Takeaway: never name your own files after standard-library or installed packages (random.py, email.py, logging.py, pandas.py). When an import behaves strangely, print module.__file__ first.

Follow-ups:

1. "A colleague says import pandas gives AttributeError: module 'pandas' has no attribute 'DataFrame'. What's your first check?" python -c "import pandas; print(pandas.__file__)" from the same directory. If it points to their own pandas.py (or a pandas/ folder) in the project, that's the cause. Rename it and delete any stale __pycache__. If the path is right, check that they're using the venv's interpreter (which python, python -m pip show pandas).
2. "Is there a way to stop the script's directory being put on sys.path?" Yes, since Python 3.11: python -P script.py or the environment variable PYTHONSAFEPATH=1. The cleaner structural fix is a src/ layout with an installed package, so tests and tools import the installed code rather than whatever sits in the current folder.
3. "How does python -m app.main differ from python app/main.py for imports?" With -m, the current working directory goes at the front of sys.path and app.main runs as part of the package, so from app import config works. Running the file path puts app/ itself first, which breaks absolute package imports and makes shadowing by files inside app/ more likely.

Scoring: Strong: All six lines; explains the sys.modules cache before the sys.path search, why os is immune here, and that the script directory comes first. Acceptable: Knows local files can shadow stdlib modules but expects os.py to be loaded too; understands once told os is imported at startup. Red flag: Thinks the standard library always takes priority, or has never debugged an import by checking __file__.

JR-HT-C01 · A decorator that enforces type hints at runtime

Hard & Tricky · Coding · Junior (1–3 years) · typing, decorators, inspect.signature, get_type_hints, validation · 30 min

Problem:

Type hints aren't checked at runtime. For a handful of internal functions that receive data straight from JSON, your lead wants a small @enforce_types decorator (no Pydantic in this service) that checks arguments and the return value against the function's hints and raises TypeError naming the offending parameter.

Requirements:

• Check every annotated parameter, however it was passed (positionally, by keyword, or left at its default). Unannotated parameters are not checked.
• Supported hints: plain classes (int, str, float, your own classes), X | None, Optional[X] and other unions, None, Any, and parameterised generics such as list[float] (check the container type only, not the elements).
• bool must not pass for int or float (JSON true must not become quantity 1), but an int is accepted for float, following the usual typing rule.
• For *args: T check each positional extra; for **kwargs: T check each value.
• Check the return value if there is a return annotation.
• Hints may be strings / forward references to classes defined after the decorated function.
• Keep the function's name and docstring.

Signature: def enforce_types(func: Callable[P, R]) -> Callable[P, R]:

Constraints:

• Standard library only (inspect, typing, functools, types).
• Calling with the wrong number of arguments must still raise TypeError as a normal call would.
• The error message must contain the parameter name (e.g. qty, tags[1], return value).

Examples:

• add_item("TEA-250", 2, 149.5) → 299.0
• add_item("TEA-250", qty="2") → TypeError: add_item(): qty must be <class 'int'>, got str
• add_item("TEA-250", True, 10.0) → TypeError (bool is not accepted for int)
• invoice_total(inv: "Invoice") where Invoice is defined later; invoice_total(Invoice(500.0)) → 500.0

Hints:

1. zip(annotations, args) misses keyword arguments and defaults. What in inspect maps every argument to its parameter name?
2. sig.bind(*args, **kwargs) followed by apply_defaults() gives you bound.arguments.
3. isinstance(True, int) is True. Handle bool before the general check.
4. typing.get_origin / get_args take apart int | None and list[float].
5. If you call get_type_hints in the decorator itself, what happens with a forward reference to a class that doesn't exist yet?

Reference solution:

import functools
import inspect
import types
from collections.abc import Callable
from typing import Any, ParamSpec, TypeVar, Union, get_args, get_origin, get_type_hints

P = ParamSpec("P")
R = TypeVar("R")


def _matches(value: Any, hint: Any) -> bool:
    if hint is Any:
        return True
    if hint is None or hint is type(None):
        return value is None
    origin = get_origin(hint)
    if origin is Union or origin is types.UnionType:
        return any(_matches(value, h) for h in get_args(hint))
    if origin is not None:                       # list[int], dict[str, float]: container type only
        return isinstance(value, origin)
    if isinstance(value, bool) and hint is not bool:
        return False                             # bool is an int subclass; don't let True pass as 1
    if hint is float:
        return isinstance(value, (int, float))   # PEP 484: int is acceptable where float is expected
    return isinstance(value, hint)


def enforce_types(func: Callable[P, R]) -> Callable[P, R]:
    sig = inspect.signature(func)
    hints: dict[str, Any] | None = None          # resolved lazily: forward refs may not exist yet

    def check(name: str, value: Any, hint: Any) -> None:
        if not _matches(value, hint):
            raise TypeError(f"{func.__name__}(): {name} must be {hint!r}, got {type(value).__name__}")

    @functools.wraps(func)
    def wrapper(*args: P.args, **kwargs: P.kwargs) -> R:
        nonlocal hints
        if hints is None:
            hints = get_type_hints(func)
        bound = sig.bind(*args, **kwargs)        # raises TypeError for bad arity, like a normal call
        bound.apply_defaults()
        for name, value in bound.arguments.items():
            if name not in hints:
                continue
            kind = sig.parameters[name].kind
            if kind is inspect.Parameter.VAR_POSITIONAL:
                for i, item in enumerate(value):
                    check(f"{name}[{i}]", item, hints[name])
            elif kind is inspect.Parameter.VAR_KEYWORD:
                for key, item in value.items():
                    check(f"{name}[{key!r}]", item, hints[name])
            else:
                check(name, value, hints[name])
        result = func(*args, **kwargs)
        if "return" in hints:
            check("return value", result, hints["return"])
        return result

    return wrapper

Complexity: Per call: O(number of parameters) checks, plus O(n) for *args/**kwargs with n extras. Union checks are proportional to the number of union members. inspect.signature is computed once at decoration time, and the type hints once on the first call.

Tests:

from typing import Any, Optional

def raises(fn, *args, **kwargs) -> str:
    try:
        fn(*args, **kwargs)
    except TypeError as exc:
        return str(exc)
    raise AssertionError("expected TypeError")

@enforce_types
def add_item(sku: str, qty: int, price: float = 0.0, note: str | None = None) -> float:
    """Add a line item."""
    return qty * price

assert add_item("TEA-250", 2, 149.5) == 299.0
assert add_item("TEA-250", qty=3, price=100) == 300                 # int is fine for float
assert add_item(sku="TEA-250", qty=1, note=None) == 0.0
assert "qty" in raises(add_item, "TEA-250", True, 10.0)             # bool is not an int here
assert "qty" in raises(add_item, "TEA-250", qty="2")                # keyword args are checked
assert "price" in raises(add_item, "TEA-250", 1, price=True)
assert "note" in raises(add_item, "TEA-250", 1, note=42)
assert "sku" in raises(add_item, 101, 1)
raises(add_item, "TEA-250")                                         # missing arg: still a TypeError
assert add_item.__name__ == "add_item" and add_item.__doc__ == "Add a line item."

@enforce_types
def bad_total(amounts: list[float]) -> int:
    return sum(amounts)

assert bad_total([1, 2]) == 3
assert "return" in raises(bad_total, [1.5, 2.0])                    # returns float, promised int
assert "amounts" in raises(bad_total, (1, 2))                       # tuple is not a list

@enforce_types
def tag_all(*tags: str, **meta: int) -> None:
    pass

tag_all("vip", "diwali", visits=3)
assert "tags[1]" in raises(tag_all, "vip", 7)
assert "meta" in raises(tag_all, "vip", visits="3")

@enforce_types
def flag(enabled: bool, reason: Optional[str] = None, extra: Any = None) -> None:
    pass

flag(True, "manual", extra=object())
assert "enabled" in raises(flag, 1)

# Forward reference to a class defined AFTER the decorated function
@enforce_types
def invoice_total(inv: "Invoice") -> float:
    return inv.amount

class Invoice:
    def __init__(self, amount: float) -> None:
        self.amount = amount

assert invoice_total(Invoice(500.0)) == 500.0
assert "inv" in raises(invoice_total, {"amount": 500.0})

@enforce_types
def untyped(a, b: int = 1):
    return a

assert untyped("anything") == "anything"

A common wrong solution (the tests catch it):

import functools


def enforce_types(func):
    hints = func.__annotations__

    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        for (name, hint), value in zip(hints.items(), args):     # positional args only
            if isinstance(hint, type) and not isinstance(value, hint):
                raise TypeError(f"{func.__name__}(): {name} must be {hint.__name__}")
        return func(*args, **kwargs)

    return wrapper

Alternatives and tradeoffs:

• Pydantic's @validate_call does this properly, including coercion, nested element validation and good error messages. Prefer it wherever adding Pydantic is acceptable.
• typeguard checks hints at runtime, including generic element types; it's handy in tests or at module boundaries.
• Validate at the boundary only: parse the JSON into a Pydantic model or dataclass once, and let static type checking (mypy/pyright) cover the internal calls. Runtime checks on every internal call cost CPU and duplicate what the type checker already proves.

Follow-ups:

1. "Why resolve the hints lazily, on the first call, instead of when decorating?" get_type_hints evaluates string annotations. If "Invoice" is defined further down the module, evaluating at decoration time raises NameError. By the first call the module has finished importing and the name exists. Caching the result keeps the cost to one evaluation.
2. "Your decorator accepts ["a", "b"] for amounts: list[float]. Is that acceptable?" It's a documented limitation: checking elements means walking the whole container on every call, which is O(n) and gets tricky for nested or lazy types (iterators can't be checked without consuming them). For boundary data, validate elements once with Pydantic. Inside the codebase, rely on mypy.
3. "What would you have to change to support Literal["UPI", "CARD"]?" Detect get_origin(hint) is Literal and check value in get_args(hint), with an exact type check so that True doesn't match a literal 1. Without that branch, the generic-origin path would call isinstance(value, Literal), which raises TypeError.

Scoring: Strong: Uses inspect.signature().bind with defaults, handles unions, None, Any and generics, rejects bool for int, checks *args/**kwargs and the return value, and resolves forward references lazily, explaining each choice. Acceptable: Correct for positional and keyword arguments and simple classes using bind; misses the bool rule or forward references until a test shows it. Red flag: Zips __annotations__ with positional args only, or relies on isinstance(value, hint) for every hint (crashing on int | None or list[float]).

JR-HT-C02 · Signed, expiring session tokens with HMAC

Hard & Tricky · Coding · Junior (1–3 years) · auth basics, hmac, hashlib, base64, json, security · 30 min

Problem:

An internal tool needs simple stateless session tokens: after login the server issues a token, and later requests present it. Write two functions:

• make_token(user_id, expires_at, secret) returns a token: the base64url-encoded JSON payload {"exp": ..., "sub": ...} (no = padding), a ., and the base64url HMAC-SHA256 signature of the encoded payload.
• verify_token(token, secret, now) returns the user_id if the token is authentic and not expired, and otherwise raises InvalidToken.

Rules for verify_token:

• The signature must cover the whole payload, so a client can't change the user id or extend exp.
• Compare signatures in constant time.
• A token is expired when now >= exp.
• Any malformed input (wrong number of parts, non-ASCII characters, bad base64, payload that isn't a JSON object, missing or wrongly typed claims) raises InvalidToken. No KeyError, binascii.Error, UnicodeEncodeError or JSONDecodeError may leak to the caller.
• User ids may contain dots (asha.rao@corp.in).

now and expires_at are integer Unix timestamps passed in explicitly, so the functions are testable.

Signature: def make_token(user_id: str, expires_at: int, secret: bytes) -> str: def verify_token(token: str, secret: bytes, now: int) -> str:

Constraints:

• Standard library only (hmac, hashlib, base64, json).
• make_token must be deterministic for the same inputs (use sort_keys=True and compact separators).
• Define class InvalidToken(Exception).

Examples:

• verify_token(make_token("asha.rao@corp.in", NOW + 900, SECRET), SECRET, NOW) → "asha.rao@corp.in"
• same token verified at now = NOW + 900 → InvalidToken (expired)
• payload re-encoded with a later exp, original signature kept → InvalidToken (bad signature)
• verify_token("ünï.cödé", SECRET, NOW) → InvalidToken (not a UnicodeEncodeError)

Hints:

1. What exactly do you sign? Sign the encoded payload string, not just the user id.
2. hmac.compare_digest instead of ==, and why?
3. base64url without padding: add back '=' * (-len(s) % 4) before decoding.
4. Verify the signature before trusting or even parsing the payload.
5. List every exception that parsing can raise and convert each one to InvalidToken.

Reference solution:

import base64
import binascii
import hashlib
import hmac
import json


class InvalidToken(Exception):
    pass


def _b64e(raw: bytes) -> str:
    return base64.urlsafe_b64encode(raw).rstrip(b"=").decode("ascii")


def _b64d(text: str) -> bytes:
    return base64.urlsafe_b64decode(text + "=" * (-len(text) % 4))


def _sign(payload_b64: str, secret: bytes) -> str:
    return _b64e(hmac.new(secret, payload_b64.encode("ascii"), hashlib.sha256).digest())


def make_token(user_id: str, expires_at: int, secret: bytes) -> str:
    payload = json.dumps({"sub": user_id, "exp": expires_at}, separators=(",", ":"), sort_keys=True)
    payload_b64 = _b64e(payload.encode("utf-8"))
    return f"{payload_b64}.{_sign(payload_b64, secret)}"


def verify_token(token: str, secret: bytes, now: int) -> str:
    """Return the user id if `token` is authentic and unexpired, else raise InvalidToken."""
    if not token.isascii():
        raise InvalidToken("malformed token")
    try:
        payload_b64, signature = token.split(".")
    except ValueError:
        raise InvalidToken("malformed token") from None
    expected = _sign(payload_b64, secret)
    if not hmac.compare_digest(signature, expected):
        raise InvalidToken("bad signature")
    try:
        claims = json.loads(_b64d(payload_b64))
        user_id, exp = claims["sub"], claims["exp"]
    except (binascii.Error, ValueError, KeyError, TypeError):
        raise InvalidToken("bad payload") from None
    if not isinstance(user_id, str) or type(exp) is not int:
        raise InvalidToken("bad claims")
    if now >= exp:
        raise InvalidToken("expired")
    return user_id

Complexity: O(n) in the token length for encoding, hashing and comparison; O(n) extra space. HMAC-SHA256 is fast enough to run on every request.

Tests:

SECRET = b"s3cr3t-key-from-env"
NOW = 1_780_000_000

tok = make_token("asha.rao@corp.in", NOW + 900, SECRET)
assert tok.count(".") == 1 and "=" not in tok          # dots in the user id don't leak into the format
assert verify_token(tok, SECRET, NOW) == "asha.rao@corp.in"
assert verify_token(tok, SECRET, NOW + 899) == "asha.rao@corp.in"
assert make_token("asha.rao@corp.in", NOW + 900, SECRET) == tok   # deterministic

def rejects(token, secret=SECRET, now=NOW):
    try:
        verify_token(token, secret, now)
    except InvalidToken:
        return True
    return False

assert rejects(tok, now=NOW + 900)                      # expiry boundary: exp itself is expired
assert rejects(tok, secret=b"other-key")                # wrong key

# Tampering with the expiry while keeping the old signature must fail
payload_b64, sig = tok.split(".")
claims = json.loads(base64.urlsafe_b64decode(payload_b64 + "=" * (-len(payload_b64) % 4)))
claims["exp"] = NOW + 10**6
forged_payload = base64.urlsafe_b64encode(
    json.dumps(claims, separators=(",", ":"), sort_keys=True).encode()).rstrip(b"=").decode()
assert rejects(f"{forged_payload}.{sig}")

# Changing the user id must fail too
claims["exp"], claims["sub"] = NOW + 900, "admin@corp.in"
forged_payload = base64.urlsafe_b64encode(
    json.dumps(claims, separators=(",", ":"), sort_keys=True).encode()).rstrip(b"=").decode()
assert rejects(f"{forged_payload}.{sig}")

# Garbage never leaks a different exception type
for junk in ["", "abc", "a.b.c", tok + "x", "." + sig, "%%%%.%%%%", "ünï.cödé"]:
    assert rejects(junk), junk

# Correctly signed but structurally wrong payloads are rejected cleanly
def signed(raw: bytes) -> str:
    p = base64.urlsafe_b64encode(raw).rstrip(b"=").decode()
    s = base64.urlsafe_b64encode(hmac.new(SECRET, p.encode(), hashlib.sha256).digest()).rstrip(b"=").decode()
    return f"{p}.{s}"

assert rejects(signed(b"not json"))
assert rejects(signed(b'{"sub": "x"}'))
assert rejects(signed(b'[1, 2]'))
assert rejects(signed(b'{"sub": "x", "exp": "9999999999"}'))
assert verify_token(signed(b'{"sub": "x", "exp": 9999999999}'), SECRET, NOW) == "x"

A common wrong solution (the tests catch it):

import base64
import hashlib
import hmac
import json


class InvalidToken(Exception):
    pass


def _b64e(raw: bytes) -> str:
    return base64.urlsafe_b64encode(raw).rstrip(b"=").decode("ascii")


def make_token(user_id: str, expires_at: int, secret: bytes) -> str:
    payload = json.dumps({"sub": user_id, "exp": expires_at}, separators=(",", ":"), sort_keys=True)
    sig = _b64e(hmac.new(secret, user_id.encode(), hashlib.sha256).digest())   # signs only the user id
    return f"{_b64e(payload.encode())}.{sig}"


def verify_token(token: str, secret: bytes, now: int) -> str:
    try:
        payload_b64, signature = token.split(".")
        claims = json.loads(base64.urlsafe_b64decode(payload_b64 + "=" * (-len(payload_b64) % 4)))
        user_id, exp = claims["sub"], claims["exp"]
    except Exception:
        raise InvalidToken("bad token") from None
    expected = _b64e(hmac.new(secret, str(user_id).encode(), hashlib.sha256).digest())
    if not hmac.compare_digest(signature, expected) or now >= exp:
        raise InvalidToken("rejected")
    return user_id

Alternatives and tradeoffs:

• A standard format (JWT via a maintained library such as PyJWT) gives interoperability, key rotation (kid) and algorithm handling. Hand-rolling is for learning or very small internal tools; in production prefer the library, but pin the accepted algorithm.
• Opaque random tokens stored server-side (secrets.token_urlsafe(32) mapped to a session row) can be revoked instantly and leak nothing. The cost is a database or cache lookup per request.
• itsdangerous (used by Flask) implements exactly this signed-and-timestamped pattern.

Follow-ups:

1. "Why does hmac.compare_digest matter? Both versions give the same True/False." == on strings stops at the first differing character, so response time leaks how many leading characters of a guessed signature are right. Over many requests an attacker can recover a valid signature byte by byte. compare_digest takes the same time however many characters match.
2. "A user is fired at 11:00 IST but their token expires at 18:00. What can you do with stateless tokens?" Nothing inside the token itself. Options: keep expiries short and use refresh tokens checked against the database; keep a server-side deny-list of revoked token ids (add a jti claim) or a per-user 'tokens issued before T are invalid' timestamp; or rotate the secret, which logs everyone out. Revocation is the main trade-off of stateless tokens.
3. "Where should secret come from, and what happens if it leaks?" From a secret manager or environment variable, never from the repo, and long and random (secrets.token_bytes(32)). If it leaks, anyone can mint tokens for any user, so rotate it immediately. Supporting two active secrets (a key id in the token) allows rotation without logging everyone out.

Scoring: Strong: Signs the full encoded payload, verifies before parsing, uses compare_digest, gets the expiry boundary right, maps every malformed input to InvalidToken, and discusses revocation and secret handling. Acceptable: Correct signing and expiry with compare_digest; lets one or two parsing exceptions leak until the garbage-input tests are shown. Red flag: Signs only the user id (so exp can be extended), trusts the payload before checking the signature, or just base64-encodes the JSON with no signature.

JR-HT-C03 · An atomic file-write context manager

Hard & Tricky · Coding · Junior (1–3 years) · context managers, contextlib, files, os.replace, tempfile, exceptions · 30 min

Problem:

A nightly job rewrites daily_sales.csv, which a dashboard reads every minute. Last week the job crashed half-way through writing, and the dashboard showed a truncated file until the next night. Write a context manager atomic_write(path, mode="w", encoding="utf-8") so that readers see either the complete old file or the complete new file, never a partial one:

with atomic_write("daily_sales.csv") as f:
    f.write(header)
    for row in rows:
        f.write(row)

• Write to a temporary file, and only when the with block finishes successfully move it over path.
• If the block raises (any exception, including KeyboardInterrupt), leave path untouched, delete the temp file, and let the exception propagate.
• Leave no temp files behind in either case, and close the file handle.
• Support text mode "w" and binary mode "wb"; reject any other mode with ValueError.
• Work whether or not path already exists.

Signature: @contextmanager def atomic_write(path: str | os.PathLike[str], mode: str = "w", encoding: str = "utf-8") -> Iterator[IO]:

Constraints:

• Standard library only.
• The temp file must be on the same filesystem as path (think about where you create it).
• The exception raised inside the block must reach the caller unchanged.

Examples:

• with atomic_write(p) as f: f.write("new") → p contains "new"; the directory contains only p
• with atomic_write(p) as f: f.write("Delhi,"); raise RuntimeError("DB connection lost") → RuntimeError propagates; p still has its old content; no temp file left
• with atomic_write(p, "a"): ... → ValueError

Hints:

1. With @contextmanager, an exception in the with body is raised at your yield. What must surround the yield?
2. os.replace(src, dst) overwrites dst atomically when both are on the same filesystem. /tmp may be a different one.
3. tempfile.mkstemp(dir=...) gives you a unique file in a directory you choose.
4. Before renaming, make sure the bytes have reached the disk: flush() and then os.fsync().

Reference solution:

import os
import tempfile
from collections.abc import Iterator
from contextlib import contextmanager
from pathlib import Path
from typing import IO


@contextmanager
def atomic_write(path: str | os.PathLike[str], mode: str = "w",
                 encoding: str = "utf-8") -> Iterator[IO]:
    """Write to `path` all-or-nothing.

    Data goes to a temp file in the SAME directory; only after the with-block
    succeeds is it flushed, fsynced and renamed over `path` (os.replace is atomic
    on one filesystem). On any exception the temp file is removed, `path` is
    untouched, and the exception propagates.
    """
    if mode not in ("w", "wb"):
        raise ValueError("mode must be 'w' or 'wb'")
    target = Path(path)
    fd, tmp_name = tempfile.mkstemp(dir=target.parent, prefix=f".{target.name}.", suffix=".tmp")
    try:
        if mode == "w":
            f = os.fdopen(fd, "w", encoding=encoding, newline="")
        else:
            f = os.fdopen(fd, "wb")
    except BaseException:
        os.close(fd)
        os.unlink(tmp_name)
        raise
    try:
        with f:
            yield f
            f.flush()
            os.fsync(f.fileno())
        os.replace(tmp_name, target)
    except BaseException:
        try:
            os.unlink(tmp_name)
        except FileNotFoundError:
            pass
        raise

Complexity: O(size of the data) time for writing, plus one fsync and one rename. O(1) extra memory, since data streams to the temp file. Disk usage briefly doubles while both files exist.

Tests:

import tempfile as _tf
from pathlib import Path as _P

with _tf.TemporaryDirectory() as d:
    report = _P(d) / "daily_sales.csv"
    report.write_text("city,amount\nPune,1200\n", encoding="utf-8")

    # Failure half-way: original untouched, no temp files left behind
    try:
        with atomic_write(report) as f:
            f.write("city,amount\n")
            f.write("Delhi,")
            raise RuntimeError("DB connection lost")
    except RuntimeError as exc:
        assert str(exc) == "DB connection lost"          # not swallowed
    assert report.read_text(encoding="utf-8") == "city,amount\nPune,1200\n"
    assert sorted(p.name for p in _P(d).iterdir()) == ["daily_sales.csv"]

    # Success: content replaced, still no temp files
    with atomic_write(report) as f:
        f.write("city,amount\nचेन्नई,800\n")
    assert report.read_text(encoding="utf-8") == "city,amount\nचेन्नई,800\n"
    assert sorted(p.name for p in _P(d).iterdir()) == ["daily_sales.csv"]

    # New file, binary mode, str path
    blob = str(_P(d) / "model.bin")
    with atomic_write(blob, "wb") as f:
        f.write(b"\x00\x01weights")
    assert _P(blob).read_bytes() == b"\x00\x01weights"

    # Failure when the target does not exist yet: it must not appear
    ghost = _P(d) / "ghost.json"
    try:
        with atomic_write(ghost) as f:
            f.write("{")
            raise KeyboardInterrupt
    except KeyboardInterrupt:
        pass
    assert not ghost.exists()
    assert sorted(p.name for p in _P(d).iterdir()) == ["daily_sales.csv", "model.bin"]

    # Handle is closed afterwards
    with atomic_write(report) as f:
        f.write("x")
    assert f.closed

    try:
        with atomic_write(report, "a"):
            pass
        raise AssertionError("append mode accepted")
    except ValueError:
        pass
    assert report.read_text(encoding="utf-8") == "x"

A common wrong solution (the tests catch it):

import os
from contextlib import contextmanager


@contextmanager
def atomic_write(path, mode="w", encoding="utf-8"):
    if mode not in ("w", "wb"):
        raise ValueError("mode must be 'w' or 'wb'")
    tmp = f"{path}.tmp"
    f = open(tmp, mode, encoding=None if "b" in mode else encoding)
    yield f                      # no try/finally: an exception skips everything below
    f.close()
    os.replace(tmp, path)

Alternatives and tradeoffs:

• Write in place with open(path, "w"): this is what failed. Opening in "w" mode truncates immediately, so readers can see an empty or partial file and a crash leaves it that way.
• Write path + ".tmp" with a fixed name: simpler, but two concurrent runs collide on the same temp file, and a crash leaves .tmp debris (as the broken solution shows). mkstemp gives a unique name.
• Write a new versioned file and switch a symlink or pointer (sales_2026-10-04.csv plus latest → it): this keeps history and allows rollback, at the cost of cleanup work.
• A full durability guarantee also needs an fsync of the directory after os.replace on POSIX, so the rename itself survives a power cut. That's worth mentioning for important data.

Follow-ups:

1. "Why must the temp file be in the same directory rather than in /tmp?" os.replace is an atomic rename only within a single filesystem. If /tmp is a different mount (often tmpfs), the rename fails with OSError: Invalid cross-device link (EXDEV). Even shutil.move, which falls back to copy-and-delete, is no longer atomic.
2. "Why catch BaseException in the cleanup instead of Exception?" So that Ctrl+C (KeyboardInterrupt) or SystemExit during the write also removes the temp file. The raise re-raises it, so you clean up without swallowing anything. Catching BaseException without re-raising would be a bug.
3. "mkstemp creates the file with permissions 0600. Why might that matter after the rename?" The new file replaces the old one including its permissions, so a file that was group-readable (0644) becomes owner-only, and a dashboard running as another user can suddenly no longer read it. Copy the original mode with os.chmod(tmp, os.stat(path).st_mode) before replacing, if that matters.

Scoring: Strong: Temp file in the same directory, try/except BaseException around the yield that cleans up and re-raises, flush, fsync and os.replace only on success, file always closed; explains the cross-device and permission caveats. Acceptable: Uses a temp file and os.replace correctly, but leaks the temp file on failure or creates it in /tmp; fixes it once the failing test is shown. Red flag: Opens the target with "w" directly, or catches the exception and doesn't re-raise it, hiding failures from the job.

JR-DE-C01 · Load a change batch into SQLite with an idempotent upsert

Medium · Coding · Junior (1–3 years) · sqlite3, upsert, transactions, parameterised queries, incremental loads, idempotency · 25 min

Problem:

An hourly job receives changed orders from an upstream system and must apply them to an orders table in SQLite. Batches overlap and jobs get re-run, so the same row can arrive several times, and an older version of an order can arrive after a newer one.

The table already exists:

CREATE TABLE orders (
    order_id     TEXT PRIMARY KEY,
    status       TEXT NOT NULL,
    amount_paise INTEGER NOT NULL CHECK (amount_paise >= 0),
    updated_at   TEXT NOT NULL      -- UTC, always 'YYYY-MM-DDTHH:MM:SSZ'
)

Write load_orders(conn, rows):

• New order_id → insert. Existing → update only if the incoming updated_at is strictly later than the stored one; otherwise leave the row alone. Re-running a batch must change nothing.
• Before writing anything, check every row's updated_at matches YYYY-MM-DDTHH:MM:SSZ exactly and raise ValueError otherwise (that fixed format is what makes comparing the text safe).
• The batch is all or nothing: if any row fails (a constraint violation, a missing key), roll back every row of this batch and let the exception propagate.
• Use query parameters, never string formatting, to put values into SQL.
• Return how many rows were inserted or updated.

Signature: def load_orders(conn: sqlite3.Connection, rows: list[dict]) -> int:

Constraints: Batches of up to 10^5 rows. SQLite 3.24+ (for ON CONFLICT ... DO UPDATE); Python 3.12 ships a newer one.

Examples:

• load_orders(conn, [A1 PLACED @10:00Z, A2 PLACED @10:05Z]) on an empty table → 2
• the same call again → 0
• A1 DELIVERED @11:00Z, then later A1 SHIPPED @10:30Z (arrived late) → 1, then 0; A1 stays DELIVERED
• a batch whose second row has amount_paise = -5 → sqlite3.IntegrityError; the first row is not saved either

Hints:

1. SQLite's INSERT ... ON CONFLICT (order_id) DO UPDATE SET ... WHERE ... can express the whole rule in one statement; excluded.col is the incoming value.
2. executemany accepts a list of dicts when the SQL uses named parameters like :order_id.
3. with conn: commits on success and rolls back on an exception. conn.total_changes counts rows changed so far on this connection.

Reference solution:

import re
import sqlite3

STAMP = re.compile(r"\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z")

UPSERT = """
INSERT INTO orders (order_id, status, amount_paise, updated_at)
VALUES (:order_id, :status, :amount_paise, :updated_at)
ON CONFLICT (order_id) DO UPDATE SET
    status = excluded.status,
    amount_paise = excluded.amount_paise,
    updated_at = excluded.updated_at
WHERE excluded.updated_at > orders.updated_at
"""


def load_orders(conn: sqlite3.Connection, rows: list[dict]) -> int:
    """Upsert `rows` into `orders` atomically; return the number of rows inserted or updated."""
    for row in rows:
        stamp = row.get("updated_at")
        if not isinstance(stamp, str) or not STAMP.fullmatch(stamp):
            raise ValueError(f"bad updated_at for {row.get('order_id')!r}: {stamp!r}")
    before = conn.total_changes
    with conn:                      # one transaction: commit on success, roll back on error
        conn.executemany(UPSERT, rows)
    return conn.total_changes - before

Complexity: O(n log m) for n batch rows against a table of m rows (each upsert is a primary-key B-tree lookup), in a single transaction; O(1) extra Python memory beyond the input list.

Tests:

def fresh():
    conn = sqlite3.connect(":memory:")
    conn.execute("""CREATE TABLE orders (order_id TEXT PRIMARY KEY, status TEXT NOT NULL,
        amount_paise INTEGER NOT NULL CHECK (amount_paise >= 0), updated_at TEXT NOT NULL)""")
    return conn

def snapshot(conn):
    return conn.execute("SELECT * FROM orders ORDER BY order_id").fetchall()

def order(oid, status, amount, stamp):
    return {"order_id": oid, "status": status, "amount_paise": amount, "updated_at": stamp}

conn = fresh()
batch = [order("A1", "PLACED", 49900, "2026-04-01T10:00:00Z"),
         order("A2", "PLACED", 19900, "2026-04-01T10:05:00Z")]
assert load_orders(conn, batch) == 2
assert load_orders(conn, batch) == 0                         # re-run: no change
assert load_orders(conn, [order("A1", "DELIVERED", 49900, "2026-04-01T11:00:00Z")]) == 1
assert load_orders(conn, [order("A1", "SHIPPED", 49900, "2026-04-01T10:30:00Z")]) == 0   # late, older
assert snapshot(conn) == [("A1", "DELIVERED", 49900, "2026-04-01T11:00:00Z"),
                          ("A2", "PLACED", 19900, "2026-04-01T10:05:00Z")]

# Several versions of one order in one batch, newest first: the newest survives.
assert load_orders(conn, [order("A3", "CANCELLED", 0, "2026-04-01T12:10:00Z"),
                          order("A3", "PLACED", 9900, "2026-04-01T12:00:00Z")]) == 1
assert conn.execute("SELECT status FROM orders WHERE order_id = 'A3'").fetchone() == ("CANCELLED",)

# All or nothing.
before = snapshot(conn)
try:
    load_orders(conn, [order("A4", "PLACED", 100, "2026-04-01T13:00:00Z"),
                       order("A5", "PLACED", -5, "2026-04-01T13:00:00Z")])
    raise AssertionError("expected IntegrityError")
except sqlite3.IntegrityError:
    pass
assert snapshot(conn) == before and not conn.in_transaction

# Bad timestamps are rejected before anything is written.
for bad in ("2026-04-01 13:00:00", "2026-04-01T18:30:00+05:30", None):
    try:
        load_orders(conn, [order("A6", "PLACED", 100, "2026-04-01T13:00:00Z"), order("A7", "PLACED", 100, bad)])
        raise AssertionError("expected ValueError")
    except ValueError:
        pass
assert snapshot(conn) == before

# Values with quotes are stored safely (parameters, not string formatting).
assert load_orders(conn, [order("D'SOUZA-1", "PLACED", 100, "2026-04-01T14:00:00Z")]) == 1

A common wrong solution (the tests catch it):

import re
import sqlite3

STAMP = re.compile(r"\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z")

UPSERT = """
INSERT INTO orders (order_id, status, amount_paise, updated_at)
VALUES (:order_id, :status, :amount_paise, :updated_at)
ON CONFLICT (order_id) DO UPDATE SET
    status = excluded.status,
    amount_paise = excluded.amount_paise,
    updated_at = excluded.updated_at
"""                                   # no WHERE: the last row to arrive always wins

def load_orders(conn, rows):
    for row in rows:
        stamp = row.get("updated_at")
        if not isinstance(stamp, str) or not STAMP.fullmatch(stamp):
            raise ValueError(f"bad updated_at: {stamp!r}")
    before = conn.total_changes
    with conn:
        conn.executemany(UPSERT, rows)
    return conn.total_changes - before

Alternatives and tradeoffs: PostgreSQL has the same INSERT ... ON CONFLICT ... DO UPDATE ... WHERE syntax; warehouses use MERGE. Doing it in Python (SELECT each row, compare, then INSERT or UPDATE) is slower and racy when two jobs overlap; letting the database apply the rule in one statement inside one transaction is simpler and safer. For large loads, a common pattern is to bulk-insert the batch into a staging table and run one set-based upsert from it.

Follow-ups:

1. "Why is comparing updated_at as text safe here but not in general?" Fixed-width, zero-padded, all-UTC ISO strings sort in the same order as the instants they represent. Mix in +05:30 offsets, missing seconds or a space instead of T, and text order no longer matches time order. That's why the function validates the format first. Storing epoch integers or a real timestamp type avoids the issue.
2. "What exactly does with conn: do in sqlite3?" It commits the transaction if the block succeeds and rolls it back if it raises. It does not close the connection. Without it, a failure halfway through executemany would leave earlier rows pending in an open transaction, to be committed or lost depending on what the caller does next.
3. "Two versions of the same order have the same updated_at. Which wins, and is that OK?" Whichever was stored first: the strict > ignores the second. That's arbitrary; ask upstream for a tiebreaker such as a version number, and use (updated_at, version) in the comparison.

Scoring: Strong: One upsert statement with a WHERE on updated_at, named parameters with executemany, a single transaction, validation before writing, and a correct count; explains why re-runs and late rows are safe. Acceptable: Correct upsert but always overwrites, or commits per row; fixes it after the late-row or all-or-nothing test fails. Red flag: Builds SQL with f-strings, or does DELETE everything and reinsert for each batch without a transaction.

JR-DE-C02 · Parse a JSON-lines order feed and quarantine bad lines

Easy · Coding · Junior (1–3 years) · json, validation, generators, isinstance, data quality · 15 min

Problem:

A payments partner drops a JSON-lines file every hour: one JSON object per line. Write a parser that yields good records and collects bad lines into a quarantine list instead of crashing on the first one, so the pipeline can load the good rows and someone can look at the rest.

A line is valid when it is a JSON object with:

• order_id: a non-empty string;
• amount_paise: an integer ≥ 0 (amounts are in paise, so ₹499 is 49900). Booleans are not integers here;
• city: a string. Strip surrounding spaces and title-case it (" pune " → "Pune").

Extra keys are dropped. Blank lines (only whitespace) are skipped silently. For every other bad line, append (line_number, reason) to rejects, numbering lines from 1 as they appear in the file (blank lines count). Use exactly these reasons, checking in this order: "invalid json", "not an object", "missing <field>" (the first missing field in the order above), "bad order_id", "bad amount_paise", "bad city".

Write it as a generator, so a large file is processed one line at a time.

Signature: def parse_orders(lines: Iterable[str], rejects: list[tuple[int, str]]) -> Iterator[dict]:

Constraints: Files can be several GB: do not read the whole file into a list. lines may be an open file object.

Examples:

• parse_orders(['{"order_id": "A1", "amount_paise": 49900, "city": " pune "}'], rejects) → yields {'order_id': 'A1', 'amount_paise': 49900, 'city': 'Pune'}; rejects == []
• a line '{"order_id": "A2", "amount_paise": true, "city": "Goa"}' at line 3 → rejects gets (3, 'bad amount_paise')
• a line 'not json' at line 1 → rejects gets (1, 'invalid json')

Hints:

1. enumerate(lines, start=1) gives you line numbers that count blank lines too.
2. json.loads raises json.JSONDecodeError (a ValueError) on bad input, and can return a list or a number, not only a dict.
3. isinstance(True, int) is True. How do you reject booleans?

Reference solution:

import json
from collections.abc import Iterable, Iterator

FIELDS = ("order_id", "amount_paise", "city")


def parse_orders(lines: Iterable[str], rejects: list[tuple[int, str]]) -> Iterator[dict]:
    """Yield clean order dicts; append (line_number, reason) for bad lines to `rejects`."""
    for line_no, line in enumerate(lines, start=1):
        if not line.strip():
            continue
        try:
            data = json.loads(line)
        except json.JSONDecodeError:
            rejects.append((line_no, "invalid json"))
            continue
        if not isinstance(data, dict):
            rejects.append((line_no, "not an object"))
            continue
        missing = [f for f in FIELDS if f not in data]
        if missing:
            rejects.append((line_no, f"missing {missing[0]}"))
            continue
        order_id, amount, city = data["order_id"], data["amount_paise"], data["city"]
        if not isinstance(order_id, str) or not order_id.strip():
            rejects.append((line_no, "bad order_id"))
        elif isinstance(amount, bool) or not isinstance(amount, int) or amount < 0:
            rejects.append((line_no, "bad amount_paise"))
        elif not isinstance(city, str):
            rejects.append((line_no, "bad city"))
        else:
            yield {"order_id": order_id, "amount_paise": amount, "city": city.strip().title()}

Complexity: O(total characters) time; O(1) extra memory per good record because it is a generator, plus the size of rejects (bounded by the number of bad lines).

Tests:

import io

feed = io.StringIO(
    '{"order_id": "A1", "amount_paise": 49900, "city": " pune ", "promo": "DIWALI"}\n'
    '\n'
    '{"order_id": "A2", "amount_paise": true, "city": "Goa"}\n'
    'not json\n'
    '[1, 2, 3]\n'
    '{"order_id": "A3", "city": "Delhi"}\n'
    '{"order_id": "", "amount_paise": 100, "city": "Delhi"}\n'
    '{"order_id": "A4", "amount_paise": 99.5, "city": "Delhi"}\n'
    '{"order_id": "A5", "amount_paise": -1, "city": "Delhi"}\n'
    '{"order_id": "A6", "amount_paise": 0, "city": 7}\n'
    '{"order_id": "A7", "amount_paise": 0, "city": "navi mumbai"}\n'
)
rejects = []
gen = parse_orders(feed, rejects)
assert iter(gen) is gen                     # a generator / iterator, not a list
good = list(gen)
assert good == [
    {"order_id": "A1", "amount_paise": 49900, "city": "Pune"},
    {"order_id": "A7", "amount_paise": 0, "city": "Navi Mumbai"},
], good
assert rejects == [
    (3, "bad amount_paise"),
    (4, "invalid json"),
    (5, "not an object"),
    (6, "missing amount_paise"),
    (7, "bad order_id"),
    (8, "bad amount_paise"),
    (9, "bad amount_paise"),
    (10, "bad city"),
], rejects

# Lazy: nothing is read until the generator is advanced.
def lines():
    yield '{"order_id": "B1", "amount_paise": 1, "city": "Agra"}'
    raise RuntimeError("should not read this far")
out = []
first = next(parse_orders(lines(), out))
assert first["order_id"] == "B1" and out == []

A common wrong solution (the tests catch it):

import json

def parse_orders(lines, rejects):
    for line_no, line in enumerate(lines, start=1):
        if not line.strip():
            continue
        try:
            data = json.loads(line)
        except json.JSONDecodeError:
            rejects.append((line_no, "invalid json"))
            continue
        if not isinstance(data, dict):
            rejects.append((line_no, "not an object"))
            continue
        missing = [f for f in ("order_id", "amount_paise", "city") if f not in data]
        if missing:
            rejects.append((line_no, f"missing {missing[0]}"))
            continue
        order_id, amount, city = data["order_id"], data["amount_paise"], data["city"]
        if not isinstance(order_id, str) or not order_id.strip():
            rejects.append((line_no, "bad order_id"))
        elif not isinstance(amount, int) or amount < 0:      # lets True through
            rejects.append((line_no, "bad amount_paise"))
        elif not isinstance(city, str):
            rejects.append((line_no, "bad city"))
        else:
            yield {"order_id": order_id, "amount_paise": amount, "city": city.strip().title()}

Alternatives and tradeoffs: A Pydantic model with StrictInt / Field(ge=0) validates the same rules declaratively and gives structured error messages; it is the better choice when the schema grows. pandas read_json(lines=True) is convenient for clean files but fails or coerces on bad lines instead of quarantining them. For very large files, write the rejects to a separate "dead-letter" file instead of keeping them in a list.

Follow-ups:

1. "Why is isinstance(True, int) true, and why does it matter here?" bool is a subclass of int, so True passes an int check and would be loaded as an amount of 1 paisa. Check for bool first, or use type(x) is int, or a strict validator.
2. "The partner sends the file in two parts and the second has a different encoding. How would that show up?" Opening with the wrong encoding raises UnicodeDecodeError while iterating, which this function does not catch: the whole run fails mid-file. Open with an explicit encoding="utf-8" and decide whether to fail the file or use errors="replace" and quarantine lines containing the replacement character.
3. "How would you alert on a bad feed, rather than silently quarantining 40% of it?" Count good and rejected lines, log both, and fail the run (or page someone) when the reject rate crosses a threshold, for example above 1%.

Scoring: Strong: A real generator, correct line numbering with blank lines, rejects non-object JSON and booleans unprompted, and suggests a reject-rate threshold. Acceptable: Works on the main cases; misses the boolean or the "not an object" case until a test or hint shows it. Red flag: Reads the whole file with readlines() or wraps everything in a bare except: that hides which rule failed.

JR-DE-O01 · Epoch timestamps in milliseconds read as the wrong unit

Easy & Tricky · Output · Junior (1–3 years) · datetime, pandas, to_datetime, epoch time, units, time zones · 5 min

Question: Click events from a mobile app arrive with event_ms, a Unix timestamp in milliseconds (what JavaScript's Date.now() and most Kafka producers emit). What does this print?

from datetime import datetime, timezone
import pandas as pd

event_ms = 1775039400000          # from a mobile app's click event, in milliseconds

print(pd.to_datetime(event_ms))
print(pd.to_datetime(event_ms, unit="ms"))
print(pd.to_datetime(event_ms, unit="ms", utc=True).tz_convert("Asia/Kolkata"))
try:
    datetime.fromtimestamp(event_ms, tz=timezone.utc)
except ValueError as exc:
    print("ValueError:", exc)
print(datetime.fromtimestamp(event_ms / 1000, tz=timezone.utc))
print(pd.to_datetime(pd.Series([event_ms // 1000]), unit="s").iloc[0])

Expected output:

1970-01-01 00:29:35.039400
2026-04-01 10:30:00
2026-04-01 16:00:00+05:30
ValueError: year 58218 is out of range
2026-04-01 10:30:00+00:00
2026-04-01 10:30:00

The trap:

"The first line is 1 April 2026." Tempting because a big integer "obviously" is a timestamp, and the code runs without any error.

Real-world bug: a pipeline loads a month of click events and every one of them lands on 1 January 1970. The daily partitions for April are empty, the 1970 partition is huge, and the dashboard shows zero traffic. No exception was raised anywhere.

Explanation:

An epoch timestamp is only a number; the unit is a separate fact you have to know.

• pd.to_datetime(int) assumes nanoseconds (pandas' internal unit). 1,775,039,400,000 ns is about 1,775 seconds, i.e. 29 minutes and 35 seconds after midnight on 1 January 1970. No error, just a wrong date.
• unit="ms" gives the right instant: 10:30 UTC on 1 April 2026. The result is naive (no time zone), but epoch time is defined in UTC.
• utc=True makes it timezone-aware in UTC, and tz_convert("Asia/Kolkata") shows it in IST: 16:00, five and a half hours later. Use the IST version for "which business day was this?" questions.
• The standard library's datetime.fromtimestamp expects seconds. Given milliseconds it computes a date about 58,000 years in the future and raises ValueError (this one, at least, fails loudly). Divide by 1000.
• Integer division to seconds with unit="s" gives the same instant, losing the sub-second part.

Takeaway: always state the unit (unit="ms" / "s"), make the result UTC-aware, and sanity-check the date range after parsing (for example "no events before 2020").

Follow-ups:

1. "How can you tell seconds from milliseconds just by looking at the number?" Current timestamps in seconds have 10 digits (about 1.7–1.8 billion in 2026); in milliseconds, 13 digits; microseconds, 16; nanoseconds, 19. A quick len(str(x)) or a range check catches a wrong unit, but the producer's documentation is the real answer.
2. "Why use utc=True instead of leaving the timestamps naive?" A naive value doesn't say which zone it is in. Someone later calls tz_localize("Asia/Kolkata") on it, and every event shifts by 5:30. Aware UTC values compare and convert correctly everywhere.
3. "What check would you add to the pipeline?" After parsing, assert the min and max timestamps fall in an expected window (e.g. within the last few days for a daily job) and fail the run otherwise. It also catches producers that switch units without telling anyone.

Scoring: Strong: All six lines; knows pandas defaults to nanoseconds and fromtimestamp to seconds, converts to UTC-aware and then IST, and proposes a range check. Acceptable: Spots that the first line is wrong and that unit="ms" fixes it; unsure about the fromtimestamp error or the IST conversion. Red flag: Fixes the dates by adding a constant offset, or converts to IST by calling tz_localize("Asia/Kolkata") on the UTC values.

JR-DE-O02 · read_csv turns a real country code into a missing value

Medium · Output · Junior (1–3 years) · pandas, read_csv, missing values, na_values, nullable integers · 6 min

Question: An export from a Mumbai spice exporter lists orders by destination country. NA is the ISO code for Namibia, a real market for them. What does this print on pandas 2.2?

import io
import pandas as pd

csv_text = """order_id,country,qty,coupon
A1,IN,3,DIWALI10
A2,NA,,
A3,IN,5,null
"""
df = pd.read_csv(io.StringIO(csv_text))
print(df.dtypes.astype(str).to_dict())
print(df["country"].isna().sum(), df["coupon"].isna().sum(), df["qty"].sum())
print(df.groupby("country")["qty"].sum().to_dict())

fixed = pd.read_csv(io.StringIO(csv_text), dtype={"qty": "Int64"}, keep_default_na=False,
                    na_values={"qty": [""], "coupon": ["", "null"]})
print(fixed.dtypes.astype(str).to_dict())
print(fixed["country"].tolist(), fixed["qty"].tolist(), fixed["qty"].sum())
print(fixed.groupby("country")["qty"].sum().to_dict())

Expected output:

{'order_id': 'object', 'country': 'object', 'qty': 'float64', 'coupon': 'object'}
1 2 8.0
{'IN': 8.0}
{'order_id': 'object', 'country': 'object', 'qty': 'Int64', 'coupon': 'object'}
['IN', 'NA', 'IN'] [3, <NA>, 5] 8
{'IN': 8, 'NA': 0}

The trap:

"country is ['IN', 'NA', 'IN'] and qty is an integer column." Tempting because the file plainly contains the text NA, and pandas usually reads text as text.

Real-world bug: the country-wise export report silently drops Namibia: its orders are "missing country", and groupby leaves NaN keys out of the result by default. Nobody notices until the Namibian distributor asks why their volumes are not in the quarterly review.

Explanation:

read_csv treats a list of strings as missing values by default: "", NA, N/A, NaN, NULL, null, None, n/a, nan, <NA>, #N/A and a few more. So:

• Namibia's NA becomes NaN (1 missing country). The empty and the null coupon both become NaN (2), which is what you'd want there.
• qty has an empty cell. A NumPy int64 column can't hold a missing value, so pandas reads the column as float64: 3.0, NaN, 5.0, sum 8.0.
• groupby drops rows whose key is NaN (dropna=True by default), so the result only has IN.

The fixed read turns the default list off (keep_default_na=False) and declares per column what counts as missing (na_values), so NA stays a country. "Int64" (capital I) is pandas' nullable integer dtype: the gap is <NA> and the other values stay integers, so the sum is the integer 8. Namibia now appears in the group-by, with 0 because sum skips the missing quantity.

Takeaway: the default missing-value list is a guess about your data. For pipeline inputs, say which values mean "missing" in which columns, and give integer columns with gaps a nullable dtype.

Follow-ups:

1. "Would you keep NA for Namibia by quoting it in the file, as "NA"?" No: the csv parser removes the quotes before the missing-value check, so "NA" is still read as missing. keep_default_na=False (or a per-column na_values) is the fix.
2. "What does groupby(..., dropna=False) change?" Rows with a missing key are kept as their own group (shown as NaN). It's a good habit in data-quality checks, because totals then add up to the ungrouped total.
3. "How would you catch this kind of silent change in a pipeline?" Check counts after loading: number of rows, nulls per column, and the set of distinct codes compared with a reference list (ISO country codes). A new null in a column that should never be null is a red flag.

Scoring: Strong: All six lines; knows NA is in the default missing list, explains the int → float change and the dropped NaN group, and describes keep_default_na/na_values and Int64. Acceptable: Gets the float column and the sum; surprised by NA becoming NaN but explains the fix once told. Red flag: Patches it afterwards with fillna("NA") on the country column (which also labels genuinely missing countries as Namibia), or doesn't know missing values change a column's dtype.

JR-DS-C01 · Target-mean encoding fitted on train only

Medium · Coding · Junior (1–3 years) · pandas, feature engineering, groupby, map, data leakage, train/test split · 20 min

Problem:

You are predicting whether a loan applicant defaults (defaulted is 0 or 1). The branch column has hundreds of values, too many for one-hot encoding, so you replace each branch with the mean default rate of that branch ("target-mean encoding").

Write mean_encode(train, test, col, target, smoothing=0.0) that returns two Series, one for train and one for test:

• The per-category statistics are computed from train only.
• With smoothing m, a category with n training rows and target sum s is encoded as (s + m * g) / (n + m), where g is the global mean of the target in train. With m = 0 this is the plain category mean.
• Categories not seen in train (including missing values) get g.
• Returned Series keep the index of the frame they belong to, are named f"{col}_te", and are float64.
• Do not modify train or test.

Signature: def mean_encode(train: pd.DataFrame, test: pd.DataFrame, col: str, target: str, smoothing: float = 0.0) -> tuple[pd.Series, pd.Series]:

Constraints: Up to 10^6 training rows: no Python loops over rows. smoothing >= 0.

Examples:

• train branches A, A, B with defaulted 1, 0, 0; test branches B, C → train → [0.5, 0.5, 0.0]; test → [0.0, 0.3333...] (C is unseen, gets the global mean 1/3)
• same, smoothing=2 → A → (1 + 2/3) / 4 = 0.41666..., B → (0 + 2/3) / 3 = 0.2222...

Hints:

1. train.groupby(col)[target].agg(['sum', 'count']) gives you s and n per category in one pass.
2. Series.map(stats) looks each value up in a Series indexed by category; what does it return for a key that isn't there?
3. Which DataFrame is allowed to influence the numbers, and why?

Reference solution:

import pandas as pd


def mean_encode(
    train: pd.DataFrame, test: pd.DataFrame, col: str, target: str, smoothing: float = 0.0
) -> tuple[pd.Series, pd.Series]:
    """Encode `col` by the (smoothed) mean of `target`, learned from `train` only."""
    if smoothing < 0:
        raise ValueError("smoothing must be >= 0")
    global_mean = float(train[target].mean())
    stats = train.groupby(col)[target].agg(["sum", "count"])
    encoding = (stats["sum"] + smoothing * global_mean) / (stats["count"] + smoothing)

    def apply(frame: pd.DataFrame) -> pd.Series:
        encoded = frame[col].map(encoding).fillna(global_mean).astype("float64")
        return encoded.rename(f"{col}_te")

    return apply(train), apply(test)

Complexity: O(n + m) time for n training rows and m test rows (one groupby, two hash lookups via map); O(k) extra space for k categories plus the two output Series.

Tests:

import math

train = pd.DataFrame({"branch": ["A", "A", "B"], "defaulted": [1, 0, 0]}, index=[10, 11, 12])
test = pd.DataFrame({"branch": ["B", "C", None]}, index=[7, 8, 9])
train_copy, test_copy = train.copy(), test.copy()

tr, te = mean_encode(train, test, "branch", "defaulted")
assert tr.tolist() == [0.5, 0.5, 0.0]
assert te.iloc[0] == 0.0
assert math.isclose(te.iloc[1], 1 / 3) and math.isclose(te.iloc[2], 1 / 3)   # unseen and missing → global
assert list(tr.index) == [10, 11, 12] and list(te.index) == [7, 8, 9]
assert tr.name == te.name == "branch_te" and te.dtype == "float64"
assert train.equals(train_copy) and test.equals(test_copy)

tr2, te2 = mean_encode(train, test, "branch", "defaulted", smoothing=2)
assert math.isclose(tr2.iloc[0], (1 + 2 / 3) / 4)
assert math.isclose(te2.iloc[0], (0 + 2 / 3) / 3)

# Test rows must not change the encoding, even if test has the target column.
leaky_test = pd.DataFrame({"branch": ["B", "B"], "defaulted": [1, 1]})
_, te3 = mean_encode(train, leaky_test, "branch", "defaulted")
assert te3.tolist() == [0.0, 0.0]

try:
    mean_encode(train, test, "branch", "defaulted", smoothing=-1)
    raise AssertionError("expected ValueError")
except ValueError:
    pass

A common wrong solution (the tests catch it):

import pandas as pd

def mean_encode(train, test, col, target, smoothing=0.0):
    if smoothing < 0:
        raise ValueError("smoothing must be >= 0")
    global_mean = float(train[target].mean())
    stats = train.groupby(col)[target].agg(["sum", "count"])
    encoding = (stats["sum"] + smoothing * global_mean) / (stats["count"] + smoothing)
    tr = train[col].map(encoding).rename(f"{col}_te")
    te = test[col].map(encoding).rename(f"{col}_te")      # unseen categories stay NaN
    return tr, te

Alternatives and tradeoffs: scikit-learn ≥ 1.3 has TargetEncoder, which also uses cross-fitting: each training row is encoded with statistics computed on the other folds, so a row's own label never leaks into its feature. The plain version here leaks a little on train (a branch with one applicant gets exactly that applicant's label), which inflates training scores; cross-fitting or strong smoothing reduces it. One-hot encoding is fine for a few dozen categories; frequency encoding is a leak-free option when the target isn't needed.

Follow-ups:

1. "Why must the statistics come from train only?" The test set stands in for future data whose labels you won't have. Using test labels (or computing stats on train + test) lets the answer leak into the feature, so the validation score is better than what production will see.
2. "A branch with one applicant who defaulted gets an encoding of 1.0 on train. What problem does that cause, and how does smoothing help?" The feature effectively is the label for that row, so the model learns to trust it too much. Smoothing pulls small categories towards the global mean: with m = 10, one default gives (1 + 10g) / 11, close to g.
3. "How would you use this in production for a new applicant?" Save the fitted encoding Series and global_mean with the model (e.g. as JSON), and apply the same map plus fillna at inference. Recomputing from live data would change the feature's meaning.

Scoring: Strong: Vectorised groupby + map, handles unseen and missing categories, keeps index and name, fits on train only and explains why; mentions train-side leakage and cross-fitting or smoothing. Acceptable: Correct plain encoding; forgets the unseen-category fallback or the index until a test shows it. Red flag: Computes statistics on the combined train and test data, or loops over rows with iterrows().

JR-DS-C02 · Per-user conversion summary for an A/B test

Easy & Tricky · Coding · Junior (1–3 years) · pandas, groupby, agg, unit of analysis, experiments · 15 min

Problem:

A food-delivery app tested a new checkout page. The event log has one row per page view: user_id, variant ("A" or "B"), and converted (1 if that view ended in an order, else 0). Users can view the page many times.

Return a summary at the user level:

• A user counts as converted if any of their views converted.
• A user who appears in both variants (an assignment bug, say after reinstalling the app) is excluded from both; return how many were excluded.
• The summary is a DataFrame indexed by variant (sorted), with integer columns users and conversions and a float column rate = conversions / users.

Signature: def ab_summary(events: pd.DataFrame) -> tuple[pd.DataFrame, int]:

Constraints: Up to 10^7 events: use groupby, not Python loops. converted may be stored as int or bool.

Examples:

• u1 (A) views twice, converts on the second; u2 (A) views once, no order; u3 (B) converts once → A: users 2, conversions 1, rate 0.5; B: users 1, conversions 1, rate 1.0; excluded 0
• u4 has one view in A and one in B → u4 counted in neither variant; excluded 1

Hints:

1. First reduce to one row per user. Which aggregation turns several 0/1 values into 'converted at least once'?
2. nunique on the variant column per user tells you who saw both.
3. Only then group by variant.

Reference solution:

import pandas as pd


def ab_summary(events: pd.DataFrame) -> tuple[pd.DataFrame, int]:
    """User-level conversion per variant, excluding users exposed to both variants."""
    per_user = events.groupby("user_id").agg(
        n_variants=("variant", "nunique"),
        variant=("variant", "first"),
        converted=("converted", "max"),
    )
    mixed = per_user["n_variants"] > 1
    clean = per_user[~mixed]
    summary = clean.groupby("variant").agg(
        users=("converted", "size"),
        conversions=("converted", "sum"),
    ).sort_index()
    summary = summary.astype({"users": "int64", "conversions": "int64"})
    summary["rate"] = summary["conversions"] / summary["users"]
    return summary, int(mixed.sum())

Complexity: O(n) expected time for n events (hash-based groupby), O(u) extra space for u users.

Tests:

events = pd.DataFrame({
    "user_id":   ["u1", "u1", "u2", "u3", "u4", "u4", "u5", "u5", "u5"],
    "variant":   ["A",  "A",  "A",  "B",  "A",  "B",  "B",  "B",  "B"],
    "converted": [0,    1,    0,    1,    1,    0,    0,    0,    1],
})
summary, excluded = ab_summary(events)
assert excluded == 1
assert list(summary.index) == ["A", "B"]
assert summary.loc["A", "users"] == 2 and summary.loc["A", "conversions"] == 1
assert summary.loc["B", "users"] == 2 and summary.loc["B", "conversions"] == 2
assert summary.loc["A", "rate"] == 0.5 and summary.loc["B", "rate"] == 1.0
assert str(summary["users"].dtype) == "int64" and str(summary["conversions"].dtype) == "int64"

# bool column and variants listed out of order
ev2 = pd.DataFrame({"user_id": ["x", "y", "y"], "variant": ["B", "A", "A"],
                    "converted": [False, True, True]})
s2, ex2 = ab_summary(ev2)
assert ex2 == 0 and list(s2.index) == ["A", "B"]
assert s2["conversions"].tolist() == [1, 0] and s2["rate"].tolist() == [1.0, 0.0]

A common wrong solution (the tests catch it):

import pandas as pd

def ab_summary(events):
    # counts page views, not users
    summary = events.groupby("variant").agg(users=("user_id", "size"),
                                            conversions=("converted", "sum")).sort_index()
    summary = summary.astype({"users": "int64", "conversions": "int64"})
    summary["rate"] = summary["conversions"] / summary["users"]
    return summary, 0

Alternatives and tradeoffs: SQL: a CTE with GROUP BY user_id HAVING COUNT(DISTINCT variant) = 1 and MAX(converted), then group by variant. In pandas you could also drop mixed users with groupby("user_id")["variant"].transform("nunique") == 1 on the raw events first. Either way, the important decision is the unit of analysis: users were randomised, so rates must be per user.

Follow-ups:

1. "Why is the per-view conversion rate misleading here?" Variants were assigned per user, and users who browse a lot (often the undecided ones) contribute many views without converting. A variant that makes people view the page more times would look worse per view even if more users ordered.
2. "B's rate is 0.12 and A's is 0.10. Can you ship B?" Not from the rates alone: you need sample sizes and a significance test (a two-proportion z-test or a chi-square test), plus a check that the split is about 50/50 as designed (a "sample ratio mismatch" means the assignment is broken).
3. "Excluded users are 8% of the total. What do you do?" Stop and investigate before reading the results: that many cross-over users means the assignment is unstable, and excluding them may bias the comparison (for example, if reinstalls happen more often in one variant).

Scoring: Strong: Reduces to one row per user first, uses max for "converted at least once", excludes cross-over users, and explains why the unit of analysis matters. Acceptable: Gets the per-user reduction with a hint; forgets the cross-over users or the integer dtypes. Red flag: Reports events.groupby("variant")["converted"].mean() as the conversion rate and sees no problem.

JR-DS-O01 · A left join that inflates revenue

Medium & Tricky · Output · Junior (1–3 years) · pandas, merge, duplicate keys, groupby, data validation · 6 min

Question: An analyst enriches orders with each customer's city before a revenue-by-city chart. The customer table was built by appending address updates, so customer C1 (who moved from Pune to Mumbai) appears twice. What does this print?

import pandas as pd

orders = pd.DataFrame({"order_id": [101, 102, 103],
                       "customer_id": ["C1", "C2", "C1"],
                       "amount": [500, 1200, 300]})
customers = pd.DataFrame({"customer_id": ["C1", "C2", "C1"],
                          "city": ["Pune", "Delhi", "Mumbai"]})   # C1 moved; old row kept

merged = orders.merge(customers, on="customer_id", how="left")
print(len(orders), len(merged))
print(orders["amount"].sum(), merged["amount"].sum())
print(merged.groupby("city")["amount"].sum().to_dict())
try:
    orders.merge(customers, on="customer_id", how="left", validate="many_to_one")
except pd.errors.MergeError as exc:
    print("MergeError:", exc)

Expected output:

3 5
2000 2800
{'Delhi': 1200, 'Mumbai': 800, 'Pune': 800}
MergeError: Merge keys are not unique in right dataset; not a many-to-one merge

The trap:

"A left join keeps the left table's rows, so merged has 3 rows and the total is still 2000." Tempting because "left join = one output row per left row" is how many people remember it.

Real-world bug: a revenue dashboard over-reports by exactly the orders of customers with duplicate profile rows; the number looks plausible, and it grows a little every time a customer updates their address.

Explanation:

A join produces one output row for every matching pair of rows. A left join only guarantees that every left row appears at least once (with NaN if nothing matches). Orders 101 and 103 belong to C1, which matches two customer rows, so each of them appears twice: 1 + 2 + 2 = 5 rows.

The duplicated order amounts are summed twice: 2000 + 500 + 300 = 2800. The per-city sums show the same orders counted under both Pune and Mumbai (500 + 300 = 800 in each).

validate="many_to_one" tells pandas what you expect: the right side has unique keys. It raises a MergeError instead of silently multiplying rows. The real fix is upstream: deduplicate customers to one row per id (for example, the latest address) before joining.

Takeaway: after every join, check the row count (or pass validate=); a changed row count is the cheapest bug detector you have.

Follow-ups:

1. "How would you keep only each customer's latest city?" If there's an updated_at column: customers.sort_values("updated_at").drop_duplicates("customer_id", keep="last"). Without one, the "latest" is unknowable and that is the real problem to raise with whoever owns the table.
2. "What do one_to_one, one_to_many and many_to_many check?" one_to_one: keys unique on both sides; one_to_many: unique on the left; many_to_one: unique on the right; many_to_many: no check. Use the strictest one that should hold.
3. "Should the analysis use the customer's city now, or at the time of the order?" Usually at the time of the order: revenue from 101 was earned in Pune. That needs the address history with valid-from/valid-to dates and a join on the order date, not a plain join on the id.

Scoring: Strong: All four lines; explains join cardinality (one row per matching pair) and suggests validate= or a row-count check, and raises the "city at order time" question. Acceptable: Gets 5 rows after a moment of tracing; knows to deduplicate the right table; unsure what validate does. Red flag: Fixes the total with merged.drop_duplicates() (which keeps both cities' rows, because they differ) or with .mean(), without understanding where the extra rows came from.

JR-DS-O02 · Indian DD/MM dates through pd.to_datetime

Easy & Tricky · Output · Junior (1–3 years) · pandas, to_datetime, date parsing, feature engineering, dayfirst · 5 min

Question: A sales sheet from the Chennai team writes dates the Indian way, DD/MM/YYYY. You want day-of-week features. What does this print on pandas 2.2?

import pandas as pd

raw = pd.Series(["03/04/2026", "11/04/2026", "25/04/2026"])
try:
    pd.to_datetime(raw)
except ValueError as exc:
    print("ValueError:", str(exc).split(". You")[0])
first_two = pd.to_datetime(raw[:2])
print(first_two.dt.strftime("%d %b").tolist())
ok = pd.to_datetime(raw, dayfirst=True)
print(ok.dt.strftime("%d %b").tolist())
print(ok.dt.dayofweek.tolist(), ok.dt.day_name().tolist())
print(pd.to_datetime(raw, format="%d/%m/%Y").equals(ok))

Expected output:

ValueError: time data "25/04/2026" doesn't match format "%m/%d/%Y", at position 2
['04 Mar', '04 Nov']
['03 Apr', '11 Apr', '25 Apr']
[4, 5, 5] ['Friday', 'Saturday', 'Saturday']
True

The trap:

"All three parse as April dates." Or: "pandas looks at 25 and realises the column is day-first." Tempting because a human reading the column immediately sees the format.

Real-world bug: a month's data where every date happens to have a day ≤ 12 parses without any error as the wrong dates, so "day of week" and "month" features are silently wrong, and a weekly seasonality model learns noise. The crash only appears later, on a file that contains the 13th.

Explanation:

In pandas 2.x, to_datetime infers one format from the first value and applies it to the whole column. 03/04/2026 is ambiguous; the default (dayfirst=False) reading is US-style month first, so it picks %m/%d/%Y. Then 25/04/2026 has no month 25, so the call raises and points at position 2.

With only the first two values, nothing fails: they parse as 4 March and 4 November. This is the dangerous case, because it's silent.

dayfirst=True gives 3, 11 and 25 April. dt.dayofweek counts Monday = 0, so Friday is 4 and Saturday is 5. An explicit format="%d/%m/%Y" gives the same result and is the most robust choice: no guessing, and anything that doesn't match fails loudly.

Takeaway: never let a date column's format be guessed; pass format= (or at least dayfirst=True) and check a few parsed values against the raw strings.

Follow-ups:

1. "How would you handle a column with a few unparseable values, like 'TBD'?" pd.to_datetime(col, format="%d/%m/%Y", errors="coerce") turns them into NaT. Then count the NaTs and decide; silently coercing 30% of a column to NaT is as bad as a wrong format.
2. "Which date features would you build for daily sales, and which one is easy to get wrong?" Day of week, weekend flag, month, day of month, and holiday or festival flags (Diwali, Pongal and Onam move every year, so they need a calendar table). Easy to get wrong: dayofweek starting at Monday = 0, and "week of year" around year boundaries (dt.isocalendar().week).
3. "The timestamps are actually '2026-04-03 23:30' in UTC and the business runs on IST. What changes?" Localise and convert before extracting features: .dt.tz_localize("UTC").dt.tz_convert("Asia/Kolkata"). 23:30 UTC is 05:00 the next day in IST, so the day of week changes.

Scoring: Strong: All five lines, explains the format inference from the first value, notes the silent MM/DD case and Monday = 0, and recommends an explicit format=. Acceptable: Knows about dayfirst=True and that the default is month-first; unsure whether the call raises or what the day numbers are. Red flag: Says pandas "figures out" date formats reliably, or only checks that the parse didn't raise.

JR-MLE-C01 · Build a model's feature vector from a JSON request

Easy · Coding · Junior (1–3 years) · validation, dicts, isinstance, math.isfinite, training/inference contract · 12 min

Problem:

An inference endpoint receives JSON such as {"income": 52000, "age": 31, "tenure_months": 14} and must turn it into the list of floats the model was trained on, in the training column order (the "schema").

Rules:

• The output follows schema order, never the order of keys in the request.
• A feature missing from the request uses defaults[name] if there is one; otherwise raise ValueError("missing feature: <name>").
• A key that is not in the schema raises ValueError("unknown feature: <name>"): it is usually a typo such as "incme", and silently ignoring it would score the request with the default instead.
• Values must be real numbers: int or float, but not bool, and finite (no NaN or infinity). Otherwise raise ValueError("bad value for <name>").
• Return floats.

If several problems exist, report the first one found when checking unknown keys first, then the schema in order.

Signature: def build_features(payload: dict[str, object], schema: list[str], defaults: dict[str, float]) -> list[float]:

Examples:

• build_features({'income': 52000, 'age': 31}, ['age', 'income', 'tenure_months'], {'tenure_months': 0.0}) → [31.0, 52000.0, 0.0]
• build_features({'age': 31, 'incme': 52000}, ['age', 'income'], {}) → ValueError: unknown feature: incme
• build_features({'age': True, 'income': 1}, ['age', 'income'], {}) → ValueError: bad value for age

Hints:

1. Loop over schema, not over payload.
2. set(payload) - set(schema) finds unknown keys, but sets have no order; how do you report the first one deterministically?
3. json.loads('NaN') returns a float NaN, so a JSON client can send one. math.isfinite rejects it.

Reference solution:

import math


def build_features(payload: dict[str, object], schema: list[str], defaults: dict[str, float]) -> list[float]:
    """Return the feature vector in training order, validating the request."""
    allowed = set(schema)
    for key in payload:
        if key not in allowed:
            raise ValueError(f"unknown feature: {key}")
    vector: list[float] = []
    for name in schema:
        if name in payload:
            value = payload[name]
        elif name in defaults:
            value = defaults[name]
        else:
            raise ValueError(f"missing feature: {name}")
        if isinstance(value, bool) or not isinstance(value, (int, float)) or not math.isfinite(value):
            raise ValueError(f"bad value for {name}")
        vector.append(float(value))
    return vector

Complexity: O(f + k) for f schema features and k request keys, using a set for the unknown-key check.

Tests:

schema = ["age", "income", "tenure_months"]
defaults = {"tenure_months": 0.0}

# Request key order differs from the schema.
assert build_features({"income": 52000, "age": 31, "tenure_months": 14}, schema, defaults) == [31.0, 52000.0, 14.0]
assert build_features({"income": 52000, "age": 31}, schema, defaults) == [31.0, 52000.0, 0.0]
assert all(type(x) is float for x in build_features({"income": 1, "age": 2}, schema, defaults))

def error(payload):
    try:
        build_features(payload, schema, defaults)
    except ValueError as exc:
        return str(exc)
    return None

assert error({"income": 52000}) == "missing feature: age"
assert error({"age": 31, "incme": 52000}) == "unknown feature: incme"
assert error({"age": True, "income": 1}) == "bad value for age"
assert error({"age": "31", "income": 1}) == "bad value for age"
assert error({"age": 31, "income": float("nan")}) == "bad value for income"
assert error({"age": 31, "income": float("inf")}) == "bad value for income"
assert error({"age": 31, "income": None}) == "bad value for income"

A common wrong solution (the tests catch it):

import math

def build_features(payload, schema, defaults):
    for key in payload:
        if key not in schema:
            raise ValueError(f"unknown feature: {key}")
    merged = {**defaults, **payload}
    for name in schema:
        if name not in merged:
            raise ValueError(f"missing feature: {name}")
        value = merged[name]
        if isinstance(value, bool) or not isinstance(value, (int, float)) or not math.isfinite(value):
            raise ValueError(f"bad value for {name}")
    return [float(v) for v in merged.values()]      # dict order, not schema order

Alternatives and tradeoffs: A Pydantic model with one typed field per feature (model_config = ConfigDict(extra="forbid"), StrictFloat or allow_inf_nan=False) gives the same validation with structured 422 errors in FastAPI, and you then build the vector with [getattr(m, name) for name in SCHEMA]. The schema list itself should be saved with the model at training time (for example from X_train.columns), not typed by hand in the service.

Follow-ups:

1. "Why not just do list(payload.values())?" JSON object key order is whatever the client sent. Two clients sending the same data in different orders would get different predictions, with no error anywhere.
2. "Where should schema come from?" From the training run: save list(X_train.columns) with the model artefact and load it with the model, so the service can never drift from what the model was trained on.
3. "Is it right to fill a missing feature with a default?" Only if the training data was filled the same way (same default, same rule). Otherwise the model sees a value distribution it never trained on. Defaults belong to the preprocessing step that was fitted with the model.

Scoring: Strong: Iterates in schema order, rejects unknown keys, booleans and NaN without prompting, and says the schema should be saved with the model. Acceptable: Correct order and missing-feature handling; needs a hint for booleans or NaN. Red flag: Builds the vector from payload.values(), or silently ignores unknown keys.

JR-MLE-C02 · A deterministic train/validation split by user

Medium · Coding · Junior (1–3 years) · train/validation split, data leakage, hashlib, determinism, hash randomisation · 20 min

Problem:

A recommendation model is trained on interaction rows ({"user_id": ..., "item_id": ..., ...}); each user has many rows. A random row-level split puts the same user in both train and validation, so validation measures how well the model remembers users it has already seen, not how it does on new ones.

Write split_by_user(rows, val_fraction, salt="") that returns (train, val):

• All rows of a user go to the same side.
• The assignment is deterministic across runs, machines and Python processes: the same user and salt always land on the same side, without storing a lookup table.
• Adding new users to the data never moves existing users to the other side.
• About val_fraction of the users go to validation; 0 means none and 1 means all.
• Rows keep their original relative order on each side. val_fraction outside [0, 1] raises ValueError.
• Changing salt gives a different (but again deterministic) split, for a fresh validation set.

Signature: def split_by_user(rows: list[dict], val_fraction: float, salt: str = "") -> tuple[list[dict], list[dict]]:

Constraints: Up to 10^7 rows; one pass, no sorting of the whole dataset, no randomness from random or NumPy.

Examples:

• split_by_user(rows, 0.2) where rows has 3 rows for each of 1000 users → about 200 users (600 rows) in val, the rest in train; no user in both
• same call twice, or in a new Python process → identical result

Hints:

1. You need a function from user_id to a number in [0, 1) that is stable everywhere. Is the built-in hash() stable across processes for strings?
2. hashlib.sha256(text.encode()).digest() is stable; turn its first 8 bytes into an integer with int.from_bytes.
3. Compare that number with val_fraction.

Reference solution:

import hashlib


def _bucket(user_id: object, salt: str) -> float:
    """Map a user id to a stable number in [0, 1)."""
    digest = hashlib.sha256(f"{salt}:{user_id}".encode("utf-8")).digest()
    return int.from_bytes(digest[:8], "big") / 2**64


def split_by_user(rows: list[dict], val_fraction: float, salt: str = "") -> tuple[list[dict], list[dict]]:
    """Split rows so that every user is entirely in train or entirely in validation."""
    if not 0.0 <= val_fraction <= 1.0:
        raise ValueError("val_fraction must be between 0 and 1")
    train: list[dict] = []
    val: list[dict] = []
    cache: dict[object, bool] = {}
    for row in rows:
        uid = row["user_id"]
        if uid not in cache:
            cache[uid] = _bucket(uid, salt) < val_fraction
        (val if cache[uid] else train).append(row)
    return train, val

Complexity: O(n) time for n rows (one hash per distinct user thanks to the cache), O(u) extra space for u distinct users plus the output lists.

Tests:

rows = [{"user_id": f"u{u:04d}", "item_id": i} for u in range(1000) for i in range(3)]
train, val = split_by_user(rows, 0.2)

train_users = {r["user_id"] for r in train}
val_users = {r["user_id"] for r in val}
assert not train_users & val_users                         # no user on both sides
assert len(train) + len(val) == len(rows)
assert 150 <= len(val_users) <= 250, len(val_users)        # about 20% of users
assert [r for r in rows if r in val] == val                # original order kept

assert split_by_user(rows, 0.2) == (train, val)            # deterministic

# New users don't move existing ones.
more = rows + [{"user_id": f"n{u}", "item_id": 0} for u in range(500)]
_, val_more = split_by_user(more, 0.2)
assert {r["user_id"] for r in val_more if r["user_id"].startswith("u")} == val_users

# A bigger fraction only adds users to validation.
_, val_30 = split_by_user(rows, 0.3)
assert val_users <= {r["user_id"] for r in val_30}

assert split_by_user(rows, 0.0)[1] == [] and split_by_user(rows, 1.0)[0] == []
assert {r["user_id"] for r in split_by_user(rows, 0.2, salt="v2")[1]} != val_users

for bad in (-0.1, 1.5):
    try:
        split_by_user(rows, bad)
        raise AssertionError("expected ValueError")
    except ValueError:
        pass

A common wrong solution (the tests catch it):

def split_by_user(rows, val_fraction, salt=""):
    if not 0.0 <= val_fraction <= 1.0:
        raise ValueError("val_fraction must be between 0 and 1")
    every = round(1 / val_fraction) if val_fraction else 0
    train, val = [], []
    for i, row in enumerate(rows):
        # every n-th row goes to validation: deterministic, but splits users
        (val if every and i % every == 0 else train).append(row)
    return train, val

Alternatives and tradeoffs: scikit-learn's GroupShuffleSplit or GroupKFold split by group with a seeded random generator; they are fine for one-off experiments but the assignment changes when the set of users changes. Hash-based bucketing is what production pipelines (and SQL, e.g. ABS(MOD(FARM_FINGERPRINT(user_id), 10)) < 2 in BigQuery) use because it is stable as data grows. For time-dependent data, a split by time (train on the past, validate on the future) is often more important than a split by user.

Follow-ups:

1. "Why not hash(user_id) % 100 < 20?" String hashing is randomised per process (PYTHONHASHSEED), so the same user lands on different sides in different runs or on different workers, unless someone fixes the seed. hashlib digests are the same everywhere.
2. "Why is a row-level random split a problem for this model?" Rows of the same user are strongly related. With the user in both sets, the model is graded on users it already memorised, so validation scores are optimistic and you can't tell how it does for new users.
3. "What is the salt for?" It lets you draw a new, independent split (for a new experiment, or to avoid overfitting to one fixed validation set) while keeping each split reproducible. Record the salt with the experiment's results.

Scoring: Strong: Hash-based bucketing with hashlib, explains why hash() and row-level random splits fail, keeps order, and checks the fraction bounds; mentions time-based splits as a further concern. Acceptable: Groups by user correctly but uses a seeded random shuffle of the user list; understands the stability problem once the "new users arrive" case is pointed out. Red flag: Splits rows randomly and sees no leakage problem, or uses the built-in hash() and claims it is stable.

JR-MLE-O01 · Softmax and log loss written from scratch overflow

Medium · Output · Junior (1–3 years) · numpy, softmax, log loss, numerical stability, inf and NaN, np.clip · 7 min

Question: A teammate writes softmax and binary log loss by hand for a quick evaluation script. What does this print?

import numpy as np

def softmax_naive(z):
    e = np.exp(z)
    return e / e.sum()

def softmax(z):
    e = np.exp(z - z.max())
    return e / e.sum()

logits = np.array([2.0, 1.0, 0.1])
print(softmax_naive(logits).round(3).tolist(), softmax(logits).round(3).tolist())

big = np.array([1000.0, 999.0, 10.0])
with np.errstate(over="ignore", invalid="ignore"):
    print(softmax_naive(big).tolist())
print(softmax(big).round(3).tolist())

y = np.array([1, 0, 1])
p = np.array([0.9, 0.2, 0.0])          # model was "certain" the third case was 0
with np.errstate(divide="ignore"):
    print(-np.mean(y * np.log(p) + (1 - y) * np.log(1 - p)))
q = np.clip(p, 1e-15, 1 - 1e-15)
print(round(float(-np.mean(y * np.log(q) + (1 - y) * np.log(1 - q))), 2))

Expected output:

[0.659, 0.242, 0.099] [0.659, 0.242, 0.099]
[nan, nan, 0.0]
[0.731, 0.269, 0.0]
inf
11.62

Explanation:

• For small logits both versions agree. Subtracting the maximum doesn't change softmax mathematically: exp(z - c) / sum(exp(z - c)) equals exp(z) / sum(exp(z)) for any constant c, because exp(-c) cancels.
• np.exp(1000) is larger than the biggest float64 (about 1.8e308), so it becomes inf. Then inf / inf is nan, and the third value is exp(10) / inf = 0.0. (The errstate only hides NumPy's RuntimeWarnings, which would otherwise be printed to stderr: a hint that something went wrong.)
• The stable version subtracts the max first, so the largest exponent is exp(0) = 1 and nothing overflows. The logits 1000 and 999 differ by 1, exactly like 1 and 0, so the answer is [0.731, 0.269, 0.0].
• Log loss: the model predicted probability 0.0 for an example whose label is 1. log(0) is -inf, so the mean loss is inf. One over-confident prediction makes the whole metric useless.
• Clipping probabilities to [1e-15, 1 - 1e-15] keeps the loss finite (-log(1e-15) is about 34.5 for that row, averaged over 3 rows with the two small losses gives 11.62). Libraries such as scikit-learn's log_loss clip for exactly this reason.

Takeaway: when you write numeric code by hand, keep values in a safe range (subtract the max, clip before log), and treat inf/nan in a metric as a bug signal, not as a number.

Follow-ups:

1. "Why do frameworks offer a loss that takes logits instead of probabilities (e.g. BCEWithLogitsLoss)?" They combine sigmoid/softmax with the log in one numerically stable formula (the log-sum-exp trick), so neither overflow nor log(0) can happen. Computing probabilities first and then taking the log loses that.
2. "What would you check if the training loss suddenly prints nan?" Look for inf/nan in inputs (a bad feature, division by zero in preprocessing), a learning rate that makes weights explode, and hand-written log/exp/division. np.isfinite(x).all() on inputs and outputs narrows it down quickly.
3. "Does the clipping value matter?" It caps how much a single confidently wrong prediction can cost. Any small epsilon keeps the metric finite; what matters is using the same value when comparing models.

Scoring: Strong: All five lines; explains why subtracting the max is safe and fixes overflow, inf / inf = nan, and log(0) in log loss, and knows libraries clip or work on logits. Acceptable: Gets the overflow to nan and the stable fix; needs a hint for the inf log loss or the clipped value. Red flag: Suggests silencing the warnings or replacing nan with 0 as the fix, without understanding where it came from.

JR-MLE-O02 · Category codes that change between training and serving

Easy & Tricky · Output · Junior (1–3 years) · pandas, categorical, label encoding, get_dummies, training/inference skew · 5 min

Question: A model uses the customer's city as a feature, encoded as an integer with .cat.codes. The serving code runs the same encoding on each live batch. What does this print?

import pandas as pd

train = pd.Series(["Delhi", "Pune", "Mumbai", "Delhi"])
live = pd.Series(["Pune", "Mumbai", "Pune"])

print(train.astype("category").cat.codes.tolist())
print(live.astype("category").cat.codes.tolist())

cities = train.astype("category").cat.categories
print(list(cities))
print(pd.Categorical(live, categories=cities).codes.tolist())
print(pd.Categorical(["Chennai"], categories=cities).codes.tolist())
print(list(pd.get_dummies(live).columns))

Expected output:

[0, 2, 1, 0]
[1, 0, 1]
['Delhi', 'Mumbai', 'Pune']
[2, 1, 2]
[-1]
['Mumbai', 'Pune']

The trap:

"Pune is 2 in both" or "codes follow the order the cities first appear". Tempting because the encoding code is identical in training and serving, so it feels like it must produce the same numbers.

Real-world bug: at serving time, Pune customers are scored as if they lived in Mumbai and vice versa. Nothing errors, the model's online accuracy quietly drops, and offline evaluation still looks perfect.

Explanation:

astype("category") builds the categories from the values present in that Series, sorted. Training sees Delhi, Mumbai, Pune → codes 0, 1, 2, so the training codes are [0, 2, 1, 0]. The live batch has no Delhi, so its categories are Mumbai, Pune → 0, 1: Pune is now 1 instead of 2, and Mumbai 0 instead of 1.

Passing the training categories explicitly (pd.Categorical(live, categories=cities)) gives the right codes [2, 1, 2]. A city never seen in training gets code -1, which you must handle deliberately (an "unknown" bucket, or reject the request), not feed to the model as if it were a real category.

get_dummies has the same problem in another form: the live batch produces only the columns for cities it contains, so the feature matrix has a different number of columns than in training.

Takeaway: any encoding learned from data (category lists, vocabularies, scaler stats) is part of the model and must be saved at training time and reused at serving time.

Follow-ups:

1. "How do you make get_dummies produce the training columns at serving time?" Save the training column list and reindex(columns=train_columns, fill_value=0) after get_dummies, or better, use scikit-learn's OneHotEncoder(handle_unknown="ignore") fitted on train and saved with the model.
2. "Would a test have caught this?" A test that encodes a small live batch which is missing one training category and compares the codes or the prediction with the offline pipeline would catch it. A test that reuses the training data at serving time would not.
3. "What should happen for the code -1?" Decide explicitly: map it to an "other" category that existed in training, or return a validation error. Log and count unknown values; a spike usually means an upstream change (a new city launch, or a spelling change).

Scoring: Strong: All six lines; explains sorted categories built per Series, knows -1 means unknown, and says the category list must be saved with the model. Acceptable: Realises the codes differ between the two batches; unsure about the -1 or the get_dummies columns. Red flag: Thinks sorting both batches the same way fixes it, or that label codes are stable because "Pune is always Pune".

JR-BE-C01 · CRUD endpoints for a product catalogue with validation

Medium · Coding · Junior (1–3 years) · FastAPI, Pydantic, CRUD, validation, status codes, testing · 25 min

Problem:

Build a small FastAPI app for a kirana store's product catalogue. Keep the data in memory, but each app created by create_app() must have its own store, so tests don't leak into each other.

Endpoints:

• POST /products with a JSON body {"sku", "name", "price_paise", "stock"}:
• sku: 3–20 characters of letters, digits or -; stored upper-cased, so "atta-5kg" and "ATTA-5KG" are the same product;
• name: 1–100 characters after stripping spaces (store the stripped value);
• price_paise: integer > 0; stock: integer ≥ 0, default 0.

Returns 201 with the stored product plus an id (1, 2, 3, … per app). Invalid input → 422 (FastAPI's default). A SKU that already exists → 409 with {"detail": "sku already exists"}. - GET /products/{id} → 200 with the product, or 404 {"detail": "product not found"}. - GET /products → 200 with all products, ordered by id. - DELETE /products/{id} → 204 with an empty body, or 404 as above.

Signature: def create_app() -> FastAPI:

Constraints: Use Pydantic v2 models for the request and response bodies. No database; a dict per app is fine.

Examples:

• POST /products {"sku": "atta-5kg", "name": " Aashirvaad Atta 5kg ", "price_paise": 28500} → 201 {"id": 1, "sku": "ATTA-5KG", "name": "Aashirvaad Atta 5kg", "price_paise": 28500, "stock": 0}
• POST /products {"sku": "ATTA-5KG", ...} again → 409 {"detail": "sku already exists"}
• POST /products {"sku": "x", "name": "", "price_paise": 0} → 422

Hints:

1. Put the rules on the model: Field(pattern=..., min_length=..., gt=0). Which rule needs a field_validator because it changes the value?
2. Create the dict and the id counter inside create_app, so they belong to that app.
3. status_code=201 / 204 go on the route decorator; a 204 route should return Response(status_code=204).

Reference solution:

from fastapi import FastAPI, HTTPException, Response
from pydantic import BaseModel, Field, field_validator


class ProductIn(BaseModel):
    sku: str = Field(pattern=r"^[A-Za-z0-9-]{3,20}$")
    name: str
    price_paise: int = Field(gt=0)
    stock: int = Field(default=0, ge=0)

    @field_validator("sku")
    @classmethod
    def upper_sku(cls, value: str) -> str:
        return value.upper()

    @field_validator("name")
    @classmethod
    def clean_name(cls, value: str) -> str:
        value = value.strip()
        if not 1 <= len(value) <= 100:
            raise ValueError("name must be 1-100 characters")
        return value


class Product(ProductIn):
    id: int


def create_app() -> FastAPI:
    app = FastAPI()
    products: dict[int, Product] = {}
    next_id = 1

    def get_or_404(product_id: int) -> Product:
        product = products.get(product_id)
        if product is None:
            raise HTTPException(status_code=404, detail="product not found")
        return product

    @app.post("/products", status_code=201, response_model=Product)
    def create_product(body: ProductIn) -> Product:
        nonlocal next_id
        if any(p.sku == body.sku for p in products.values()):
            raise HTTPException(status_code=409, detail="sku already exists")
        product = Product(id=next_id, **body.model_dump())
        products[next_id] = product
        next_id += 1
        return product

    @app.get("/products", response_model=list[Product])
    def list_products() -> list[Product]:
        return [products[k] for k in sorted(products)]

    @app.get("/products/{product_id}", response_model=Product)
    def read_product(product_id: int) -> Product:
        return get_or_404(product_id)

    @app.delete("/products/{product_id}", status_code=204)
    def delete_product(product_id: int) -> Response:
        get_or_404(product_id)
        del products[product_id]
        return Response(status_code=204)

    return app

Complexity: Create is O(n) because of the duplicate-SKU scan; an extra sku → id dict makes it O(1). Get and delete are O(1); list is O(n log n) for the sort (or O(n) if ids are kept in insertion order).

Tests:

from fastapi.testclient import TestClient

client = TestClient(create_app())
r = client.post("/products", json={"sku": "atta-5kg", "name": " Aashirvaad Atta 5kg ", "price_paise": 28500})
assert r.status_code == 201, r.text
assert r.json() == {"id": 1, "sku": "ATTA-5KG", "name": "Aashirvaad Atta 5kg", "price_paise": 28500, "stock": 0}

r = client.post("/products", json={"sku": "ATTA-5KG", "name": "Duplicate", "price_paise": 100})
assert r.status_code == 409 and r.json() == {"detail": "sku already exists"}

for bad in (
    {"sku": "x", "name": "Salt", "price_paise": 2000},              # sku too short
    {"sku": "SALT 1KG", "name": "Salt", "price_paise": 2000},       # space in sku
    {"sku": "SALT-1KG", "name": "   ", "price_paise": 2000},        # blank name
    {"sku": "SALT-1KG", "name": "Salt", "price_paise": 0},          # price not > 0
    {"sku": "SALT-1KG", "name": "Salt", "price_paise": 2000, "stock": -1},
    {"sku": "SALT-1KG", "name": "Salt"},                            # missing price
):
    assert client.post("/products", json=bad).status_code == 422, bad

r = client.post("/products", json={"sku": "salt-1kg", "name": "Tata Salt", "price_paise": 2800, "stock": 40})
assert r.status_code == 201 and r.json()["id"] == 2

assert client.get("/products/2").json()["stock"] == 40
assert [p["id"] for p in client.get("/products").json()] == [1, 2]
r = client.get("/products/99")
assert r.status_code == 404 and r.json() == {"detail": "product not found"}

r = client.delete("/products/1")
assert r.status_code == 204 and r.content == b""
assert client.get("/products/1").status_code == 404
assert client.delete("/products/1").status_code == 404
assert [p["id"] for p in client.get("/products").json()] == [2]

# A second app starts empty: no shared module-level state.
other = TestClient(create_app())
assert other.get("/products").json() == []
assert other.post("/products", json={"sku": "salt-1kg", "name": "Tata Salt", "price_paise": 2800}).json()["id"] == 1

A common wrong solution (the tests catch it):

from fastapi import FastAPI, HTTPException, Response
from pydantic import BaseModel, Field, field_validator

class ProductIn(BaseModel):
    sku: str = Field(pattern=r"^[A-Za-z0-9-]{3,20}$")
    name: str
    price_paise: int = Field(gt=0)
    stock: int = Field(default=0, ge=0)

    @field_validator("name")
    @classmethod
    def clean_name(cls, value):
        value = value.strip()
        if not 1 <= len(value) <= 100:
            raise ValueError("name must be 1-100 characters")
        return value

class Product(ProductIn):
    id: int

PRODUCTS = {}            # module-level store shared by every app

def create_app():
    app = FastAPI()

    @app.post("/products", status_code=201, response_model=Product)
    def create_product(body: ProductIn):
        if any(p.sku == body.sku for p in PRODUCTS.values()):   # case-sensitive
            raise HTTPException(status_code=409, detail="sku already exists")
        product = Product(id=len(PRODUCTS) + 1, **body.model_dump())
        PRODUCTS[product.id] = product
        return product

    @app.get("/products", response_model=list[Product])
    def list_products():
        return [PRODUCTS[k] for k in sorted(PRODUCTS)]

    @app.get("/products/{product_id}", response_model=Product)
    def read_product(product_id: int):
        if product_id not in PRODUCTS:
            raise HTTPException(status_code=404, detail="product not found")
        return PRODUCTS[product_id]

    @app.delete("/products/{product_id}", status_code=204)
    def delete_product(product_id: int):
        if product_id not in PRODUCTS:
            raise HTTPException(status_code=404, detail="product not found")
        del PRODUCTS[product_id]
        return Response(status_code=204)

    return app

Alternatives and tradeoffs: In a real service the store is a database table with a UNIQUE constraint on sku: insert and catch the integrity error to return 409, instead of check-then-insert, which races when two requests arrive together. Separate models for create, update and response (ProductIn, ProductUpdate, ProductOut) keep server-owned fields like id out of the request body.

Follow-ups:

1. "Why does id = len(products) + 1 break after a delete?" Create 1 and 2, delete 1, and the next product also gets id 2, overwriting an existing product. Use a counter that only goes up (or the database's sequence).
2. "Two requests create the same SKU at the same moment. What happens with the check-then-insert code in a multi-worker deployment?" Both checks can pass before either inserts, so you get two products with one SKU. Only a unique constraint in a shared database prevents it; the API then maps the integrity error to 409.
3. "How would you add PATCH /products/{id} without wiping fields the client didn't send?" A ProductUpdate model with every field optional, then body.model_dump(exclude_unset=True) to get only the fields the client sent, validated with the same rules, and merged into the stored product.

Scoring: Strong: Validation lives on the Pydantic model, SKU normalised before the duplicate check, correct 201/204/404/409, state created inside create_app, ids from a counter; mentions a unique constraint for real databases. Acceptable: Endpoints work; misses case-insensitive SKUs or the per-app state until the tests show it; 204 handled after a hint. Red flag: Returns 200 with {"error": ...} for every failure, or validates by hand in each endpoint with if chains and inconsistent status codes.

JR-BE-C02 · Salted password hashing with PBKDF2

Medium · Coding · Junior (1–3 years) · authentication, hashlib, hmac, secrets, string formats · 20 min

Problem:

Your team's user table stores passwords as plain SHA-256 hex digests. Replace that with salted, slow hashing using only the standard library.

• hash_password(password, iterations=600_000) returns a single string "pbkdf2_sha256$<iterations>$<salt_hex>$<hash_hex>", using hashlib.pbkdf2_hmac("sha256", ...) with a fresh random 16-byte salt for every call. An empty password raises ValueError.
• verify_password(password, stored) returns True only if password produces the stored hash, using the iterations and salt from the stored string (so old hashes keep working after you raise the default). It compares in constant time. A malformed or unknown-format stored value returns False; it never raises.

Signature: def hash_password(password: str, iterations: int = 600_000) -> str: ... / def verify_password(password: str, stored: str) -> bool:

Constraints: Standard library only. Passwords are Unicode: encode them as UTF-8. Tests use a small iterations value to run fast.

Examples:

• hash_password('Chai@1234', iterations=1000) → 'pbkdf2_sha256$1000$<32 hex chars>$<64 hex chars>'
• verify_password('Chai@1234', that_string) → True
• verify_password('chai@1234', that_string) → False

Hints:

1. secrets.token_bytes(16) (or os.urandom(16)) gives a cryptographically random salt; bytes.hex() and bytes.fromhex() convert both ways.
2. In verify_password, split the stored string on $ and check you got exactly four parts before using them.
3. hmac.compare_digest(a, b) compares without stopping at the first difference.

Reference solution:

import hashlib
import hmac
import secrets

ALGORITHM = "pbkdf2_sha256"


def _derive(password: str, salt: bytes, iterations: int) -> bytes:
    return hashlib.pbkdf2_hmac("sha256", password.encode("utf-8"), salt, iterations)


def hash_password(password: str, iterations: int = 600_000) -> str:
    """Return a self-describing salted PBKDF2-SHA256 hash of `password`."""
    if not password:
        raise ValueError("password must not be empty")
    salt = secrets.token_bytes(16)
    digest = _derive(password, salt, iterations)
    return f"{ALGORITHM}${iterations}${salt.hex()}${digest.hex()}"


def verify_password(password: str, stored: str) -> bool:
    """Check `password` against a string produced by `hash_password`."""
    parts = stored.split("$")
    if len(parts) != 4 or parts[0] != ALGORITHM:
        return False
    try:
        iterations = int(parts[1])
        salt = bytes.fromhex(parts[2])
        expected = bytes.fromhex(parts[3])
    except ValueError:
        return False
    if iterations < 1 or not salt or not expected:
        return False
    return hmac.compare_digest(_derive(password, salt, iterations), expected)

Complexity: Deliberately slow: O(iterations) hash computations per call (roughly a tenth of a second or more at 600,000 on one modern CPU core), which is the point: it makes offline guessing expensive. O(1) memory. Budget for it: a login endpoint that hashes on every request needs that CPU time per login.

Tests:

import hashlib

h1 = hash_password("Chai@1234", iterations=1000)
h2 = hash_password("Chai@1234", iterations=1000)
algo, iters, salt_hex, hash_hex = h1.split("$")
assert algo == "pbkdf2_sha256" and iters == "1000"
assert len(salt_hex) == 32 and len(hash_hex) == 64
assert h1 != h2                                   # fresh salt each time
assert hash_hex == hashlib.pbkdf2_hmac("sha256", b"Chai@1234", bytes.fromhex(salt_hex), 1000).hex()

assert verify_password("Chai@1234", h1) and verify_password("Chai@1234", h2)
assert not verify_password("chai@1234", h1)
assert not verify_password("Chai@1234 ", h1)

# Unicode passwords round-trip.
hu = hash_password("पासवर्ड-2026", iterations=1000)
assert verify_password("पासवर्ड-2026", hu) and not verify_password("पासवर्ड-2025", hu)

# Iterations come from the stored string, not the default.
h_old = hash_password("legacy-pass", iterations=500)
assert verify_password("legacy-pass", h_old)

# Malformed values never raise.
for bad in ("", "5f4dcc3b5aa765d61d8327deb882cf99", "pbkdf2_sha256$abc$00$00",
            "pbkdf2_sha256$1000$zz$00", "md5$1000$00$00", h1 + "$extra"):
    assert verify_password("Chai@1234", bad) is False, bad

try:
    hash_password("")
    raise AssertionError("expected ValueError")
except ValueError:
    pass

A common wrong solution (the tests catch it):

import hashlib
import hmac

SALT = b"kirana-app-salt!"          # one fixed salt for every user

def hash_password(password, iterations=600_000):
    if not password:
        raise ValueError("password must not be empty")
    digest = hashlib.pbkdf2_hmac("sha256", password.encode("utf-8"), SALT, iterations)
    return f"pbkdf2_sha256${iterations}${SALT.hex()}${digest.hex()}"

def verify_password(password, stored):
    parts = stored.split("$")
    if len(parts) != 4 or parts[0] != "pbkdf2_sha256":
        return False
    try:
        iterations, salt, expected = int(parts[1]), bytes.fromhex(parts[2]), bytes.fromhex(parts[3])
    except ValueError:
        return False
    digest = hashlib.pbkdf2_hmac("sha256", password.encode("utf-8"), salt, iterations)
    return hmac.compare_digest(digest, expected)

Alternatives and tradeoffs: Prefer a vetted library in production: argon2-cffi (Argon2id, memory-hard) or bcrypt, usually through a framework helper such as Django's password hashers or passlib/pwdlib. hashlib.scrypt is also in the standard library and is memory-hard. The self-describing format (algorithm$params$salt$hash) is what those libraries use, so you can upgrade parameters later and rehash on the user's next successful login.

Follow-ups:

1. "Why is plain SHA-256 a bad password hash, even with a salt?" It's designed to be fast: a GPU computes billions per second, so common passwords fall quickly. A password hash must be slow (and ideally memory-hard) on purpose. The salt only stops precomputed tables and identical passwords producing identical hashes.
2. "How do you migrate existing users from SHA-256 to PBKDF2 without asking everyone to reset?" On each successful login (when you have the plain password), verify with the old scheme and immediately store the new hash. Optionally wrap old hashes now: PBKDF2 over the old SHA-256 digest, marked with its own algorithm name, so no weak hashes remain at rest.
3. "Why hmac.compare_digest instead of ==?" == stops at the first differing byte, so response time leaks how many leading bytes matched. With slow hashing the risk here is small, but constant-time comparison is the habit to have for every secret (tokens, API keys, signatures).

Scoring: Strong: Random salt per call, iterations and salt read back from the stored string, compare_digest, False on malformed input; explains why fast hashes are wrong and how to migrate. Acceptable: Correct hashing and verification; forgets the malformed-input cases or uses the default iterations when verifying, and fixes it after the tests. Red flag: Uses one global salt, stores passwords encrypted (reversibly) "so support can read them", or uses random for the salt.

JR-BE-O01 · sqlite3 with f-strings, parameters and rowcount

Easy & Tricky · Output · Junior (1–3 years) · sqlite3, SQL injection, parameterised queries, rowcount, CRUD · 6 min

Question: A small customer service stores data in SQLite. What does this print?

import sqlite3

conn = sqlite3.connect(":memory:")
conn.execute("CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT NOT NULL, city TEXT)")

cur = conn.execute("INSERT INTO customers (name, city) VALUES (?, ?)", ("Asha Rao", "Pune"))
print(cur.lastrowid, cur.rowcount)

name = "Neil D'Souza"
try:
    conn.execute(f"INSERT INTO customers (name, city) VALUES ('{name}', 'Goa')")
except sqlite3.OperationalError as exc:
    print("OperationalError:", exc)
conn.execute("INSERT INTO customers (name, city) VALUES (?, ?)", (name, "Goa"))

cur = conn.execute("UPDATE customers SET city = ? WHERE id = ?", ("Mumbai", 99))
print(cur.rowcount)

search = "x' OR '1'='1"
rows = conn.execute(f"SELECT name FROM customers WHERE city = '{search}'").fetchall()
print(rows)
print(conn.execute("SELECT name FROM customers WHERE city = ?", (search,)).fetchall())

print(conn.execute("SELECT * FROM customers WHERE id = ?", (99,)).fetchone())
conn.row_factory = sqlite3.Row
row = conn.execute("SELECT * FROM customers WHERE id = ?", (2,)).fetchone()
print(dict(row))

Expected output:

1 1
OperationalError: near "Souza": syntax error
0
[('Asha Rao',), ("Neil D'Souza",)]
[]
None
{'id': 2, 'name': "Neil D'Souza", 'city': 'Goa'}

The trap:

"The update of customer 99 raises an error, and the search for that odd city returns []." Tempting because "updating something that doesn't exist" feels like an error, and the f-string query reads like a normal search.

Real-world bug: PUT /customers/99 returns 200 "updated" for a customer that doesn't exist, because nobody checked rowcount. And a search box built with an f-string returns every customer to anyone who types a quote, which is a data breach, not a bug.

Explanation:

• lastrowid is the id SQLite assigned to the inserted row (1); rowcount is how many rows the statement changed (1).
• Building SQL with an f-string pastes the value into the SQL text. The apostrophe in D'Souza ends the string literal early, and SQLite sees Souza' as garbage: a syntax error. Real customer names break your app.
• With ? placeholders the value is sent separately from the SQL, so any characters are just data.
• An UPDATE (or DELETE) that matches no rows is not an error: it succeeds and rowcount is 0. Your API has to check that and return 404 itself.
• The search string x' OR '1'='1 turns the f-string query into WHERE city = 'x' OR '1'='1', which is true for every row: SQL injection. With a parameter, the database looks for a city literally named that, and finds none.
• fetchone() returns None when nothing matches (check it before indexing), and sqlite3.Row lets you access columns by name and convert a row with dict(row).

Takeaway: never build SQL with string formatting; always use parameters, and check rowcount / None to detect "not found".

Follow-ups:

1. "Can you use a parameter for a table or column name, e.g. a user-chosen sort column?" No: parameters are only for values. Check the name against an allow-list ({"name", "city", "created_at"}) and only then put it into the SQL text.
2. "How does an ORM like SQLAlchemy relate to this?" It builds parameterised SQL for you, so normal ORM queries are safe. Raw SQL through the ORM (text(...)) still needs bound parameters (:name), not f-strings.
3. "What would your PUT /customers/{id} endpoint do with rowcount == 0?" Return 404 Not Found (or, if your API supports create-by-PUT, insert and return 201). Never report success when nothing was written.

Scoring: Strong: All seven lines; explains the quote breaking the f-string, SQL injection, that zero-row updates aren't errors, and uses parameters plus rowcount checks. Acceptable: Knows about parameters and injection; expects the missing update to raise, but understands rowcount once shown. Red flag: "Fixes" the D'Souza problem by escaping quotes by hand or stripping apostrophes from names.

JR-BE-O02 · When a FastAPI yield dependency runs, and how often

Medium · Output · Junior (1–3 years) · FastAPI, dependencies, Depends, yield, request lifecycle, resource cleanup · 6 min

Question: An order service opens a database session per request with a yield dependency. The auth dependency also needs the session. What does this print?

from fastapi import Depends, FastAPI, HTTPException
from fastapi.testclient import TestClient

events = []
app = FastAPI()

def get_db():
    events.append("open")
    try:
        yield {"orders": {1: "₹499 thali"}}
    finally:
        events.append("close")

def current_user(db: dict = Depends(get_db)) -> str:
    events.append("auth")
    return "asha"

@app.get("/orders/{order_id}")
def read_order(order_id: int, user: str = Depends(current_user), db: dict = Depends(get_db)):
    events.append("handler")
    if order_id not in db["orders"]:
        raise HTTPException(status_code=404, detail="order not found")
    return {"order": db["orders"][order_id], "user": user}

client = TestClient(app)
print(client.get("/orders/1").json())
print(events)
events.clear()
r = client.get("/orders/7")
print(r.status_code, events)

Expected output:

{'order': '₹499 thali', 'user': 'asha'}
['open', 'auth', 'handler', 'close']
404 ['open', 'auth', 'handler', 'close']

Explanation:

• get_db is used twice in one request: directly by the route and indirectly through current_user. FastAPI caches a dependency's result within a request, so get_db runs once and both receive the same session. That is what you want for a database session: auth and the handler see the same transaction.
• A yield dependency is a setup/teardown pair: the code before yield runs before the handler, the value is injected, and the code after yield runs when the request is finished. With try/finally, the cleanup runs even when the handler raises, as the 404 request shows.
• Dependencies are resolved before the handler, in order: get_db, then current_user, then the handler.
• Nothing is shared across requests: each request opens and closes its own session.

Takeaway: per-request resources (DB sessions, clients that must be closed) belong in a yield dependency with try/finally; FastAPI gives every dependency in the request the same instance.

Follow-ups:

1. "When would you want a dependency to run again instead of using the cached value?" Rarely, for example a dependency that must produce a fresh value each time it's used. Depends(get_db, use_cache=False) turns off the per-request cache for that use.
2. "Where should you commit the transaction, and what happens on an error?" A common pattern is commit after yield if no exception occurred and roll back in except, then close in finally. Then the handler doesn't need to remember to commit, and a failing request never commits half its work.
3. "How would you replace get_db with an in-memory fake in tests?" app.dependency_overrides[get_db] = fake_get_db before creating the TestClient, and clear it afterwards. Both the route and current_user then receive the fake, because they depend on the same function.

Scoring: Strong: All three lines; explains the per-request cache (one open despite two uses), the order of resolution, and that finally runs after an HTTPException. Acceptable: Gets the order right but expects open twice; understands the cache once told. Red flag: Opens a global database connection at import time and shares it across all requests without thinking about cleanup or concurrent use.

JR-FS-C01 · A "Download as CSV" export that is safe to open in Excel

Medium · Coding · Junior (1–3 years) · csv, io.StringIO, CSV formula injection, type formatting, file downloads · 20 min

Problem:

The admin dashboard of a coaching institute has a "Download as CSV" button for the enquiries table. The rows come from user-submitted forms. Write the function that produces the file's text (the endpoint will return it with media_type="text/csv").

• columns is a list of (key, header) pairs: the header row uses the headers, and each data row takes the values for those keys in that order. A key missing from a row gives an empty cell.
• Formatting: None → empty; True/False → Yes/No; date/datetime → isoformat(); numbers → str(); strings as they are, except as below.
• Formula injection: a spreadsheet treats a cell starting with =, +, - or @ (also a tab or carriage return) as a formula, so a visitor who types =HYPERLINK("http://evil.example","Click") into the enquiry form gets a live link in your staff's spreadsheet. Prefix such strings with a single quote '. Numbers (including negative ones) are not changed.
• Commas, quotes and newlines inside values must survive a round trip through a CSV reader.
• Start the text with a UTF-8 byte-order mark ("") so Excel on Windows shows ₹ and Hindi names correctly, and use the csv module's default \r\n line endings.

Signature: def export_csv(rows: list[dict], columns: list[tuple[str, str]]) -> str:

Examples:

• export_csv([{'name': 'Asha', 'fee': 4500, 'paid': True}], [('name', 'Name'), ('fee', 'Fee (₹)'), ('paid', 'Paid')]) → '\ufeffName,Fee (₹),Paid\r\nAsha,4500,Yes\r\n'
• a row whose name is '=1+1' → the cell is "'=1+1"
• a row whose fee is -500 → the cell is -500 (numbers are never prefixed)

Hints:

1. csv.writer(io.StringIO()) handles quoting for you; getvalue() returns the text.
2. Check bool before int: isinstance(True, int) is True.
3. str.startswith accepts a tuple of prefixes.

Reference solution:

import csv
import io
from datetime import date

FORMULA_START = ("=", "+", "-", "@", "\t", "\r")


def _cell(value: object) -> str:
    if value is None:
        return ""
    if isinstance(value, bool):
        return "Yes" if value else "No"
    if isinstance(value, date):            # datetime is a subclass of date
        return value.isoformat()
    if isinstance(value, str):
        return "'" + value if value.startswith(FORMULA_START) else value
    return str(value)


def export_csv(rows: list[dict], columns: list[tuple[str, str]]) -> str:
    """Render rows as CSV text that opens safely in spreadsheet apps."""
    buffer = io.StringIO()
    writer = csv.writer(buffer)
    writer.writerow([header for _, header in columns])
    for row in rows:
        writer.writerow([_cell(row.get(key)) for key, _ in columns])
    return "" + buffer.getvalue()

Complexity: O(total size of the output) time and memory, since the whole file is built in a StringIO.

Tests:

from datetime import date, datetime
from decimal import Decimal

cols = [("name", "Name"), ("fee", "Fee (₹)"), ("paid", "Paid")]
assert export_csv([{"name": "Asha", "fee": 4500, "paid": True}], cols) == "Name,Fee (₹),Paid\r\nAsha,4500,Yes\r\n"
assert export_csv([], cols) == "Name,Fee (₹),Paid\r\n"

rows = [
    {"name": "=HYPERLINK(\"http://evil.example\",\"Click\")", "fee": -500, "paid": False,
     "note": "+91 98765 43210", "city": "@home", "joined": date(2026, 4, 1)},
    {"name": "Rao, Priya", "fee": Decimal("1999.50"), "paid": None,
     "note": "Said \"call after 6\"\nprefers Hindi", "city": "-", "joined": datetime(2026, 4, 2, 18, 30)},
    {"name": "राहुल", "fee": 0},
]
cols2 = [("name", "Name"), ("fee", "Fee"), ("paid", "Paid"), ("note", "Note"), ("city", "City"), ("joined", "Joined")]
text = export_csv(rows, cols2)
assert text.startswith("Name,Fee,Paid,Note,City,Joined\r\n")

parsed = list(csv.reader(io.StringIO(text[1:], newline="")))
assert parsed[0] == ["Name", "Fee", "Paid", "Note", "City", "Joined"]
assert parsed[1] == ["'=HYPERLINK(\"http://evil.example\",\"Click\")", "-500", "No",
                     "'+91 98765 43210", "'@home", "2026-04-01"]
assert parsed[2] == ["Rao, Priya", "1999.50", "", "Said \"call after 6\"\nprefers Hindi", "'-",
                     "2026-04-02T18:30:00"]
assert parsed[3] == ["राहुल", "0", "", "", "", ""]
assert len(parsed) == 4

A common wrong solution (the tests catch it):

import csv
import io
from datetime import date

def _cell(value):
    if value is None:
        return ""
    if isinstance(value, bool):
        return "Yes" if value else "No"
    if isinstance(value, date):
        return value.isoformat()
    if isinstance(value, str):
        return "'" + value if value.startswith("=") else value   # only guards '='
    return str(value)

def export_csv(rows, columns):
    buffer = io.StringIO()
    writer = csv.writer(buffer)
    writer.writerow([header for _, header in columns])
    for row in rows:
        writer.writerow([_cell(row.get(key)) for key, _ in columns])
    return "" + buffer.getvalue()

Alternatives and tradeoffs: pandas.DataFrame.to_csv is convenient but won't sanitise formulas for you, and it formats None/NaN and booleans its own way. For large exports, stream the response: a generator that writes one row at a time to a small buffer and yields it, passed to FastAPI's StreamingResponse, so memory stays flat. If staff need real formatting (currency, column widths), generate .xlsx with a library such as openpyxl, writing values as text cells.

Follow-ups:

1. "Why only prefix strings and not negative numbers?" A number cell is data and can't execute anything; prefixing -500 would turn it into text and break sums in the spreadsheet. The danger is user-controlled text that a spreadsheet interprets as a formula.
2. "The file is downloaded with a name like enquiries.csv. What header sets that?" Content-Disposition: attachment; filename="enquiries.csv". Set it on the response; if the filename includes user input (a batch name), sanitise it too.
3. "Why not just ','.join(str(v) for v in values)?" A value containing a comma, quote or newline (Rao, Priya, an address, a note) would shift columns or split rows. The csv module quotes such fields and doubles embedded quotes, so a reader gets the original value back.

Scoring: Strong: Uses csv.writer, orders by columns, checks bool before numbers, sanitises all formula prefixes for strings only, adds the BOM, and explains why formula injection matters. Acceptable: Correct CSV and formatting; sanitises only = or forgets the BOM until the tests show it. Red flag: Joins values with commas by hand, or strips "dangerous" characters from user data instead of escaping at export.

JR-FS-C02 · Validate an uploaded document and make its filename safe

Medium · Coding · Junior (1–3 years) · file uploads, bytes, path traversal, regex, input validation · 20 min

Problem:

A loan-application form lets users upload ID proof (PAN card, Aadhaar, salary slip) as an image or PDF. The browser sends a filename and the file's bytes. Write check_upload(filename, data, max_bytes) that either returns a safe name to store the file under, or raises ValueError with one of these exact messages, checked in this order:

1. "empty file" if data is empty; "file too large" if it's longer than max_bytes.
2. "file type not allowed" unless the extension (the part from the last dot, compared case-insensitively) is .png, .jpg, .jpeg or .pdf. A name with no dot is not allowed.
3. "content does not match extension" unless data starts with the right signature ("magic bytes"): PNG b"\x89PNG\r\n\x1a\n", JPEG b"\xff\xd8\xff", PDF b"%PDF-". Users rename .exe files to .pdf.

The safe name:

• keeps only the last path component; the browser may send C:\Users\Asha\Pictures\pan.jpg, and an attacker may send ../../app/config.pdf, so treat both / and \ as separators;
• replaces every character other than ASCII letters, digits, ., _ and - with _;
• strips leading dots and underscores, so the result can never be ..-something or a hidden file;
• keeps at most 50 characters of the stem, uses "file" if nothing is left, and adds the extension in lower case.

Signature: def check_upload(filename: str, data: bytes, max_bytes: int = 2_000_000) -> str:

Examples:

• check_upload('Aadhaar Card (front).JPG', jpeg_bytes) → 'Aadhaar_Card__front_.jpg'
• check_upload('C:\\Users\\Asha\\Pictures\\pan.jpg', jpeg_bytes) → 'pan.jpg'
• check_upload('salary.pdf', png_bytes) → ValueError: content does not match extension
• check_upload('invoice.pdf.exe', pdf_bytes) → ValueError: file type not allowed

Hints:

1. re.split(r'[\\/]', name)[-1] gives the last component for both kinds of separator; os.path.basename only knows the current OS's separator.
2. str.rpartition('.') splits at the last dot. What does os.path.splitext('.pdf') return?
3. bytes.startswith works like the str version.

Reference solution:

import re

SIGNATURES = {
    ".png": b"\x89PNG\r\n\x1a\n",
    ".jpg": b"\xff\xd8\xff",
    ".jpeg": b"\xff\xd8\xff",
    ".pdf": b"%PDF-",
}
UNSAFE = re.compile(r"[^A-Za-z0-9._-]")


def check_upload(filename: str, data: bytes, max_bytes: int = 2_000_000) -> str:
    """Validate an uploaded file and return a safe storage name, or raise ValueError."""
    if not data:
        raise ValueError("empty file")
    if len(data) > max_bytes:
        raise ValueError("file too large")
    name = re.split(r"[\\/]", filename)[-1]
    stem, dot, ext = name.rpartition(".")
    if not dot:
        raise ValueError("file type not allowed")
    ext = "." + ext.lower()
    if ext not in SIGNATURES:
        raise ValueError("file type not allowed")
    if not data.startswith(SIGNATURES[ext]):
        raise ValueError("content does not match extension")
    stem = UNSAFE.sub("_", stem).lstrip("._")[:50] or "file"
    return stem + ext

Complexity: O(len(filename)) for the name handling plus O(1) for the signature check; len(data) is O(1) on bytes. The bigger concern in a real app is memory: check the size while streaming the upload, not after reading it all.

Tests:

PNG = b"\x89PNG\r\n\x1a\n" + b"\x00" * 20
JPG = b"\xff\xd8\xff\xe0" + b"\x00" * 20
PDF = b"%PDF-1.7\n" + b"\x00" * 20

assert check_upload("Aadhaar Card (front).JPG", JPG) == "Aadhaar_Card__front_.jpg"
assert check_upload("C:\\Users\\Asha\\Pictures\\pan.jpg", JPG) == "pan.jpg"
assert check_upload("../../app/config.pdf", PDF) == "config.pdf"
assert check_upload("..\\..\\static\\logo.png", PNG) == "logo.png"
assert check_upload("....pdf", PDF) == "file.pdf"
assert check_upload(".pdf", PDF) == "file.pdf"
assert check_upload("आधार.pdf", PDF) == "file.pdf"
assert check_upload("salary.slip.march.pdf", PDF) == "salary.slip.march.pdf"
assert check_upload("x" * 80 + ".png", PNG) == "x" * 50 + ".png"
assert check_upload("scan.jpeg", JPG) == "scan.jpeg"

def error(*args):
    try:
        check_upload(*args)
    except ValueError as exc:
        return str(exc)
    return None

assert error("a.pdf", b"") == "empty file"
assert error("a.pdf", PDF, 10) == "file too large"
assert error("invoice.pdf.exe", PDF) == "file type not allowed"
assert error("README", PDF) == "file type not allowed"
assert error("pan.png\x00.exe", PNG) == "file type not allowed"
assert error("salary.pdf", PNG) == "content does not match extension"
assert error("photo.jpg", b"MZ\x90\x00 pretend exe") == "content does not match extension"

A common wrong solution (the tests catch it):

import os
import re

SIGNATURES = {".png": b"\x89PNG\r\n\x1a\n", ".jpg": b"\xff\xd8\xff", ".jpeg": b"\xff\xd8\xff", ".pdf": b"%PDF-"}

def check_upload(filename, data, max_bytes=2_000_000):
    if not data:
        raise ValueError("empty file")
    if len(data) > max_bytes:
        raise ValueError("file too large")
    name = os.path.basename(filename)            # only splits on "/" on Linux
    stem, dot, ext = name.rpartition(".")
    if not dot:
        raise ValueError("file type not allowed")
    ext = "." + ext.lower()
    if ext not in SIGNATURES:
        raise ValueError("file type not allowed")
    if not data.startswith(SIGNATURES[ext]):
        raise ValueError("content does not match extension")
    stem = re.sub(r"[^A-Za-z0-9._-]", "_", stem).lstrip("._")[:50] or "file"
    return stem + ext

Alternatives and tradeoffs: Many apps ignore the client's name entirely and store files under a generated id (uuid4().hex + ext), keeping the original name only as display metadata in the database; that removes most filename risks. Libraries such as python-magic or filetype detect many more formats from content. In FastAPI, UploadFile gives you filename, content_type (sent by the client, so don't trust it) and a file object to read in chunks.

Follow-ups:

1. "Why not trust the Content-Type the browser sends?" The client sets it, so an attacker can send any value. Use it as a hint at most, and decide from the extension plus the file's own bytes.
2. "The checks pass. Is the file now safe to show to other users?" Not fully: a valid PDF can still contain malicious content, and an image can be huge in pixels. Serve uploads from a separate domain or with Content-Disposition: attachment, never execute or render them as HTML, scan if required, and store them outside the web root (or in object storage).
3. "Why strip leading dots instead of just checking for ..?" Blocklisting .. misses variants (...., encoded forms, a leading dot that creates a hidden file). Taking only the last component and keeping a small allow-list of characters is simpler and safer than listing bad inputs.

Scoring: Strong: Checks in the stated order, splits on both separators, uses the last dot, compares magic bytes, sanitises with an allow-list; explains why the client's name and content type can't be trusted and suggests generated names. Acceptable: Correct type and content checks; uses os.path.basename and fixes the Windows-path case after the test fails. Red flag: Only checks filename.endswith(".pdf"), or saves the file under the client's filename as given.

JR-FS-O01 · Building and parsing URLs for a menu search page

Easy & Tricky · Output · Junior (1–3 years) · urllib.parse, urlencode, quote, parse_qs, query strings, form data · 5 min

Question: A food-ordering site builds search links on the server and parses form posts by hand in one legacy view. What does this print?

from urllib.parse import parse_qs, quote, quote_plus, urlencode

filters = {"q": "paneer tikka", "veg": True, "cuisine": ["north", "south"]}
print(urlencode(filters))
print(urlencode(filters, doseq=True))

dish = "dal makhani/naan"
print(quote(dish), quote(dish, safe=""), quote_plus("dal & naan"))

body = "name=&city=Pune&city=Thane&note=50%25+off"
print(parse_qs(body))
print(parse_qs(body, keep_blank_values=True)["name"])
print(parse_qs("q=a+b%2Bc")["q"])

Expected output:

q=paneer+tikka&veg=True&cuisine=%5B%27north%27%2C+%27south%27%5D
q=paneer+tikka&veg=True&cuisine=north&cuisine=south
dal%20makhani/naan dal%20makhani%2Fnaan dal+%26+naan
{'city': ['Pune', 'Thane'], 'note': ['50% off']}
['']
['a b+c']

The trap:

"urlencode writes cuisine=north&cuisine=south and veg=true, and parse_qs returns name as an empty string." Tempting because that's what a browser form would produce, and urlencode sounds like it knows about forms.

Real-world bug: the "North + South" filter link sends cuisine=['north', 'south'] as one literal string, so the backend finds no matching dishes; and a profile form where the user clears their name is parsed as "name not sent", so the old name is silently kept.

Explanation:

• urlencode converts every value with str(). A list becomes its Python repr, "['north', 'south']", then percent-encoded. True becomes True (capital T), which a JavaScript or Java backend expecting true may reject. Spaces become +, form-encoding style.
• doseq=True expands a sequence into repeated keys, the standard way to send several values.
• quote is for path segments and leaves / unescaped by default (safe="/"), so a dish name containing / would create an extra path segment. safe="" encodes it as %2F. quote_plus is the form/query variant: space → +, & → %26.
• parse_qs returns a list for every key (keys can repeat), decodes %25 to % and + to a space, and drops keys with blank values unless you pass keep_blank_values=True.
• + means space in a query string; a literal plus must be sent as %2B, so a+b%2Bc decodes to a b+c.

Takeaway: in query strings, decide how lists, booleans and blank values are represented, and use doseq=True / keep_blank_values=True when that's what you mean.

Follow-ups:

1. "When would you use parse_qsl instead of parse_qs?" When order or duplicates matter: parse_qsl returns a list of (key, value) pairs in the original order, which a dict of lists can't preserve across keys.
2. "Why does a phone number like +919876543210 arrive as ' 919876543210' on the server?" It was put into a query string without encoding, and + decodes to a space. Build URLs with urlencode / quote_plus (or URLSearchParams in the browser), never by string concatenation.
3. "Do you need these functions in a FastAPI app?" For parsing incoming requests, no: FastAPI and Starlette decode query strings and form bodies for you. You still need them when building outgoing URLs (redirects, links in emails, calls to other APIs); httpx does it for you with params=.

Scoring: Strong: All six lines; knows doseq, str() of booleans, quote's default safe /, list values and dropped blanks in parse_qs, and + vs %2B. Acceptable: Gets the encoding lines roughly right; surprised by the dropped blank name or the repr of the list. Red flag: Builds query strings with f-strings and "&".join(...) without encoding.

JR-FS-O02 · How FastAPI parses query strings from a filter form

Medium · Output · Junior (1–3 years) · FastAPI, query parameters, type coercion, lists, validation errors · 6 min

Question: The product listing page builds its URL from a filter form. What does this print?

from fastapi import FastAPI, Query
from fastapi.testclient import TestClient

app = FastAPI()

@app.get("/products")
def products(page: int = 1, in_stock: bool = False, brand: str | None = None,
             tags: list[str] = Query(default=[])):
    return {"page": page, "in_stock": in_stock, "brand": brand, "tags": tags}

client = TestClient(app)
print(client.get("/products?page=2&in_stock=yes").json())
print(client.get("/products?in_stock=0&brand=Tata&brand=Amul").json())
print(client.get("/products?tags=organic&tags=vegan").json()["tags"])
print(client.get("/products?tags=organic,vegan").json()["tags"])
r = client.get("/products?page=two")
print(r.status_code, r.json()["detail"][0]["msg"])
r = client.get("/products?in_stock=maybe")
print(r.status_code, r.json()["detail"][0]["type"])
print(client.get("/products?page=").status_code)

Expected output:

{'page': 2, 'in_stock': True, 'brand': None, 'tags': []}
{'page': 1, 'in_stock': False, 'brand': 'Amul', 'tags': []}
['organic', 'vegan']
['organic,vegan']
422 Input should be a valid integer, unable to parse string as an integer
422 bool_parsing
422

Explanation:

Everything in a query string is text; FastAPI converts it using the parameter's type hint.

• page=2 becomes the int 2. For bool, Pydantic accepts true/false, 1/0, yes/no, on/off (and a few more), so yes is True and 0 is False; maybe is a validation error of type bool_parsing.
• A parameter typed as a single str takes one value. When the key repeats (brand=Tata&brand=Amul), FastAPI keeps the last one, Amul, and silently ignores the other.
• To accept several values, declare a list with Query(): repeated keys (tags=organic&tags=vegan, which is what an HTML multi-select or a set of same-named checkboxes submits) become a list. A comma-separated value is one string, 'organic,vegan'; splitting it is up to you.
• Values that can't be converted give a 422 with a readable message. page= is present but empty, and an empty string isn't a valid integer, so it's a 422 too, not the default 1.

Takeaway: declare query parameter types precisely (including lists), and make the frontend send exactly what those types expect; for example, drop empty fields from the form before building the URL.

Follow-ups:

1. "How would you validate page >= 1 and cap per_page at 100?" page: int = Query(1, ge=1) and per_page: int = Query(20, ge=1, le=100): invalid values get a 422 with the constraint in the message, before your code runs.
2. "Why might a list filter be better as repeated keys than as a comma-separated string?" It's what HTML forms and URLSearchParams.append produce, it needs no escaping rules for values that contain commas, and FastAPI parses it with no extra code. Comma-separated is shorter in the URL; if you choose it, split and strip on the server and document it.
3. "How should the frontend show a 422 from this endpoint?" Use detail[i]["loc"] (for example ['query', 'page']) to point at the form field and show a friendly message, not the raw Pydantic text. Better still, validate on the client too so most bad values never reach the API.

Scoring: Strong: All seven lines; knows Pydantic's bool strings, that a repeated key keeps the last value for a str, that lists need Query(), and that an empty value is a 422. Acceptable: Gets the int and list behaviour; unsure about yes/0 for bool or the repeated brand. Red flag: Expects "0" to be truthy because it's a non-empty string, or parses request.query_params by hand instead of using typed parameters.

JR-CR-01 · Grouping delivery orders by city

Easy · Code review · Junior (1–3 years) · mutability, aliasing, dict.fromkeys, dicts · 8 min

Context:

PR #412 · dashboard/grouping.py · author: Karthik (8 months in the team)

The ops dashboard for a quick-commerce app shows, for each city the company operates in, the list of order IDs placed today. Cities with no orders must still appear with an empty list so the dashboard renders a "0 orders" tile. City names in the order feed come from a free-text address field, so they arrive in mixed case with stray spaces. Orders from cities outside the operating list (test orders, bad data) should be ignored.

Author's note: "Used dict.fromkeys so every city starts with an empty list in one line. Tested locally with Bengaluru orders and the counts looked right."

Review the function as you would a real pull request.

Code under review:

def group_orders_by_city(orders, cities):
    """Return {city: [order_id, ...]} for every city in `cities`.

    Cities with no orders map to []. Orders from other cities are ignored.
    """
    grouped = dict.fromkeys(cities, [])
    for order in orders:
        city = order["city"].strip().title()
        grouped[city].append(order["order_id"])
    return grouped

What a strong reviewer raises:

1. High: dict.fromkeys(cities, []) evaluates [] once and stores that same list object as the value of every key. Every append goes into the one shared list, so every city shows every order. With the three sample orders the buggy function returns {'Bengaluru': ['BLR-101', 'PUN-201', 'BLR-102'], 'Pune': ['BLR-101', 'PUN-201', 'BLR-102'], 'Chennai': ['BLR-101', 'PUN-201', 'BLR-102']}. The author's local test used only Bengaluru orders and only looked at Bengaluru, which is the one case where the output looks right. Fix: Build a fresh list per key with a dict comprehension, {city: [] for city in cities}. Alternatives: collections.defaultdict(list) (but then empty cities must still be added for the "0 orders" tile). dict.fromkeys is fine only with immutable defaults such as 0, None or "".
2. Medium: An order from a city not in cities raises KeyError (for example KeyError: 'Hyderabad'), so one test order or typo takes down the whole dashboard refresh. The docstring says such orders are ignored, so the code contradicts its own contract. Fix: Check membership before appending (if city in grouped:). In production, also count or log the skipped rows (logger.info("skipped %d orders from unknown cities", n)) so bad data is visible instead of silently vanishing.
3. Low: .title() is a fragile normaliser: "navi mumbai" → "Navi Mumbai" works, but spellings such as "Bangalore" vs "Bengaluru" or "Gurgaon" vs "Gurugram" still miss, and the function has no tests for normalisation at all. Fix: Normalise against a small alias map ({"bangalore": "Bengaluru", ...}) keyed on city.strip().casefold(), and add a parametrised pytest covering spacing, case and aliases.

Tests that expose the bug:

orders = [
    {"order_id": "BLR-101", "city": "Bengaluru"},
    {"order_id": "PUN-201", "city": " pune "},
    {"order_id": "BLR-102", "city": "bengaluru"},
]
result = group_orders_by_city(orders, ["Bengaluru", "Pune", "Chennai"])
assert result == {"Bengaluru": ["BLR-101", "BLR-102"], "Pune": ["PUN-201"], "Chennai": []}, result

# The lists must be independent: touching one city must not change another.
result["Chennai"].append("CHN-301")
assert result["Pune"] == ["PUN-201"]

# Orders from cities outside the operating list are ignored, not a crash.
stray = [{"order_id": "TEST-1", "city": "Hyderabad"}, {"order_id": "PUN-202", "city": "Pune"}]
assert group_orders_by_city(stray, ["Pune"]) == {"Pune": ["PUN-202"]}

assert group_orders_by_city([], ["Pune", "Chennai"]) == {"Pune": [], "Chennai": []}

Fixed version:

def group_orders_by_city(orders, cities):
    """Return {city: [order_id, ...]} for every city in `cities`.

    Cities with no orders map to []. Orders from other cities are ignored.
    """
    grouped = {city: [] for city in cities}      # a new list per city
    for order in orders:
        city = order["city"].strip().title()
        if city in grouped:                       # skip cities we don't operate in
            grouped[city].append(order["order_id"])
    return grouped

Follow-ups:

1. "When is dict.fromkeys(keys, value) perfectly safe?" When the value is immutable (0, None, False, a string, a tuple of immutables). Sharing one immutable object is harmless because nobody can change it in place; counts[k] += 1 rebinds the key to a new int instead of mutating the shared one.
2. "The same bug in another disguise: what does grid = [[0] * 3] * 2; grid[0][0] = 9; print(grid) print?" [[9, 0, 0], [9, 0, 0]]. The outer * 2 copies the reference to one inner list. Fix with [[0] * 3 for _ in range(2)].
3. "What single test would have caught the shared-list bug before review?" Any test with orders from two different cities that asserts the full returned dict, or one that appends to one city's list and checks another is unchanged (result["Pune"] is not result["Chennai"]). Testing only one city can never expose aliasing between keys.
4. "How would you debug this if you saw it in production, with no reviewer around?" Print or log id(grouped["Pune"]) == id(grouped["Chennai"]), or check grouped["Pune"] is grouped["Chennai"]. True means the values are the same object, which points straight at how the dict was built.

Scoring: Strong: Spots the shared list within a couple of minutes, explains that [] is evaluated once and the same object is stored for every key, gives the comprehension fix, and also flags the KeyError on unknown cities against the docstring. Proposes a test with two cities. Acceptable: Finds the shared-list bug after being asked "what would Pune show?", fixes it correctly, but misses the KeyError or needs a hint for it. Red flag: Approves because "it worked for Bengaluru", comments only on naming or style, or "fixes" the aliasing with dict.fromkeys(cities, list()) (still one shared list).

JR-CR-02 · Alert threshold checks built in a loop

Easy & Tricky · Code review · Junior (1–3 years) · closures, late binding, scope, lambda, testing · 10 min

Context:

PR #87 · alerts/checks.py · author: Sneha

The payments on-call team gets paged when a metric crosses its threshold. Thresholds used to be hard-coded if statements; this PR moves them into a config dict and builds one check function per metric, so adding a metric is a one-line config change. The scheduler calls breached() every minute with the latest readings and pages for every metric it returns.

The PR includes this test, which passes:

def test_refund_check():
    checks = build_checks({"refund_count": 50})
    assert checks["refund_count"](51) is True
    assert checks["refund_count"](10) is False

Author's note: "Pure refactor, behaviour unchanged. CI is green."

Code under review:

THRESHOLDS = {
    "upi_failure_rate": 0.05,   # fraction of UPI payments failing
    "p95_latency_ms": 800,
    "refund_count": 50,         # refunds in the last minute
}


def build_checks(thresholds):
    """Return {metric: check} where check(value) is True if value is above the limit."""
    checks = {}
    for metric, limit in thresholds.items():
        checks[metric] = lambda value: value > limit
    return checks


def breached(checks, readings):
    """Names of metrics whose reading is above the threshold, sorted."""
    return sorted(metric for metric, value in readings.items() if checks[metric](value))

What a strong reviewer raises:

1. High: Late binding. Each lambda refers to the variable limit in build_checks's scope, not to the value limit had when the lambda was created. The lookup happens when the check is called, after the loop has finished, so every check compares against the last value, 50. Consequences with the real config: upi_failure_rate 0.09 > 50 is False, so a 9% UPI failure rate never pages; and p95_latency_ms 120 > 50 is True, so a healthy service pages all night. The PR's own test passes because it builds a single check, and with one item the "last value" is the right value. Fix: Bind the value at creation time. Cleanest: a small factory (_above(limit)), because each call to the factory gets its own limit. Also acceptable: lambda value, limit=limit: value > limit (default values are evaluated at definition time) or functools.partial(operator.lt, limit).
2. Medium: The test only covers one metric, so it cannot catch any bug that involves more than one closure. A "pure refactor" claim needs a test that runs the old and new behaviour over the whole config. Fix: Add a parametrised test over every (metric, limit) pair checking a value just above and just below the limit, plus one breached() test with mixed readings.
3. Medium: breached() raises KeyError for any reading that has no configured threshold. When the metrics team adds a new metric to the readings feed before anyone adds a threshold, the whole alert loop crashes and no alerts fire, including real ones. Fix: Skip metrics without a check (if metric in checks) and log a warning once, so one unknown metric can't disable alerting for everything else.
4. Low: Lambdas all have __name__ == "<lambda>", so tracebacks and log lines don't say which metric's check ran. Fix: Log the metric name with each result (the scheduler already has it as the dict key). A named inner function such as _above.<locals>.check at least gives tracebacks a name you can search for.

Tests that expose the bug:

checks = build_checks(THRESHOLDS)

# 9% of UPI payments failing is an incident and must page.
assert checks["upi_failure_rate"](0.09) is True
assert checks["upi_failure_rate"](0.01) is False
# 120 ms latency is healthy and must not page.
assert checks["p95_latency_ms"](120) is False
assert checks["p95_latency_ms"](900) is True

readings = {"upi_failure_rate": 0.09, "p95_latency_ms": 900, "refund_count": 12}
assert breached(checks, readings) == ["p95_latency_ms", "upi_failure_rate"]

# A metric that has no configured threshold is skipped, not a crash.
assert breached(checks, {"new_metric": 5, "refund_count": 60}) == ["refund_count"]

Fixed version:

THRESHOLDS = {
    "upi_failure_rate": 0.05,   # fraction of UPI payments failing
    "p95_latency_ms": 800,
    "refund_count": 50,         # refunds in the last minute
}


def _above(limit):
    """Return a check bound to this call's `limit`."""
    def check(value):
        return value > limit
    return check


def build_checks(thresholds):
    """Return {metric: check} where check(value) is True if value is above the limit."""
    return {metric: _above(limit) for metric, limit in thresholds.items()}


def breached(checks, readings):
    """Names of metrics whose reading is above the threshold, sorted."""
    return sorted(
        metric
        for metric, value in readings.items()
        if metric in checks and checks[metric](value)
    )

Follow-ups:

1. "Why did p95_latency_ms with 900 still give the right answer in the buggy version?" Because 900 > 50 is also True: the wrong limit happens to agree with the right one for that reading. That's why spot checks on large values miss this bug. You need a value between the real limit and the leaked one (120 for latency, 0.09 for the UPI rate).
2. "Someone suggests functools.partial(operator.gt, limit). Is that correct?" No. partial(operator.gt, limit)(value) computes operator.gt(limit, value), which is limit > value, the opposite check. The correct one is partial(operator.lt, limit), meaning limit < value. Readability matters: the factory is harder to get backwards.
3. "What is the downside of the limit=limit default-argument fix?" limit becomes part of the function's public signature: a caller can accidentally pass a second argument and override it (check(0.09, 1)), and type checkers and help() show a parameter that callers should never use. The factory keeps it private.
4. "Would a list comprehension [lambda v: v > limit for limit in limits] have the same problem?" Yes. The comprehension has its own scope, but all the lambdas still close over the one limit variable in that scope, which ends at the last value.

Scoring: Strong: Spots that every lambda closes over the same limit and explains it as lookup at call time, not definition time. Names the concrete impact (missed UPI page, false latency pages) and explains why the single-metric test was green. Fixes with a factory or default argument and asks for a multi-metric test. Acceptable: Recognises the late-binding pattern and fixes it, but needs a prompt to explain why CI passed or to see the KeyError in breached(). Red flag: Approves because CI is green and it is "a pure refactor", or believes each lambda "remembers" its own limit, and can't explain why after running [c(0.09) for c in checks.values()].

JR-CR-03 · A retry decorator for the SMS gateway

Medium · Code review · Junior (1–3 years) · decorators, functools.wraps, exceptions, logging, retries · 12 min

Context:

PR #233 · notify/retry.py · author: Arjun

The OTP service calls a third-party SMS gateway that sometimes returns 502s or times out for a few seconds. The client already raises TransientError for 5xx responses and timeouts, and lets other errors (ValueError for a malformed phone number, PermissionError for a revoked API key) propagate. This PR adds a reusable @retry decorator so callers can write:

@retry(times=3, delay=0.5)
def send_otp(phone: str, code: str) -> str:
    ...  # returns the gateway's message ID

The spec agreed in standup: try up to times times in total; wait a little longer after each failure; if every attempt fails, the caller must see the error (the login screen shows "Couldn't send OTP, try again"). Callers store the returned message ID for delivery tracking.

Code under review:

import logging
import time

logger = logging.getLogger("notify")


class TransientError(Exception):
    """5xx response or timeout from the SMS gateway."""


def retry(times=3, delay=0.5):
    def decorator(func):
        def wrapper(*args, **kwargs):
            for attempt in range(1, times):
                try:
                    return func(*args, **kwargs)
                except Exception as exc:
                    logger.warning("attempt %d failed: %s", attempt, exc)
                    time.sleep(delay * attempt)
        return wrapper
    return decorator

What a strong reviewer raises:

1. High: Swallowed failure. When the last attempt fails, the except block logs, sleeps, and the loop ends. wrapper then falls off the end and returns None. The caller gets None instead of an exception, so the login flow says "OTP sent", stores None as the message ID, and the user waits for an SMS that never comes. Nothing reaches error monitoring because no exception escaped. Fix: Re-raise on the final attempt (if attempt == times: raise). A bare raise inside except re-raises the original exception with its traceback intact.
2. High: Off by one. range(1, times) yields 1 .. times-1, so times=3 makes only 2 attempts (and times=1 makes zero attempts and returns None without calling the function at all). A call that would have succeeded on the third try is reported as a failure. In the tests, flaky_send returns None after two calls. Fix: range(1, times + 1), and reject times < 1 up front so a config typo can't turn the decorator into a silent no-op.
3. Medium: except Exception retries everything. A ValueError for a malformed number or a revoked API key will fail identically every time, so retrying just multiplies load on the gateway and delays the error. It also hides real bugs: a TypeError in our own code is retried three times and logged as "attempt failed". Fix: Retry only what is known to be transient: a retry_on=(TransientError,) parameter, defaulting to the gateway's transient error type. Everything else propagates on the first attempt.
4. Medium: No functools.wraps: every decorated function now reports __name__ == "wrapper" and loses its docstring. Log lines, metrics keyed by function name, and pytest/Sentry output all show wrapper. Fix: Decorate the inner function with @functools.wraps(func), and include func.__name__ and attempt/times in the warning so on-call can tell which call is failing.
5. Low: It sleeps even after the final attempt, adding delay * times seconds of pointless waiting before returning, on a user-facing login path. Fix: Only sleep when another attempt will follow (the fixed version re-raises before sleeping).

Tests that expose the bug:

logging.disable(logging.CRITICAL)   # keep test output quiet

calls = []

@retry(times=3, delay=0)
def flaky_send(phone):
    calls.append(phone)
    if len(calls) < 3:
        raise TransientError("502 Bad Gateway")
    return "msg-7f3a"

# Succeeds on the third (last allowed) attempt.
assert flaky_send("+919800000001") == "msg-7f3a"
assert len(calls) == 3

# When every attempt fails, the caller must see the error, after exactly `times` attempts.
attempts = []

@retry(times=3, delay=0)
def gateway_down(phone):
    attempts.append(phone)
    raise TransientError("timeout")

try:
    result = gateway_down("+919800000002")
except TransientError:
    pass
else:
    raise AssertionError(f"expected TransientError, got return value {result!r}")
assert len(attempts) == 3

# A bad phone number will never succeed: no retries.
bad = []

@retry(times=3, delay=0)
def invalid_number(phone):
    bad.append(phone)
    raise ValueError("phone must be +91 followed by 10 digits")

try:
    invalid_number("98400")
except ValueError:
    pass
assert len(bad) == 1

# Logs, metrics and pytest reports use the real function name.
assert flaky_send.__name__ == "flaky_send"

Fixed version:

import functools
import logging
import time

logger = logging.getLogger("notify")


class TransientError(Exception):
    """5xx response or timeout from the SMS gateway."""


def retry(times=3, delay=0.5, retry_on=(TransientError,)):
    if times < 1:
        raise ValueError("times must be at least 1")

    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            for attempt in range(1, times + 1):
                try:
                    return func(*args, **kwargs)
                except retry_on as exc:
                    if attempt == times:
                        raise                     # out of attempts: let the caller see it
                    logger.warning("%s attempt %d/%d failed: %s",
                                   func.__name__, attempt, times, exc)
                    time.sleep(delay * attempt)
        return wrapper
    return decorator

Follow-ups:

1. "The gateway call timed out, but the gateway actually sent the SMS. What happens when we retry, and how do you prevent it?" The user gets two OTPs, and with some providers the first one becomes invalid, which confuses them. A timeout means "unknown outcome", not "failed". Prevent it with an idempotency key (the same request ID on every retry, so the gateway dedups), or by retrying only errors that guarantee nothing happened (connection refused, 503 before processing).
2. "Why does logging.disable appear in the tests, and what would print without it?" The notify logger has no handler configured, so Python's last-resort handler prints WARNING and above to stderr: each failed attempt would print a line such as attempt 1 failed: 502 Bad Gateway. Tests should either silence logging or assert on it with pytest's caplog fixture.
3. "How would you test this without real time.sleep calls slowing the suite?" Pass delay=0 as here, or patch the sleep: monkeypatch.setattr(time, "sleep", fake_sleep) and assert on the delays it recorded ([0.5, 1.0] for three attempts). Making sleep an injectable parameter of retry is another clean option.
4. "Why delay * attempt rather than a fixed delay? What would you add for a gateway used by many servers?" Increasing waits give the gateway time to recover. With many clients, add jitter (a random part of the delay) so all servers don't retry in lockstep and hammer the gateway at the same instant. Exponential backoff (delay * 2 ** (attempt - 1)) with a cap is the usual pattern; libraries such as tenacity implement it.

Scoring: Strong: Finds both high-severity bugs (the silent None and the off-by-one) by reading the loop carefully, and explains the user-visible effect of each. Raises the except Exception scope and the missing functools.wraps. Fixes with a bare raise on the last attempt, and mentions idempotency or tests without real sleeps. Acceptable: Finds the swallowed exception and the missing wraps, and finds the off-by-one when asked to trace times=3. Fix is correct but retries all exceptions until prompted. Red flag: Comments only on naming or log format. Thinks returning None after failures is "graceful". Fixes by raise exc after the loop (in Python 3 that raises UnboundLocalError, because the as exc name is deleted when the except block ends). Or can't explain why a decorator with arguments needs three nested functions.

JR-CR-04 · Hourly incremental load of an orders table

Medium & Tricky · Code review · Junior (1–3 years) · pandas, incremental loads, drop_duplicates, NaT, watermarks, data engineering · 15 min

Context:

PR #58 · etl/orders_incremental.py · author: Meera (data engineering)

The analytics copy of the orders table used to be rebuilt from scratch every night. This PR switches to an hourly incremental load. Every hour the upstream team drops a change file with orders whose updated_at changed recently. To be safe they re-send the previous hour's rows too, so files overlap. Files for quiet hours (roughly 02:00–05:00 IST) are often empty. The job keeps a watermark, the latest updated_at it has loaded, and stores it between runs.

incremental_load should upsert: new orders are inserted, and changed orders replace their old row (an order moves PLACED → DELIVERED or CANCELLED). The target must stay one row per order_id.

Author's note: "Tested with yesterday's 11:00 file: the new orders show up and the row count matches. The > watermark filter skips the overlapping rows."

Code under review:

import pandas as pd


def incremental_load(target, batch, watermark):
    """Upsert rows from an hourly change file into the target table.

    target:    current copy of the orders table (one row per order_id)
    batch:     the latest change file; may repeat rows already loaded
    watermark: latest updated_at already loaded
    Returns (new_target, new_watermark).
    """
    changed = batch[batch["updated_at"] > watermark]
    merged = pd.concat([target, changed]).drop_duplicates(subset="order_id")
    merged = merged.sort_values("order_id").reset_index(drop=True)
    return merged, changed["updated_at"].max()

What a strong reviewer raises:

1. High: Updates are thrown away. drop_duplicates keeps the first occurrence by default. Because the old target rows come first in pd.concat([target, changed]), the stale row wins and the new version is dropped. New orders are inserted (they have no duplicate), so the author's check, "new orders show up and the row count matches", passes. But order 2 stays PLACED after the 11:00 file says DELIVERED. Every status change after the first load is lost, and nothing errors. Fix: drop_duplicates(subset="order_id", keep="last"), so the batch row wins. Sort changed by updated_at first (with a stable sort) so that if one order appears twice in a file, its latest version is the one kept.
2. High: An empty file poisons the watermark. For a quiet hour changed is empty, and changed["updated_at"].max() returns NaT. Every comparison with NaT is False, so from the next run on batch["updated_at"] > NaT selects nothing, forever. The job keeps "succeeding" with zero rows loaded. In the tests the watermark after the 03:00 file is NaT, and the later cancellation of order 1 and the new order 4 never arrive. Fix: If changed is empty, return the target and the old watermark unchanged. Also never let the watermark move backwards: max(watermark, changed["updated_at"].max()). A sanity check (assert pd.notna(new_watermark)) before saving the watermark would have turned this into a loud failure.
3. Medium: Late rows at the watermark are skipped. Many rows share a timestamp (two orders updated at 10:40). If one of them was committed after the extract ran, it arrives in a later file with updated_at equal to the watermark, and > watermark filters it out. Order 4 in the tests is lost even with a valid watermark. Fix: Use >= watermark. That re-reads the rows at the boundary every run, which is harmless because the load is an idempotent upsert (keep="last"). The general rule: make the write idempotent, then overlap the read window rather than trying to make it exact.
4. Low: Concatenating an empty change file changes column types. An empty CSV is read with object columns, and after pd.concat the target's order_id silently becomes object instead of int64. Later joins against an int64 key then match nothing or raise. Fix: The early return for empty batches avoids it here. More generally, read files with explicit dtype={"order_id": "int64"} and parse_dates=["updated_at"], and assert the schema before loading.

Tests that expose the bug:

ts = pd.Timestamp
COLS = ["order_id", "status", "updated_at"]


def frame(rows):
    df = pd.DataFrame(rows, columns=COLS)
    df["updated_at"] = pd.to_datetime(df["updated_at"])
    return df


target = frame([(1, "PLACED", "2026-10-01 09:00"), (2, "PLACED", "2026-10-01 09:30")])
wm = ts("2026-10-01 09:30")

# 11:00 file: order 2 delivered, order 3 placed; the upstream also re-sends order 1 unchanged.
batch_11 = frame([(1, "PLACED", "2026-10-01 09:00"),
                  (2, "DELIVERED", "2026-10-01 10:40"),
                  (3, "PLACED", "2026-10-01 10:40")])
target, wm = incremental_load(target, batch_11, wm)
assert target["status"].tolist() == ["PLACED", "DELIVERED", "PLACED"], target
assert wm == ts("2026-10-01 10:40")

# 03:00 file is empty (quiet hour). Nothing changes, the watermark must survive.
target, wm = incremental_load(target, frame([]), wm)
assert wm == ts("2026-10-01 10:40"), wm
assert target["order_id"].dtype == "int64", target.dtypes

# Next file: order 4 was committed late with the same timestamp as the watermark,
# and order 1 was cancelled.
batch_04 = frame([(4, "PLACED", "2026-10-01 10:40"),
                  (1, "CANCELLED", "2026-10-02 04:10")])
target, wm = incremental_load(target, batch_04, wm)
assert target["order_id"].tolist() == [1, 2, 3, 4], target
assert target["status"].tolist() == ["CANCELLED", "DELIVERED", "PLACED", "PLACED"], target
assert wm == ts("2026-10-02 04:10")

Fixed version:

import pandas as pd


def incremental_load(target, batch, watermark):
    """Upsert rows from an hourly change file into the target table.

    target:    current copy of the orders table (one row per order_id)
    batch:     the latest change file; may repeat rows already loaded
    watermark: latest updated_at already loaded
    Returns (new_target, new_watermark).
    """
    # >= : re-read rows at the watermark; the upsert below makes that harmless.
    changed = batch[batch["updated_at"] >= watermark]
    if changed.empty:
        return target, watermark              # quiet hour: keep the old watermark
    changed = changed.sort_values("updated_at", kind="stable")
    merged = pd.concat([target, changed]).drop_duplicates(subset="order_id", keep="last")
    merged = merged.sort_values("order_id").reset_index(drop=True)
    return merged, max(watermark, changed["updated_at"].max())

Follow-ups:

1. "Why does batch['updated_at'] > NaT select nothing, and how would you detect a NaT watermark in a pipeline?" NaT behaves like NaN: every comparison with it is False (pd.NaT == pd.NaT is False too; only != is True). Detect it with pd.isna(watermark) before saving state, and alert when a run loads zero rows several hours in a row during business hours.
2. "The upstream starts sending updated_at as timezone-aware IST while the stored watermark is naive. What happens?" The comparison raises TypeError: Invalid comparison between dtype=datetime64[ns, Asia/Kolkata] and Timestamp. At least it's loud. Pick one convention (usually UTC, timezone-aware) at the boundary: convert with tz_localize/tz_convert when reading, and store the watermark the same way.
3. "The job crashes after writing the new target but before saving the watermark. Is the next run safe?" Yes, because the upsert is idempotent: the next run re-reads from the old watermark and rewrites the same rows with the same values. That's why "save the watermark last" plus idempotent writes is the standard ordering. If the write were an append, the rerun would create duplicates.
4. "In production target is a database table, not a DataFrame. What replaces concat + drop_duplicates?" An upsert in the database: INSERT ... ON CONFLICT (order_id) DO UPDATE in PostgreSQL, or MERGE in warehouses, ideally with a guard such as WHERE excluded.updated_at >= orders.updated_at so an older replay can't overwrite a newer row. Load the batch into a staging table first.
5. "How would you test this function properly with pytest?" Small hand-built DataFrames for each scenario: an update to an existing order, an empty file, an overlapping replay, a late row at the watermark, and the same order twice in one file. Assert on the full table and the watermark after a sequence of runs, because most of these bugs only appear on the second or third run.

Scoring: Strong: Finds the keep="first" bug by asking "what happens to an order that changes?", and the NaT watermark by asking "what if the file is empty?". Explains why the author's row-count check passed. Proposes keep="last", an early return, and >= with an idempotent upsert, and thinks in sequences of runs, not a single call. Acceptable: Finds the drop_duplicates bug and the empty-file case with one hint ("think about a quiet hour"), but treats the > vs >= boundary as a nitpick or misses it. Red flag: Reviews only one run on the happy path. Accepts "row count matches" as proof of correctness, or proposes rebuilding the full table every hour without being asked about scale or cost.

JR-CR-05 · Customer profile API with partial updates

Hard · Code review · Junior (1–3 years) · fastapi, pydantic, CRUD, validation, authorization, PATCH semantics, PII · 20 min

Context:

PR #301 · profiles/ (schemas.py, db.py, auth.py, routes.py) · author: Vikram

A lending app is adding a "My profile" screen. Customers log in on the app and get an API key, sent as the X-API-Key header. This PR adds two endpoints:

• GET /customers/{customer_id}: view your own profile.
• PATCH /customers/{customer_id}: update some of name, city, phone. The app sends only the fields the customer edited, for example {"city": "Bengaluru"}.

The customer table also stores the PAN (Permanent Account Number), collected for KYC. The product spec says the PAN is never shown or returned by the profile screen. Customers may only see or change their own profile.

The four modules are shown in one block, separated by comments. The dict CUSTOMERS stands in for the database table. Author's note: "Validation is all in Pydantic: phone must be +91 and 10 digits, name can't be empty. Manually tested both endpoints in Swagger with my own test account."

Code under review:

from fastapi import Depends, FastAPI, Header, HTTPException
from pydantic import BaseModel, Field

# ---------------- schemas.py ----------------
class CustomerOut(BaseModel):
    id: int
    name: str
    city: str
    phone: str


class CustomerUpdate(BaseModel):
    """PATCH body: every field optional, send only what changes."""
    name: str | None = Field(default=None, min_length=1)
    city: str | None = Field(default=None, min_length=1)
    phone: str | None = Field(default=None, pattern=r"^\+91\d{10}$")


# ---------------- db.py (in-memory stand-in for the real table) ----------------
CUSTOMERS = {
    1: {"id": 1, "name": "Ananya Iyer", "city": "Chennai", "phone": "+919840012345", "pan": "ABCPI1234K"},
    2: {"id": 2, "name": "Rohit Verma", "city": "Indore", "phone": "+919826054321", "pan": "BXZPV5678L"},
}
API_KEYS = {"key-ananya": 1, "key-rohit": 2}   # issued at login; maps key -> customer id


# ---------------- auth.py ----------------
def current_customer_id(x_api_key: str = Header()) -> int:
    customer_id = API_KEYS.get(x_api_key)
    if customer_id is None:
        raise HTTPException(status_code=401, detail="invalid API key")
    return customer_id


# ---------------- routes.py ----------------
app = FastAPI()


@app.get("/customers/{customer_id}")
def get_customer(customer_id: int, caller: int = Depends(current_customer_id)):
    if customer_id != caller:
        raise HTTPException(status_code=403, detail="not your profile")
    return CUSTOMERS[customer_id]


@app.patch("/customers/{customer_id}")
def update_customer(customer_id: int, body: CustomerUpdate,
                    caller: int = Depends(current_customer_id)):
    customer = CUSTOMERS.get(customer_id)
    if customer is None:
        raise HTTPException(status_code=404, detail="customer not found")
    customer.update(body.model_dump())
    return customer

What a strong reviewer raises:

1. High: Anyone can edit anyone's profile (IDOR, insecure direct object reference). GET checks customer_id != caller, but PATCH resolves caller and then never uses it. With her own key, Ananya can PATCH /customers/2 and change Rohit's phone number. On a lending app, changing someone else's phone redirects their OTPs, which is the first step of an account takeover. Testing "with my own test account" can't find this, because you only ever request your own ID. Fix: Move the ownership check into a shared dependency (require_owner) used by every /customers/{customer_id} route, so a new route can't forget it. Add a test that uses one customer's key on another customer's ID for each route.
2. High: PATCH wipes fields the client didn't send. body.model_dump() includes every field, with None for the ones that weren't sent. {"city": "Bengaluru"} therefore writes name=None, phone=None. The response in the tests is {'id': 1, 'name': None, 'city': 'Bengaluru', 'phone': None, 'pan': 'ABCPI1234K'}. The customer loses their phone number, so they can't receive OTPs at all. Fix: body.model_dump(exclude_unset=True) returns only the fields present in the request JSON. That is exactly PATCH semantics.
3. High: The PAN leaks. Both routes return the raw stored dict, so the JSON response includes pan. That breaks the product spec and exposes regulated personal data to logs, browser caches and anyone holding the key. CustomerOut exists but isn't used anywhere. Fix: Declare response_model=CustomerOut on both routes. FastAPI then validates the return value and sends only the declared fields. Treat "return the DB row" as a review smell in general.
4. Medium: Explicit null passes validation. The fields are typed str | None so they can be omitted, but that also accepts {"name": null}, and min_length doesn't apply to None. Even with exclude_unset=True, an explicit null would write name=None. The author's claim that "name can't be empty" is only half true. Fix: A field_validator that rejects None. Validators don't run for omitted fields that fall back to their default, so "omitted" is still allowed while "sent as null" returns 422. Test both.
5. Low: Wrong status codes. A missing X-API-Key header returns 422 (FastAPI treats the required header as a validation error), not 401, so the mobile app's "session expired, log in again" handler never fires. Also, PATCH on an unknown ID returns 404 while an existing ID that belongs to someone else returns 200. That difference lets an attacker list which customer IDs exist. Fix: Declare the header as optional (Header(default=None)) and raise 401 yourself when it's missing or unknown. Do the ownership check before the lookup, so any ID that isn't yours gets the same 403.

Tests that expose the bug:

from fastapi.testclient import TestClient

client = TestClient(app)
ANANYA = {"X-API-Key": "key-ananya"}

# Partial update: only the city changes, everything else is kept.
r = client.patch("/customers/1", json={"city": "Bengaluru"}, headers=ANANYA)
assert r.status_code == 200, r.text
assert r.json() == {"id": 1, "name": "Ananya Iyer", "city": "Bengaluru", "phone": "+919840012345"}, r.json()

# Responses never include the PAN.
r = client.get("/customers/1", headers=ANANYA)
assert r.status_code == 200 and "pan" not in r.json(), r.json()

# A customer can't edit someone else's profile.
r = client.patch("/customers/2", json={"city": "Goa"}, headers=ANANYA)
assert r.status_code == 403, r.status_code
assert CUSTOMERS[2]["city"] == "Indore"

# Explicit null for a required field is rejected, and nothing is written.
r = client.patch("/customers/1", json={"name": None}, headers=ANANYA)
assert r.status_code == 422, r.status_code
assert CUSTOMERS[1]["name"] == "Ananya Iyer"

# Validation still works.
assert client.patch("/customers/1", json={"phone": "98400"}, headers=ANANYA).status_code == 422

# No key at all is an authentication failure (401), not a validation error.
assert client.get("/customers/1").status_code == 401
assert client.get("/customers/1", headers={"X-API-Key": "stolen"}).status_code == 401

Fixed version:

from fastapi import Depends, FastAPI, Header, HTTPException
from pydantic import BaseModel, Field, field_validator

# ---------------- schemas.py ----------------
class CustomerOut(BaseModel):
    id: int
    name: str
    city: str
    phone: str


class CustomerUpdate(BaseModel):
    """PATCH body: every field optional, send only what changes."""
    name: str | None = Field(default=None, min_length=1)
    city: str | None = Field(default=None, min_length=1)
    phone: str | None = Field(default=None, pattern=r"^\+91\d{10}$")

    @field_validator("name", "city", "phone")
    @classmethod
    def not_null(cls, value):
        # Runs only for fields the client actually sent: omitted is fine, explicit null is not.
        if value is None:
            raise ValueError("may be omitted, but not set to null")
        return value


# ---------------- db.py (in-memory stand-in for the real table) ----------------
CUSTOMERS = {
    1: {"id": 1, "name": "Ananya Iyer", "city": "Chennai", "phone": "+919840012345", "pan": "ABCPI1234K"},
    2: {"id": 2, "name": "Rohit Verma", "city": "Indore", "phone": "+919826054321", "pan": "BXZPV5678L"},
}
API_KEYS = {"key-ananya": 1, "key-rohit": 2}   # issued at login; maps key -> customer id


# ---------------- auth.py ----------------
def current_customer_id(x_api_key: str | None = Header(default=None)) -> int:
    customer_id = API_KEYS.get(x_api_key) if x_api_key else None
    if customer_id is None:
        raise HTTPException(status_code=401, detail="missing or invalid API key")
    return customer_id


def require_owner(customer_id: int, caller: int = Depends(current_customer_id)) -> int:
    """Shared by every /customers/{customer_id} route, so no route can forget the check."""
    if customer_id != caller:
        raise HTTPException(status_code=403, detail="not your profile")
    return customer_id


# ---------------- routes.py ----------------
app = FastAPI()


@app.get("/customers/{customer_id}", response_model=CustomerOut)
def get_customer(customer_id: int = Depends(require_owner)):
    return CUSTOMERS[customer_id]


@app.patch("/customers/{customer_id}", response_model=CustomerOut)
def update_customer(body: CustomerUpdate, customer_id: int = Depends(require_owner)):
    customer = CUSTOMERS[customer_id]
    customer.update(body.model_dump(exclude_unset=True))
    return customer

Follow-ups:

1. "The client sends {"city": "Pune", "pan": "XXXXX0000X"}. Can they overwrite their PAN through this endpoint after the fix?" No. Pydantic's default extra="ignore" drops unknown keys, so pan never reaches model_dump() and the stored PAN is unchanged. Many teams prefer model_config = ConfigDict(extra="forbid") on input models, so the client gets a 422 instead of a silent ignore. Writing the request dict straight into the row without a model ("mass assignment") is how this goes wrong.
2. "What's the difference between exclude_unset=True and exclude_none=True here?" exclude_unset drops fields not present in the request. exclude_none drops fields whose value is None, whether sent or not. For PATCH you want exclude_unset, and you decide separately what an explicit null means: reject it (as here), or treat it as "clear this field" for a genuinely nullable column such as alternate_phone.
3. "Why is the ownership check better as a dependency than as an if in each route?" It can't be forgotten: routes declare Depends(require_owner) and get back an ID that is already authorised. The rule lives in one place, so when admins or support staff need access, you change one function. It is also easy to test on its own.
4. "Is an API key that maps to a customer ID enough for production?" It's a reasonable stand-in. In production you'd usually issue short-lived signed tokens (for example JWTs or opaque session tokens) with expiry and revocation, send them only over HTTPS, store only a hash of long-lived keys, and rate-limit the login and OTP endpoints. A junior isn't expected to design that, but should know the key must expire and must never be logged.
5. "Which tests would you ask the author to add before approving?" One per issue, using FastAPI's TestClient: a partial PATCH asserting untouched fields are kept; "pan" not in response.json() for both routes; another customer's key gets 403 on every route; an explicit null gets 422 and nothing changes; no header gets 401.

Scoring: Strong: Finds the missing ownership check on PATCH, the model_dump() wiping fields, and the PAN leak. Explains the real-world impact of each (account takeover through a changed phone number, data loss, regulated data exposure). Fixes with a shared dependency, exclude_unset=True and response_model, raises the explicit-null case, and proposes cross-customer tests. Acceptable: Finds two of the three high-severity issues on their own (usually the PATCH wipe and the PAN leak) and the authorisation gap after a prompt such as "what stops Ananya from calling /customers/2?". Fixes are correct but stay route by route. Red flag: Trusts "tested in Swagger" as evidence. Focuses on code style or the in-memory dict. Doesn't see why returning the stored row is a problem. Treats authentication (who you are) as if it were authorisation (what you may access).

JR-TH-ASY-01 · A minimal asyncio program

Easy · Theory · Junior (1–3 years) · asyncio, async def, await, gather, asyncio.run · 4 min

Question: Walk me through a minimal asyncio program that fetches two things concurrently. What do async def, await, asyncio.gather and asyncio.run each do?

Answer:

• async def defines a coroutine function. Calling it returns a coroutine object; nothing in the body runs until it's awaited or scheduled as a task.
• await x runs the awaitable and pauses the current coroutine until it's done. While paused, the event loop runs other tasks.
• asyncio.gather(c1, c2) schedules the coroutines as tasks, runs them concurrently, and returns their results in argument order, not completion order. "users" finished first but is second in the list.
• asyncio.run(main()) creates an event loop, runs main() to completion and closes the loop. Call it once, at the program's entry point.

Everything runs on one thread. Concurrency comes from switching tasks at await points while they wait on I/O, so the total time is roughly the longest wait (0.05 s here), not the sum.

Good fit: many network or database calls with async libraries. Not a fit: CPU-heavy work, which blocks the single thread.

import asyncio

async def fetch(name, delay):
    print(f"start {name}")
    await asyncio.sleep(delay)          # stands in for a network call
    print(f"end {name}")
    return f"{name} ok"

async def main():
    results = await asyncio.gather(fetch("orders", 0.05), fetch("users", 0.01))
    print(results)

asyncio.run(main())

Output:

start orders
start users
end users
end orders
['orders ok', 'users ok']

Follow-ups:

1. "Can you use await inside a normal def function?" No, it's a SyntaxError. Only inside async def (Jupyter and the asyncio REPL also allow top-level await).
2. "What if fetch used time.sleep instead of asyncio.sleep?" time.sleep blocks the whole thread, so the event loop can't switch tasks: the fetches run one after another and the total becomes the sum.

Scoring: Strong: Explains each piece accurately, notes gather's result order and that it's single-threaded concurrency at await points. Acceptable: Writes a working example but is fuzzy on what await does to the event loop. Red flag: Thinks async def runs the function in a background thread, or that gather returns results in completion order.

JR-TH-ASY-02 · Two awaits in a row are not concurrent

Easy & Tricky · Theory · Junior (1–3 years) · asyncio, await, gather, concurrency · 4 min

Question: An async endpoint does a = await fetch(1) and then b = await fetch(2). Do the two calls overlap? Compare with asyncio.gather.

Answer:

Trap: "Each await starts the call in the background, so they overlap." await waits for that coroutine to finish before the next line runs. Two awaits in a row are sequential: the output shows start 1, end 1, start 2, end 2, and the total time is the sum.

Being inside async def isn't enough. You have to schedule both before waiting on either:

• await asyncio.gather(fetch(1), fetch(2)),
• t1 = asyncio.create_task(...) and t2 = asyncio.create_task(...), then await them,
• or an asyncio.TaskGroup (3.11+).

Then both start before either ends (start 1, start 2, end 2, end 1), and the total is about the longest call.

The real-world version: a FastAPI endpoint that awaits five independent service calls one after another and is no faster than the sync version. Only independent calls should run concurrently; if you need the user before you can fetch their orders, those stay sequential.

import asyncio

async def fetch(n, delay):
    print(f"start {n}")
    await asyncio.sleep(delay)
    print(f"end {n}")
    return n

async def sequential():
    a = await fetch(1, 0.02)
    b = await fetch(2, 0.01)
    return [a, b]

async def concurrent():
    return await asyncio.gather(fetch(1, 0.02), fetch(2, 0.01))

print(asyncio.run(sequential()))
print(asyncio.run(concurrent()))

Output:

start 1
end 1
start 2
end 2
[1, 2]
start 1
start 2
end 2
end 1
[1, 2]

Follow-ups:

1. "Rewrite concurrent() with create_task." t1 = asyncio.create_task(fetch(1, 0.02)), t2 = asyncio.create_task(fetch(2, 0.01)), then return [await t1, await t2]. Both are already running before the first await.
2. "And with a TaskGroup?" async with asyncio.TaskGroup() as tg: create both tasks with tg.create_task(...); after the block, read t1.result() and t2.result(). If one fails, the other is cancelled.

Scoring: Strong: Says the awaits run sequentially, reads the trace correctly, and gives gather / create_task / TaskGroup with the 'only independent calls' caveat. Acceptable: Unsure at first but gets it from the printed start/end order. Red flag: Insists sequential awaits run in parallel because the function is async.

JR-TH-ASY-03 · Limiting concurrency with a Semaphore

Medium · Theory · Junior (1–3 years) · asyncio, Semaphore, rate limits, gather · 5 min

Question: You need to call an API for 10,000 SKUs with asyncio, but the provider allows at most 10 requests in flight. asyncio.gather on 10,000 coroutines would start them all at once. How do you limit it?

Answer:

Use an asyncio.Semaphore(n). At most n coroutines can be inside async with sem: at any moment; the rest wait at that line. In the snippet the peak number of in-flight calls is exactly 3, and gather still returns the results in input order.

Create the semaphore inside the running program (e.g. in main), share it with all the tasks, and hold it only around the actual request, not around the processing of the response.

Alternatives:

• A fixed pool of worker tasks pulling from an asyncio.Queue. That's better for very large inputs, because you don't create 10,000 coroutine objects up front.
• httpx.AsyncClient(limits=httpx.Limits(max_connections=10)) caps connections at the client level.

A semaphore limits concurrency, not rate. If the limit is "100 requests per minute", you also need a time-based limiter.

Why is the global in_flight counter safe without a lock? Everything runs on one thread, and there's no await between reading and writing it, so no other task can run in between.

import asyncio

in_flight = 0
peak = 0

async def call_api(sem, i):
    global in_flight, peak
    async with sem:
        in_flight += 1
        peak = max(peak, in_flight)
        await asyncio.sleep(0.01)
        in_flight -= 1
        return i * 10

async def main():
    sem = asyncio.Semaphore(3)
    results = await asyncio.gather(*(call_api(sem, i) for i in range(10)))
    print(results)
    print("peak concurrent calls:", peak)

asyncio.run(main())

Output:

[0, 10, 20, 30, 40, 50, 60, 70, 80, 90]
peak concurrent calls: 3

Follow-ups:

1. "Semaphore(10) vs '10 requests per second': same thing?" No. A fast API could serve 10 concurrent requests many times per second. Use a token bucket, or space out the starts.
2. "What if one request hangs forever?" It holds a semaphore slot forever. Always set a timeout (client timeout or asyncio.timeout) so slots are released.
3. "Would threading.Semaphore work here?" No. It blocks the whole thread, and with it the event loop. Use the asyncio version.

Scoring: Strong: Uses an asyncio Semaphore correctly, mentions queue-based workers or client limits, and distinguishes concurrency from rate. Acceptable: Knows a semaphore is the answer but places it awkwardly (e.g. around gather). Red flag: Proposes time.sleep between calls, or batching with sequential awaits only.

JR-TH-ASY-04 · gather does not cancel the others on failure

Medium & Tricky · Theory · Junior (1–3 years) · asyncio, gather, exceptions, TaskGroup · 5 min

Question: You charge two orders with asyncio.gather(charge("A1"), charge("A2")). A1 fails. Does A2 still get charged?

Answer:

Trap: "When one task in gather fails, the others are cancelled." Not with plain gather (the default return_exceptions=False). The first exception is raised to whoever awaited gather, but the other awaitables are not cancelled; they keep running. A2 still gets charged after your code has already handled "card declined", so a step you think was aborted actually happened.

If main() returned right away, asyncio.run would cancel the leftover task at shutdown, which is a different, timing-dependent outcome.

The options:

• return_exceptions=True: gather waits for everything and puts exceptions in the result list as values; check each with isinstance(r, Exception). Good for independent jobs, such as sending 50 notifications.
• asyncio.TaskGroup (3.11+): if one task fails, the others are cancelled and the errors are raised together as an ExceptionGroup (catch with except*). Good for "all or nothing" steps.

Pick by meaning, not by habit.

import asyncio

async def charge(order_id, delay, fail=False):
    await asyncio.sleep(delay)
    if fail:
        raise ValueError(f"card declined for {order_id}")
    print(f"charged {order_id}")
    return order_id

async def main():
    try:
        await asyncio.gather(charge("A1", 0.01, fail=True), charge("A2", 0.03))
    except ValueError as exc:
        print("gather raised:", exc)
    await asyncio.sleep(0.05)      # give A2 time to finish

    results = await asyncio.gather(charge("B1", 0.01, fail=True), charge("B2", 0.02),
                                   return_exceptions=True)
    print(results)

asyncio.run(main())

Output:

gather raised: card declined for A1
charged A2
charged B2
[ValueError('card declined for B1'), 'B2']

Follow-ups:

1. "How do you handle errors from a TaskGroup?" except* ValueError as eg: then loop over eg.exceptions. You can have several except* clauses for different types.
2. "What if the gather(...) itself is cancelled, e.g. by a timeout?" Then all of its unfinished children are cancelled too.
3. "For payments, is cancelling A2 enough to be safe?" No. Cancellation can arrive after the provider already processed the charge. Use idempotency keys and reconcile with the provider's status.

Scoring: Strong: Knows plain gather doesn't cancel siblings, explains return_exceptions=True vs TaskGroup, and picks by semantics. Acceptable: Knows return_exceptions but assumes the default cancels the rest. Red flag: Thinks the exception is silently swallowed, or that the whole program stops.

JR-TH-ASY-05 · Timeouts in asyncio

Hard · Theory · Junior (1–3 years) · asyncio, timeouts, wait_for, cancellation · 7 min

Question: How do you put a timeout on a slow async call, or on a whole block of calls? What happens to the work that timed out?

Answer:

Two tools:

• await asyncio.wait_for(coro, timeout=...) for a single awaitable.
• async with asyncio.timeout(seconds): (3.11+) around a block of several awaits, e.g. a whole endpoint's budget.

On timeout, asyncio cancels the inner work: CancelledError is raised inside it at the await where it's waiting, so its finally blocks and async with cleanups run (that's why "cleanup" prints before the handler). Then the caller gets TimeoutError, which since 3.11 is the built-in TimeoutError.

The work is abandoned, not paused. If the remote side already processed your request, it may still have happened, so make retries idempotent.

Practical points:

• HTTP clients have their own timeouts. httpx defaults to 5 seconds; set them explicitly per call.
• Don't swallow CancelledError. It inherits from BaseException (since 3.8), so except Exception doesn't catch it, but a bare except: does, and then timeouts and shutdown stop working.

import asyncio

async def slow_gst_lookup(gstin):
    try:
        await asyncio.sleep(1)
        return "valid"
    finally:
        print(f"cleanup for {gstin}")

async def main():
    try:
        result = await asyncio.wait_for(slow_gst_lookup("27ABCDE1234F1Z5"), timeout=0.05)
    except TimeoutError:
        result = "unknown (timed out)"
    print(result)

    try:
        async with asyncio.timeout(0.05):
            await slow_gst_lookup("29PQRSX5678K1Z2")
    except TimeoutError:
        print("whole block timed out")

asyncio.run(main())

Output:

cleanup for 27ABCDE1234F1Z5
unknown (timed out)
cleanup for 29PQRSX5678K1Z2
whole block timed out

Follow-ups:

1. "You want to stop waiting but let the work finish in the background. How?" Start it as a task and use asyncio.wait({task}, timeout=...), which doesn't cancel, or wrap it in asyncio.shield(). Keep a reference to the task.
2. "How would you retry a call that times out?" A loop with a per-attempt timeout, a capped number of attempts and exponential backoff with jitter, and only for idempotent operations.
3. "asyncio.timeout vs wait_for: which for a whole request handler?" asyncio.timeout: one deadline across several awaits without wrapping each call.

Scoring: Strong: Names wait_for and asyncio.timeout, explains cancellation with cleanup then TimeoutError, and warns about idempotency and swallowing CancelledError. Acceptable: Uses wait_for correctly but thinks the timed-out coroutine keeps running. Red flag: Uses time.sleep / threads to implement timeouts, or catches the timeout with except Exception around unrelated code.

JR-TH-ASY-06 · asyncio.run inside a running event loop

Hard & Tricky · Theory · Junior (1–3 years) · asyncio, asyncio.run, FastAPI, Jupyter, sync/async boundary · 6 min

Question: A sync helper get_price_sync() calls asyncio.run(get_price(sku)). It works from a script but fails when called from a FastAPI async def endpoint or a Jupyter cell. Why?

Answer:

Trap: "asyncio.run is the universal way to call async code from anywhere." It creates a new event loop and is meant for the program's entry point. A thread can run only one event loop at a time. Inside an async def endpoint, or in Jupyter (which already runs a loop), the thread's loop is already running, so asyncio.run raises RuntimeError: asyncio.run() cannot be called from a running event loop. Because the coroutine you passed never ran, you also get a "coroutine was never awaited" RuntimeWarning on stderr.

Even if it were allowed, blocking the running loop until an inner loop finishes would freeze every other request on that loop.

Fixes:

• In async code, make the caller async and await the coroutine directly. Jupyter supports top-level await.
• Expose both a sync and an async version of the helper instead of hiding asyncio.run inside a library function.
• From a worker thread with no running loop (e.g. a FastAPI sync def endpoint, which runs in a thread pool), asyncio.run works, though it creates a loop per call. To hand work to the main loop from another thread, use asyncio.run_coroutine_threadsafe(coro, loop).

Avoid "nest_asyncio"-style patches in production code.

import asyncio

async def get_price(sku):
    await asyncio.sleep(0)
    return 499

def get_price_sync(sku):
    return asyncio.run(get_price(sku))       # fine from plain sync code

print(get_price_sync("SKU-1"))

async def handler():
    try:
        return get_price_sync("SKU-2")        # sync helper called inside a running loop
    except RuntimeError as exc:
        print(exc)
    return await get_price("SKU-2")           # the fix: just await it

print(asyncio.run(handler()))

Output:

499
asyncio.run() cannot be called from a running event loop
499

Follow-ups:

1. "The reverse problem: calling a slow sync function from async code?" await asyncio.to_thread(fn, *args) so it runs in a thread and doesn't block the loop.
2. "Why does Jupyter let you await at the top level?" IPython runs each cell inside an already running event loop (autoawait), which is also why asyncio.run fails there.

Scoring: Strong: Explains one running loop per thread, that asyncio.run is for entry points, and gives await / separate APIs / run_coroutine_threadsafe. Acceptable: Knows the error and the 'just await it' fix, but not the thread-based options. Red flag: Suggests catching the RuntimeError and calling loop.run_until_complete on the running loop.

JR-TH-BE-01 · Path, query or body in a CRUD API

Easy · Theory · Junior (1–3 years) · REST, HTTP, API design, CRUD, FastAPI · 4 min

Question: In a REST API for orders, when does data go in the URL path, the query string, or the request body? Sketch the CRUD endpoints.

Answer:

• Path: identifies which resource. /orders/{order_id}, or /customers/{id}/orders for a nested collection.
• Query string: optional modifiers on a read, usually a collection: filtering, sorting and pagination, as in GET /orders?status=paid&sort=-created_at&limit=20.
• Body (JSON): the resource's data when you create or update it, validated against a schema.

CRUD for orders:

Conventions: plural nouns for resources and HTTP methods for actions (POST /orders, not /createOrder); GET never changes anything.

Keep secrets and personal data (tokens, phone numbers, PAN) out of URLs: paths and query strings end up in server logs, browser history and proxy logs. Send them in headers or the body.

In FastAPI the rule is mechanical: a parameter named in the path template is a path parameter, other simple-typed parameters are query parameters, and a Pydantic model parameter is the JSON body.

Follow-ups:

1. "Search with many filters makes a very long query string. Is it OK to use POST /orders/search with a JSON body?" Yes, it's a common pragmatic choice for complex searches. You lose easy caching and shareable URLs of a GET, so use it when the filter really doesn't fit in a URL.
2. "Should GET /orders/123 for another customer's order return 403 or 404?" Often 404, so you don't reveal that the order exists. 403 is fine where existence isn't sensitive. Either way, check ownership on every request.
3. "Why return the created resource and a Location header from POST?" The client learns the server-generated ID and fields (timestamps, status) without a second request, and Location tells it where the resource lives.

Scoring: Strong: Gives the path/query/body rule, a full CRUD table with methods and status codes, noun-based URLs, safe GET, and keeps sensitive data out of URLs. Acceptable: Correct CRUD methods and the path vs query distinction, with some status codes missing. Red flag: Puts actions in URLs (/deleteOrder?id=), changes data with GET, or puts tokens in query strings without concern.

JR-TH-BE-02 · Pydantic silently ignores unknown fields

Easy & Tricky · Theory · Junior (1–3 years) · Pydantic, validation, FastAPI, extra fields, API design · 4 min

Question:

A signup endpoint takes this body model:

class SignupIn(BaseModel):
    name: str
    email: str
    newsletter: bool = False

The mobile app sends {"name": "Priya", "email": "priya@example.in", "newsltter": true}. What does the endpoint receive? Does the client get an error?

Answer:

Trap: "422, because newsltter isn't a field."

By default Pydantic models use extra="ignore": unknown keys are dropped without an error. The typo'd key disappears, newsletter takes its default False, and the request succeeds. Users who opted in are silently not subscribed, and nobody notices until marketing asks why sign-ups dropped.

Choose the behaviour on purpose:

• model_config = ConfigDict(extra="forbid") rejects unknown keys with an extra_forbidden error (a 422 in FastAPI), so client typos fail in testing instead of in the data. This is a good default for request bodies you own.
• extra="ignore" (the default) is useful when clients may send fields your version doesn't know yet, at the cost of hiding mistakes.
• Either way, declare the fields the client may set, and never build database rows from the raw request dict. Ignoring or forbidding unknown keys is what stops a client from sending "is_admin": true and having it saved.

A related default: Pydantic's lax mode also coerces some values (the string "29" into an int field, "yes" into True). Use strict=True on a model or field when the exact JSON type matters.

from pydantic import BaseModel, ConfigDict, ValidationError

class SignupIn(BaseModel):
    name: str
    email: str
    newsletter: bool = False

payload = {"name": "Priya", "email": "priya@example.in", "newsltter": True}   # typo
print(SignupIn.model_validate(payload))

class StrictSignupIn(SignupIn):
    model_config = ConfigDict(extra="forbid")

try:
    StrictSignupIn.model_validate(payload)
except ValidationError as e:
    for err in e.errors():
        print(err["loc"], err["type"])

Output:

name='Priya' email='priya@example.in' newsletter=False
('newsltter',) extra_forbidden

Follow-ups:

1. "Would making newsletter required (no default) have caught the typo?" Yes: the request would fail with missing for newsletter. But optional fields with defaults are common, so extra="forbid" is the more general guard.
2. "What does extra="allow" do?" It keeps the unknown keys on the model (in model_extra, and in model_dump()). Useful for pass-through data, but dangerous if the dump is written to the database.
3. "Should responses also use extra="forbid"?" Response models are about what you send, so the useful rule is the opposite: a separate output model that lists only the fields clients may see, so internal fields are never serialised.

Scoring: Strong: Knows unknown fields are ignored by default, explains the silent data loss, uses extra="forbid" deliberately, and links field allow-listing to mass-assignment safety; mentions lax coercion. Acceptable: Knows extra keys are ignored and how to forbid them, without the security angle. Red flag: Believes Pydantic rejects any unexpected input by default, or passes request.json() straight into an ORM model.

JR-TH-BE-03 · Protecting a login endpoint from brute force

Medium · Theory · Junior (1–3 years) · authentication, rate limiting, security, status codes, testing · 6 min

Question: Your login endpoint takes an email and password. How do you protect it against password guessing and credential stuffing?

Answer:

Attackers either try many passwords against one account (brute force) or try leaked email/password pairs from other sites across many accounts (credential stuffing). Layer several defences:

• Rate-limit failed attempts per account and per client IP. For example, at most 5 failures per account in 15 minutes, then reject with 429 Too Many Requests and a Retry-After header. The snippet shows a sliding-window limiter with an injected clock, which also makes it easy to test. In production the counters must live in shared storage (Redis), not in one process's memory, or each worker counts separately.
• Prefer temporary throttling to permanent lockout. Locking an account after N failures lets anyone lock out a real user by typing wrong passwords. Use delays or short lockouts, plus a CAPTCHA or an OTP challenge after repeated failures.
• Don't reveal which part was wrong. Return the same message ("Invalid email or password") and status for an unknown email and a wrong password. Keep response times similar too, for example by still running the password check against a dummy hash. Otherwise attackers can find out which emails have accounts. Apply the same rule to "forgot password" responses.
• Store passwords with a slow, salted hash (argon2, bcrypt, scrypt or PBKDF2) and compare in constant time.
• Offer or require MFA (OTP, authenticator app) for sensitive accounts, and check new passwords against known-breached lists.
• Log and alert on spikes in failures, and never log the submitted passwords.

from collections import defaultdict, deque

class LoginLimiter:
    """At most `limit` failed attempts per key in any `window` seconds."""

    def __init__(self, limit, window, clock):
        self.limit, self.window, self.clock = limit, window, clock
        self.failures = defaultdict(deque)

    def allowed(self, key):
        q, now = self.failures[key], self.clock()
        while q and q[0] <= now - self.window:
            q.popleft()                      # forget failures outside the window
        return len(q) < self.limit

    def record_failure(self, key):
        self.failures[key].append(self.clock())

now = [0]                                     # fake clock, in seconds
limiter = LoginLimiter(limit=3, window=300, clock=lambda: now[0])
key = "account:asha@example.in"

for t in [0, 10, 20, 30]:
    now[0] = t
    ok = limiter.allowed(key)
    print(f"t={t:>3}s allowed={ok}")
    if ok:
        limiter.record_failure(key)          # wrong password each time
now[0] = 301
print("t=301s allowed=", limiter.allowed(key), sep="")

Output:

t=  0s allowed=True
t= 10s allowed=True
t= 20s allowed=True
t= 30s allowed=False
t=301s allowed=True

Follow-ups:

1. "Why limit by account and by IP?" Per-account limits stop many guesses against one user; per-IP limits slow one machine trying many accounts. Credential stuffing from many IPs needs both, plus signals like failure spikes across the site.
2. "What should happen to the failure counter after a successful login?" Reset it for that account, so a user who mistyped twice and then logged in starts fresh next time.
3. "Why does the limiter take a clock argument?" So tests can control time and check the window without sleeping. In production you'd pass time.monotonic.

Scoring: Strong: Distinguishes brute force from credential stuffing, rate-limits per account and IP with 429 and shared storage, avoids lockout abuse, prevents user enumeration (message and timing), and mentions hashing, MFA and alerting. Acceptable: Proposes rate limiting or lockout and a generic error message, without the lockout-abuse or shared-storage points. Red flag: Returns "user not found" vs "wrong password", locks accounts permanently, or logs submitted passwords.

JR-TH-BE-04 · JWTs are signed, not encrypted

Medium & Tricky · Theory · Junior (1–3 years) · JWT, authentication, base64, HMAC, tokens · 6 min

Question: A teammate puts the user's role, phone number and PAN in the JWT the API issues at login, saying "it's fine, the token is encrypted". Is it? What does the signature actually protect?

Answer:

Trap: "A JWT is encrypted, so its contents are secret."

A standard JWT (a JWS) is header.payload.signature. Header and payload are just base64url-encoded JSON; anyone holding the token can decode them without any key (the snippet does it in two lines). So the phone number and PAN are readable by the browser, by any JavaScript running on the page, and by anything that logs the token. Keep personal data and secrets out of it: put a user ID and the minimum claims needed.

The signature (HMAC-SHA256 with a server secret for HS256, or a private key for RS256) guarantees integrity: if someone edits "role": "viewer" to "admin", the signature no longer matches. But it only protects you if the server checks it properly:

• Verify the signature on every request, and pin the algorithm: jwt.decode(token, key, algorithms=["HS256"]) in PyJWT. Never accept alg: none, and never decode with verification turned off.
• Check the claims: exp (expiry), and iss/aud if you use them.
• Keep the secret secret and strong; with HS256 anyone who has the secret can mint tokens.

Design consequences:

• A JWT stays valid until it expires, even after logout or a role change. Use short-lived access tokens (minutes) with refresh tokens, or a server-side denylist, if revocation matters.
• Where the browser stores it matters: localStorage is readable by any XSS; an HttpOnly cookie isn't (but then you need CSRF protection).

If the contents really must be hidden, that's JWE (encrypted JWT), but usually the answer is simply not to put sensitive data in the token.

import base64
import hashlib
import hmac
import json

def b64url(data: bytes) -> str:
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode()

header = b64url(json.dumps({"alg": "HS256", "typ": "JWT"}).encode())
payload = b64url(json.dumps({"sub": "user_42", "role": "viewer", "exp": 1775000000}).encode())
signature = b64url(hmac.new(b"server-secret", f"{header}.{payload}".encode(),
                            hashlib.sha256).digest())
token = f"{header}.{payload}.{signature}"

# Anyone holding the token can read the payload: no key needed
part = token.split(".")[1]
print(json.loads(base64.urlsafe_b64decode(part + "=" * (-len(part) % 4))))

# But changing it breaks the signature
forged = b64url(json.dumps({"sub": "user_42", "role": "admin", "exp": 1775000000}).encode())
expected = b64url(hmac.new(b"server-secret", f"{header}.{forged}".encode(),
                           hashlib.sha256).digest())
print("forged token valid?", hmac.compare_digest(expected, signature))

Output:

{'sub': 'user_42', 'role': 'viewer', 'exp': 1775000000}
forged token valid? False

Follow-ups:

1. "An admin demotes a user, but the user keeps admin access for another 50 minutes. Why?" The role is baked into a token valid for an hour, and the server trusts the token without checking the database. Shorten access-token lifetime, re-check roles for sensitive actions, or keep a denylist or token version per user.
2. "What's the risk of jwt.decode(token, options={"verify_signature": False}) in an auth path?" Anyone can craft a token with any claims and it's accepted. That option is only for inspecting tokens in debugging tools, never for authorisation.
3. "HS256 vs RS256: when would you choose RS256?" When other services need to verify tokens but must not be able to issue them: they get the public key, and only the auth service holds the private key. With HS256 every verifier holds the shared secret and could mint tokens.

Scoring: Strong: Explains base64url encoding vs encryption, what the signature guarantees, verification with a pinned algorithm and expiry, revocation limits, and storage trade-offs. Acceptable: Knows the payload is readable and signed, not encrypted, and that the signature must be verified, without algorithm pinning or revocation. Red flag: Believes the payload is secret, or trusts claims without verifying the signature.

JR-TH-BE-05 · Making a two-step wallet transfer atomic

Hard · Theory · Junior (1–3 years) · transactions, sqlite3, databases, atomicity, error handling · 7 min

Question: A wallet-transfer endpoint runs two UPDATE statements, a credit and a debit. What can go wrong without a transaction, and how do you use transactions correctly from Python?

Answer:

If the first statement succeeds and the second fails (a constraint violation, a crash, a lost connection, a bug), money has been created or destroyed: Ravi got ₹5,000 that Asha never paid. A transaction makes the pair atomic: either both changes are committed, or neither is.

In Python's DB-API (sqlite3, psycopg), a transaction is opened for you automatically (sqlite3 opens it before the first data-changing statement; psycopg before the first statement of any kind). Nothing is permanent until commit(), and rollback() undoes everything since the last commit. The usual pattern is a context manager:

• with conn: in sqlite3 commits if the block succeeds and rolls back if it raises, as in the snippet. The second transfer fails on the CHECK (balance >= 0) constraint, and Asha's credit from the first statement is undone too.
• psycopg 3: with conn.transaction():. SQLAlchemy: with Session.begin():.

Practical rules:

• One unit of work, one transaction. Group exactly the statements that must succeed together.
• Keep transactions short: no HTTP calls, emails or slow computations inside them. Open transactions hold locks and block other requests.
• Let the database enforce invariants (CHECK, NOT NULL, foreign keys, unique constraints) as the last line of defence, and turn a constraint failure into a clear 4xx (e.g. "insufficient balance") instead of a 500.
• Concurrent requests: two simultaneous transfers can both read the old balance. Do the arithmetic in SQL (SET balance = balance - ? WHERE user = ? AND balance >= ? and check the affected row count) or lock the row (SELECT ... FOR UPDATE in Postgres).

import sqlite3

conn = sqlite3.connect(":memory:")
conn.execute("CREATE TABLE wallet (user TEXT PRIMARY KEY, balance INTEGER CHECK (balance >= 0))")
conn.executemany("INSERT INTO wallet VALUES (?, ?)", [("asha", 1000), ("ravi", 200)])
conn.commit()

def transfer(src, dst, amount):
    with conn:   # commits on success, rolls back if an exception escapes
        conn.execute("UPDATE wallet SET balance = balance + ? WHERE user = ?", (amount, dst))
        conn.execute("UPDATE wallet SET balance = balance - ? WHERE user = ?", (amount, src))

transfer("asha", "ravi", 300)
print(conn.execute("SELECT * FROM wallet ORDER BY user").fetchall())
try:
    transfer("ravi", "asha", 5000)          # second UPDATE violates the CHECK
except sqlite3.IntegrityError as e:
    print("failed:", e)
print(conn.execute("SELECT * FROM wallet ORDER BY user").fetchall())

Output:

[('asha', 700), ('ravi', 500)]
failed: CHECK constraint failed: balance >= 0
[('asha', 700), ('ravi', 500)]

Follow-ups:

1. "What would the balances be after the failed transfer if transfer didn't use with conn: and the caller later called conn.commit()?" The credit to Asha would already have run, so committing would save Asha +5,000 while Ravi's debit never happened: money created from nothing.
2. "The transfer also has to send an SMS. Where does that go?" After the commit. If it runs inside the transaction and the commit then fails, the user gets an SMS for a transfer that never happened. For reliability, record a 'notification pending' row in the same transaction and send it from a worker.
3. "How would you return the failure to the API client?" Catch the specific error (or check the balance with a conditional update) and return a 4xx such as 409 or 422 with a clear message like 'insufficient balance', rather than letting it become a 500.

Scoring: Strong: Explains atomicity with the partial-failure scenario, uses commit/rollback via context managers in sqlite3/psycopg/SQLAlchemy, keeps transactions short, relies on constraints, and flags concurrent updates. Acceptable: Knows to wrap both statements in a transaction with commit and rollback, without the concurrency or side-effect points. Red flag: Commits after each statement, or thinks catching the exception is enough without a rollback.

JR-TH-BE-06 · Placeholders can't bind column names in ORDER BY

Hard & Tricky · Theory · Junior (1–3 years) · SQL injection, sqlite3, parameterised queries, sorting, API design · 6 min

Question: To fix SQL injection in GET /orders?sort_by=amount, a teammate changed f"SELECT ... ORDER BY {sort_by}" to "SELECT ... ORDER BY ?" with (sort_by,). The tests run without errors. Is the endpoint fixed?

Answer:

Trap: "Yes, parameterised queries fix everything."

Placeholders bind values, not identifiers. ORDER BY ? with "amount" means "order by the constant string 'amount'", which is the same for every row, so the results come back unsorted, silently. In the snippet the "sorted" result is just insertion order. SQLite accepts this without complaint; other databases may raise an error or behave the same way. Either way, it doesn't sort by the column.

The same limit applies to table names, column names in SELECT, and the ASC/DESC keyword: none of them can be bound.

The fix is an allow-list: map the API's sort names to known SQL column names, reject anything else with 400, and validate the direction against {"asc", "desc"}. Only allow-listed strings are ever put into the SQL text. With SQLAlchemy you'd map to column objects, e.g. getattr(Order, name) after checking the name against the allowed set.

The original f-string version was injectable. Sort and filter parameters are classic injection points because developers assume they're harmless. And values must still always be bound: WHERE customer = ?, never f"WHERE customer = '{name}'", where name = "x' OR '1'='1" returns every row.

import sqlite3

conn = sqlite3.connect(":memory:")
conn.execute("CREATE TABLE orders (id INTEGER PRIMARY KEY, customer TEXT, amount INTEGER)")
conn.executemany("INSERT INTO orders VALUES (?, ?, ?)",
                 [(1, "Asha", 900), (2, "Ravi", 150), (3, "Meera", 400)])

sort_by = "amount"   # from ?sort_by=amount
rows = conn.execute("SELECT id, amount FROM orders ORDER BY ?", (sort_by,)).fetchall()
print("ORDER BY ? :", rows)

ALLOWED = {"amount": "amount", "customer": "customer", "id": "id"}
column = ALLOWED[sort_by]            # KeyError -> return 400 for anything else
rows = conn.execute(f"SELECT id, amount FROM orders ORDER BY {column}").fetchall()
print("allow-list :", rows)

Output:

ORDER BY ? : [(1, 900), (2, 150), (3, 400)]
allow-list : [(2, 150), (3, 400), (1, 900)]

Follow-ups:

1. "Why didn't the tests catch the unsorted results?" They probably only checked the status code or the number of rows. A sorting test needs data inserted out of order and an assertion on the returned order (ascending and descending).
2. "How would you support sort=-amount for descending order safely?" Strip a leading - to set the direction, look up the rest in the allow-list, and build ORDER BY {column} {'DESC' if desc else 'ASC'} from fixed strings only. Add a unique tie-breaker (, id) so equal amounts have a stable order across pages.
3. "In FastAPI, how can the framework enforce the allow-list?" Type the parameter as a Literal["amount", "customer", "id"] or an Enum; anything else gets a 422 before your code runs. You still map the value to SQL explicitly.

Scoring: Strong: Explains values vs identifiers, why ORDER BY ? silently doesn't sort, fixes it with an allow-list and validated direction, and keeps binding for values, with a test that checks order. Acceptable: Knows column names can't be parameterised and suggests validating the input, without explaining the silent unsorted result. Red flag: Thinks binding fixed it, or "sanitises" by stripping quotes and keeps the f-string with raw input.

JR-TH-CLO-01 · A tax-calculator factory

Easy · Theory · Junior (1–3 years) · closures, nested functions, factories · 3 min

Question: make_tax(rate) defines an inner function apply(amount) that uses rate, and returns it. After gst_18 = make_tax(0.18), make_tax has finished. How does gst_18(1000) still know the rate?

Answer:

apply is a closure: a function that refers to a variable from the enclosing function's scope. When the inner function uses rate, Python keeps that variable alive in a cell attached to the function object (gst_18.__closure__), even after make_tax has returned. Each call to make_tax creates a new scope and a new cell, so gst_18 and gst_5 each have their own rate.

Typical uses at work: small function factories (validators, formatters, per-tenant pricing), callbacks that need a bit of context, and decorators, whose wrapper is a closure over the decorated function.

def make_tax(rate):
    def apply(amount):
        return round(amount * (1 + rate), 2)
    return apply

gst_18 = make_tax(0.18)
gst_5 = make_tax(0.05)
print(gst_18(1000), gst_5(1000))
print(gst_18.__code__.co_freevars, gst_18.__closure__[0].cell_contents)

Output:

1180.0 1050.0
('rate',) 0.18

Follow-ups:

1. "Could you write the same thing without a closure?" Yes: functools.partial(apply_tax, rate=0.18) with a top-level apply_tax(amount, rate), or a small class with a rate attribute and a __call__ method.
2. "Does a nested function that uses no outer variables have a closure?" No. Its __closure__ is None. It's just a function defined inside another function.

Scoring: Strong: Explains the captured variable kept alive after the outer function returns, notes each call gets its own scope, and gives real uses. Acceptable: Describes "the inner function remembers the variable" without the per-call detail. Red flag: Thinks rate is a global, or that it's lost when make_tax returns.

JR-TH-CLO-02 · Why a list-based counter works without `nonlocal`

Easy & Tricky · Theory · Junior (1–3 years) · closures, nonlocal, mutation vs rebinding · 3 min

Question: A counter closure stores its state as calls = [0] and the inner function does calls[0] += 1. There's no nonlocal. Does it work? Would nonlocal be better?

Answer:

Trap: "It fails with UnboundLocalError, like a counter that uses a plain int." It works and returns 1, 2, 3.

The scoping rule is about rebinding a name. calls[0] += 1 reads the name calls (found in the enclosing scope) and then assigns to an item of that list. The name calls itself is never assigned in the inner function, so it isn't made local. calls += 1 on an int would rebind the name, and that's what needs nonlocal.

The list trick was the workaround before Python 3 added nonlocal. Today nonlocal calls with a plain int states the intent more clearly. If the state grows beyond one or two values, use a small class or a dataclass instead.

def make_counter():
    calls = [0]
    def inc():
        calls[0] += 1     # mutates the list; never rebinds `calls`
        return calls[0]
    return inc

def make_counter_nonlocal():
    calls = 0
    def inc():
        nonlocal calls    # needed because we rebind the name
        calls += 1
        return calls
    return inc

c = make_counter()
print(c(), c(), c())
d = make_counter_nonlocal()
print(d(), d())

Output:

1 2 3
1 2

Follow-ups:

1. "Would a dict, state = {"n": 0} with state["n"] += 1, work too?" Yes, for the same reason: it's item assignment on an object, not rebinding the name.
2. "Do two counters made by make_counter() share their count?" No. Each call to make_counter creates a new list, so each closure has its own state.

Scoring: Strong: Says it works and explains rebinding a name versus mutating an object, then prefers nonlocal or a class for clarity. Acceptable: Says it works but explains it vaguely ("lists are mutable"). Red flag: Insists it raises an error, or adds global to fix a non-existent problem.

JR-TH-CLO-03 · `functools.partial` versus a lambda for pre-filling arguments

Medium · Theory · Junior (1–3 years) · functools.partial, lambda, early vs late binding · 4 min

Question: You need a one-argument function that converts USD to INR with today's rate. You can write lambda amt: convert(amt, rate) or partial(convert, rate=rate). How do they differ if rate is updated later in the same scope?

Answer:

• The lambda is a closure. It looks rate up when it's called, so if rate is rebound afterwards it uses the new value (late binding).
• partial evaluates its arguments when it's created and stores the values (p.args, p.keywords), so it keeps the rate it was given (early binding).

Which one is right depends on what you want: a snapshot of the rate when the job started, or always the latest value. Other practical differences:

• partial objects are introspectable (p.func, p.keywords) and can be pickled if the underlying function is a top-level function, so they work with multiprocessing and many task queues. Lambdas can't be pickled by the standard pickle.
• Keyword arguments in a partial can still be overridden at call time: p(10, rate=90.0).
• A lambda can reorder or transform arguments; partial only pre-fills them.

from functools import partial

def convert(amount, rate):
    return round(amount * rate, 2)

rate = 83.0
usd_to_inr_lambda = lambda amt: convert(amt, rate)
usd_to_inr_partial = partial(convert, rate=rate)

rate = 84.5   # rate updated later in the same scope
print(usd_to_inr_lambda(10), usd_to_inr_partial(10))
print(usd_to_inr_partial.func.__name__, usd_to_inr_partial.keywords)

Output:

845.0 830.0
convert {'rate': 83.0}

Follow-ups:

1. "How would you make the lambda keep 83.0 instead?" Bind the value as a default argument, lambda amt, rate=rate: convert(amt, rate), because defaults are evaluated when the lambda is created.
2. "Does partial copy a mutable argument such as a list?" No. It stores a reference, so later mutations of that list are visible. Only rebinding the outer name is not.

Scoring: Strong: Explains late versus early binding with the result, plus at least one practical difference (pickling, introspection, overriding keywords). Acceptable: Gets the result right but can't say why the two differ. Red flag: Thinks they are interchangeable in every case.

JR-TH-CLO-04 · Per-city fee calculators built in a loop

Medium & Tricky · Theory · Junior (1–3 years) · late binding, closures, lambda, default arguments · 4 min

Question: You build fee_calculators[city] = lambda amount: amount * rate while looping over {"Delhi": 0.05, "Mumbai": 0.08}.items(). What does the Delhi calculator return for ₹1000, and what's the cleanest fix?

Answer:

Trap: "50.0, since the lambda was created while rate was 0.05." It returns 80.0. Every calculator uses Mumbai's rate.

The lambdas don't capture the value of rate. They all refer to the same variable rate in the enclosing scope and read it when called. By then the loop has finished and rate holds its last value, 0.08.

Fixes that bind the value at creation time:

• a default argument: lambda amount, rate=rate: amount * rate. Short, but a caller can accidentally override rate by passing a second argument.
• functools.partial(apply_rate, rate=rate) with a named top-level function. Clear, and picklable.
• a factory function: make_calc(rate) returns the inner function, so each call gets its own scope.

In a code review I'd prefer the factory or partial, because the default-argument trick reads like a mistake.

rates = {"Delhi": 0.05, "Mumbai": 0.08}
fee_calculators = {}
for city, rate in rates.items():
    fee_calculators[city] = lambda amount: amount * rate

print({c: f(1000) for c, f in fee_calculators.items()})

def make_calc(rate):
    return lambda amount: amount * rate

fixed = {city: make_calc(rate) for city, rate in rates.items()}
print({c: f(1000) for c, f in fixed.items()})

Output:

{'Delhi': 80.0, 'Mumbai': 80.0}
{'Delhi': 50.0, 'Mumbai': 80.0}

Follow-ups:

1. "Would building the lambdas in a dict comprehension instead of a for loop fix it?" No. The comprehension has its own scope, but there is still one rate variable for the whole comprehension, so all the lambdas see its final value.
2. "How would a test catch this?" Assert each city separately, for example fee_calculators["Delhi"](1000) == 50.0. A test that only checks the last city passes even with the bug.

Scoring: Strong: Predicts 80.0, explains that the closure looks the variable up at call time, and gives a fix with its trade-offs. Acceptable: Knows the default-argument fix but explains the cause vaguely. Red flag: Expects 50.0 and can't explain the result when shown.

JR-TH-CLO-05 · Inspecting what a closure captured

Hard · Theory · Junior (1–3 years) · closures, inspect, debugging, testing · 5 min

Question: A fraud-flag function returned by make_flagger(city) behaves oddly in production. How can you see exactly what it captured and what global names it depends on, without reading all the code that built it?

Answer:

Python exposes a closure's state on the function object:

• f.__code__.co_freevars: the names of captured variables.
• f.__closure__: a tuple of cells in the same order; cell.cell_contents is each current value.
• inspect.getclosurevars(f): a convenient summary, with nonlocals (captured values), globals (module names the function references, with their current values), builtins, and unbound names.

That quickly shows things like "this flagger captured city='Patna', not the city we expected", or "it reads the global THRESHOLD, which a config reload changed".

For testing, it's often better to design the closure so its inputs are explicit: pass the threshold in as a factory argument instead of reading a global. Then the test builds the function with known values and doesn't depend on module state.

import inspect

THRESHOLD = 500

def make_flagger(city):
    blocked = {"Ranchi"}
    def flag(amount):
        return city in blocked or amount > THRESHOLD
    return flag

f = make_flagger("Patna")
cv = inspect.getclosurevars(f)
print(f.__code__.co_freevars)
print(cv.nonlocals)
print(cv.globals)
print(f(600), f(100))

Output:

('blocked', 'city')
{'blocked': {'Ranchi'}, 'city': 'Patna'}
{'THRESHOLD': 500}
True False

Follow-ups:

1. "Why does THRESHOLD show up under globals and not nonlocals?" It's defined at module level, not in an enclosing function, so it isn't captured in a cell. The function looks it up in the module each time it runs.
2. "Can you change a captured value from outside?" Technically yes, by assigning to cell.cell_contents, but that's for debugging only. In code, use a class with attributes if the state needs to change.

Scoring: Strong: Knows __closure__/co_freevars or inspect.getclosurevars, distinguishes captured variables from globals, and suggests making inputs explicit. Acceptable: Would add print statements or use a debugger, and knows closures store variables somewhere on the function. Red flag: Has no way to inspect a function's captured state and no strategy beyond guessing.

JR-TH-CLO-06 · Lambdas from a list comprehension versus a generator expression

Hard & Tricky · Theory · Junior (1–3 years) · late binding, generator expressions, laziness, closures · 5 min

Question: fns = [lambda: i for i in range(3)] gives [2, 2, 2] when you call each one. If you change the brackets to parentheses and call each lambda while looping over the generator, what do you get, and why?

Answer:

Trap: "Also [2, 2, 2]. It's the same late-binding bug." You get [0, 1, 2].

Every lambda still refers to the single variable i and reads it when called. The difference is when it is called:

• The list comprehension runs to completion first, so by the time you call any lambda, i is 2.
• The generator expression is lazy. It produces one lambda, pauses, and your loop calls that lambda before the generator resumes and changes i. Each call happens to see the "right" value.

So the code isn't fixed, it's just accidentally correct: list() the generator first (or store the lambdas and call them later) and you're back to [2, 2, 2]. When code's correctness depends on when it's evaluated, bind values explicitly with lambda i=i: i or partial.

fns = [lambda: i for i in range(3)]
print([f() for f in fns])

gen = (lambda: i for i in range(3))
print([f() for f in gen])

stored = list(lambda: i for i in range(3))
print([f() for f in stored])

Output:

[2, 2, 2]
[0, 1, 2]
[2, 2, 2]

Follow-ups:

1. "Where could this bite in real code?" Building callbacks or tasks lazily and then later deciding to collect them first, for example passing the generator to a function that calls list() or schedules everything before running any. The behaviour silently changes.
2. "Which fix makes it correct regardless of evaluation order?" Bind at creation: lambda i=i: i, functools.partial(fn, i), or a factory function make(i) that returns the lambda.

Scoring: Strong: Predicts [0, 1, 2], explains it as late binding plus lazy evaluation, and shows that collecting the lambdas first brings the bug back. Acceptable: Predicts the result after a hint and connects it to laziness. Red flag: Can't explain why the two versions differ.

JR-TH-CMP-01 · List, dict and set comprehensions over orders

Easy · Theory · Junior (1–3 years) · list comprehensions, dict comprehensions, set comprehensions · 3 min

Question: Given a list of order dicts, how would you use comprehensions to get (a) the IDs of orders worth ₹500 or more, (b) a dict from ID to amount, and (c) the distinct cities?

Answer:

A comprehension is expression for item in iterable, optionally followed by an if filter, wrapped in the brackets for the result type:

• list [...]: [o["id"] for o in orders if o["amount"] >= 500]
• dict {key: value ...}: {o["id"]: o["amount"] for o in orders}
• set {...} with no colon: {o["city"] for o in orders}. Duplicates disappear, and a set has no reliable order for strings, so sort it before displaying.

Compared with a for loop that calls .append(), a comprehension is shorter, says "build a collection" at a glance, and is usually a little faster. Use one when the logic fits on a line or two; switch back to a loop when it doesn't.

orders = [
    {"id": "A1", "city": "Pune", "amount": 1200},
    {"id": "A2", "city": "Delhi", "amount": 300},
    {"id": "A3", "city": "Pune", "amount": 800},
]
big = [o["id"] for o in orders if o["amount"] >= 500]
by_id = {o["id"]: o["amount"] for o in orders}
cities = {o["city"] for o in orders}
print(big)
print(by_id)
print(sorted(cities))

Output:

['A1', 'A3']
{'A1': 1200, 'A2': 300, 'A3': 800}
['Delhi', 'Pune']

Follow-ups:

1. "What does {} on its own create?" An empty dict. An empty set must be written set().
2. "How would you sum the amounts without building a list?" Pass a generator expression to sum: sum(o["amount"] for o in orders).

Scoring: Strong: Writes all three correctly, notes that set order isn't guaranteed, and knows when to fall back to a loop. Acceptable: Writes the list and dict versions but stumbles on the set syntax. Red flag: Can't turn a simple filtering loop into a comprehension.

JR-TH-CMP-02 · Where the `if` goes in a comprehension

Easy & Tricky · Theory · Junior (1–3 years) · comprehensions, conditional expressions, filtering · 3 min

Question: You want to replace negative amounts with 0 and keep everything else. A candidate writes [a for a in amounts if a > 0 else 0]. What's wrong, and what are the two different places an if can go?

Answer:

Trap: "The if ... else goes at the end, like a filter." That's a SyntaxError.

There are two different constructs:

• A filter goes after the for and has no else: [a for a in amounts if a > 0]. It decides whether an item is included, so the result can be shorter than the input.
• A conditional expression (x if cond else y) goes before the for, as part of the output expression: [a if a > 0 else 0 for a in amounts]. It decides what to output for every item, so the result has the same length as the input.

You can combine them: [a if a > 0 else 0 for a in amounts if a is not None]. Here "replace negatives with 0" is the second form.