Backend Developer (Junior Level) Interview Preparation Guide - FAANG Standards

Clarify goals & constraints

• Keep hot OLTP in Postgres for ACID + low-latency (<10ms).
• Move semi-hot analytics to a query-optimized store or read-replica + columnar files.
• Cold archives on S3/Glacier to minimize storage cost; control egress.

Partitioning & TTLs

• Postgres: range partition by event_date (daily/weekly) so whole partitions can be detached/archived.
• TTL policy: retention rules per table (e.g., hot: last 30 days; semi-hot: 31–365 days; cold: >365 days).
• Implementation: background worker (cron / pg_cron) that marks/detaches partitions older than TTL.

Lifecycle & migration

• When partition age > 30d: detach and copy to analytics tier as Parquet on S3 (columnar, compressed).
• When analytics files exceed 180–365d or access frequency low: run batch job to move to Glacier Deep Archive.
• Use S3 Lifecycle rules (Standard -> Intelligent-Tiering -> Glacier) to automate cost transitions.

Query routes & access patterns

• API routes:
  • Hot reads/writes → primary Postgres.
  • Analytics queries → read-replica or Presto/Trino over S3 Parquet.
  • Cold fetch → async job that uses S3 Select or pre-signed URL; notify user when ready.
• Keep metadata in Postgres (pointer to S3 key + tier + last_access) to avoid egress when only metadata needed.

Cost controls

• Use S3 Select to reduce egress by scanning within objects.
• Offer on-demand restore for Glacier with throttles and pricing tiers; cache restored results in a cheap DB (or S3 Standard) for repeated access.
• Monitor access patterns and promote frequently accessed cold data back to semi-hot for a window.

Why this works

• Partition detach + Parquet export gives cheap bulk moves and fast deletes.
• TTLs + lifecycle rules automate transitions.
• Metadata-driven routing and S3 Select minimize expensive data transfer and keep hot data in Postgres for latency-sensitive operations.

Top-down (memoized recursive)

Approach: recursion with cache to avoid exponential recomputation.

# Python top-down memoized solution
from functools import lru_cache

def climb_memo(n: int) -> int:
    @lru_cache(maxsize=None)
    def dfs(k):
        if k == 0: return 1
        if k < 0: return 0
        return dfs(k-1) + dfs(k-2)
    return dfs(n)

Bottom-up (tabulation)

Approach: iterative DP filling array from base cases.

def climb_tab(n: int) -> int:
    if n == 0: return 1
    dp = [0] * (n+1)
    dp[0], dp[1] = 1, 1
    for i in range(2, n+1):
        dp[i] = dp[i-1] + dp[i-2]
    return dp[n]

Space-optimized O(1)

Use rolling variables since each state uses only two prior values.

def climb_rolling(n: int) -> int:
    if n == 0: return 1
    a, b = 1, 1  # a = ways(0), b = ways(1)
    for _ in range(2, n+1):
        a, b = b, a + b
    return b if n >= 1 else a

Complexity

• Memoized: Time O(n), Space O(n) for recursion + cache.
• Tabulation: Time O(n), Space O(n).
• Rolling: Time O(n), Space O(1).

Limitations & large n (n up to 1e9)

Naïve DP (O(n)) is infeasible for n = 1e9 due to time and memory. Use logarithmic-time methods: matrix exponentiation or fast doubling for Fibonacci-like recurrence. Both compute the nth Fibonacci in O(log n) multiplications; implement with modulo if counts must be bounded (common in backend services). Fast doubling is typically fastest and simplest to implement for integers at scale.

I’d start by aligning everyone on the outcome, not the function-specific asks.

Step 1: Clarify the shared goal
I’d bring product, design, data, and engineering into one working session and define the business outcome, success metrics, and deadline constraints.

Step 2: Map dependencies and capacity
I’d list the critical dependencies, identify who owns each one, and make capacity visible by function. That exposes where the real bottlenecks are.

Step 3: Sequence the plan
I’d build the plan around the critical path: what must happen first, what can run in parallel, and what can be deferred. If capacity is tight, I’d use a simple trade-off framework: highest business value, lowest risk, and strongest dependency unlocks first.

Step 4: Create commitment
I’d confirm decision rights, document what each team is committing to, and define checkpoints where we can re-plan if assumptions change.

The goal is not to make everyone equally happy; it’s to make the trade-offs explicit so each group can commit to a plan they helped shape.

Worked example
Say the initiative is a checkout redesign that needs a payments-data migration (data team), a new UI (product design and frontend), and an updated fraud-detection model (data science). In the working session, the shared goal turns out to be reducing checkout abandonment by a set amount before the next major sales event, which becomes the deadline constraint. Mapping dependencies shows the new UI can't ship until the data migration completes, and the fraud model needs at least two weeks of production traffic on the new UI before it can be retrained safely, so the data migration is the critical-path item. Applying the trade-off framework, the data migration (highest dependency-unlock value) is sequenced first, the UI ships second, and the fraud-model update is explicitly deferred to just after the sales event rather than rushed; each team commits to that sequence in writing, with a checkpoint two weeks before launch to re-plan if the migration slips.

Direct answer

Treat the first ninety days as three distinct feedback phases rather than one long ramp: the first thirty days is mostly listening and asking calibrated questions of a wide set of people, the next thirty is testing that understanding through visible small contributions and targeted follow-up questions, and the last thirty is asking for a harder, more evaluative read now that there's real work to point to. At each phase, write down what you heard and what you changed because of it, so the loop is visible, not just felt.

Structured elaboration

• Days one to thirty: who and what. Talk to your manager (what does success look like at thirty, sixty, and ninety days, what's the biggest risk if this goes wrong), two or three peers doing similar work (what do you wish someone had told you when you started, what's the thing that trips people up here), and, if relevant, a couple of people upstream or downstream of your work (what do you actually need from this role that isn't written down anywhere). Questions here are deliberately open and low-stakes: "what should I be paying attention to that I don't know to ask about yet?"
• Days thirty-one to sixty: who and what. After producing something real, a first change, a first analysis, a first design, a first proposal, ask more targeted questions of whoever reviewed it: "was this the right level of detail," "did I miss context I should have had," "is there a pattern in what you're correcting that I should watch for?" This is also when to bring a specific check-in back to your manager: "here's what I've done, here's what I'm still unsure about."
• Days sixty-one to ninety: who and what. Ask for a more evaluative read, since there's now enough of a track record for the answer to be specific rather than generic: "if you were coaching me for the next quarter, what's the one thing I should focus on?" Ask this of your manager and at least one peer whose judgment you trust, since a manager's view and a peer's view often surface different things.
• Tracking that you're acting on it. Keep a simple running log, one line per piece of feedback: what was said, who said it, and what you changed or decided not to change and why. Bring this log into one-on-one check-ins with your manager (a regular short meeting between you and your manager), especially around the day-thirty and day-sixty marks, so your manager sees the pattern, not just individual points, and so you have to be honest with yourself about whether you actually followed through.

Worked example

The questions above stay constant, but what "producing something real" means in days thirty-one to sixty varies by the kind of work. For someone in a data-facing role, the first real deliverable is often getting the data model and who-needs-what-from-it right, so the targeted day-forty-five question becomes, "does my understanding of how this data actually gets used match reality," checked against a specific report or query. For someone in a design role, early feedback is often more about building credibility through a couple of small, well-executed pieces of work before asking for a harder critique, since a design opinion carries more weight once colleagues have seen competent delivery. For someone building technical proposals, such as an architecture document, a natural day-forty-five checkpoint is asking for feedback specifically on the early proposal itself and on communication style, since how something is proposed matters as much as what's proposed when you're new to a team. In every case, the log entry looks the same: what was said, what changed.

Trade-offs and pitfalls

Asking only your manager and skipping peers misses the day-to-day texture a manager doesn't see. Asking the same broad question the whole ninety days, instead of narrowing it as you get more context and more real work to point to, wastes the growing specificity available to you. Collecting feedback but never visibly acting on it reads as performative rather than genuinely coachable. And waiting until day ninety to ask for anything evaluative wastes the early window when small corrections are cheapest to make.

Approach (two‑pointer merge)
Use two pointers i, j iterating over arrays a and b, append the smaller element to result until one array is exhausted, then extend with the remainder. Stable, O(n) time.

Code

from typing import List

def merge_sorted(a: List[int], b: List[int]) -> List[int]:
    # Two-pointer merge into a new list
    i = j = 0
    n, m = len(a), len(b)
    res: List[int] = []
    while i < n and j < m:
        if a[i] <= b[j]:
            res.append(a[i]); i += 1
        else:
            res.append(b[j]); j += 1
    if i < n:
        res.extend(a[i:])
    if j < m:
        res.extend(b[j:])
    return res

Complexity

• Time: O(n + m)
• Space: O(n + m) for result (in-place alternative below avoids extra array)

Edge cases

• One or both arrays empty
• Duplicates and negative numbers handled by <= comparator

In-place alternative (a has extra capacity at end)
If array a has capacity to hold b (e.g., a contains valid n elements followed by space for m more), merge from the end:

• Set write = n + m - 1, i = n - 1, j = m - 1
• While j >= 0: place larger of a[i] and b[j] at a[write], decrement pointers
• This is O(n + m) time and O(1) extra space — useful in backend systems to reduce allocations when merging large sorted datasets.

Purpose (what a sentinel/dummy head is)

A dummy head is a permanent node placed before the first real element of a singly linked list. It never holds user data (or holds sentinel value) and its .next points to the real head. It standardizes list state so the list always has a node to reference.

Benefits (why use it in backend code)

• Eliminates special-case logic for empty list or head operations.
• Simplifies API implementations for insert/delete: fewer null checks and branches.
• Reduces bugs around off-by-one and pointer updates — easier to reason about in concurrent or complex code paths.

Concrete examples

• Insert at head without sentinel:

  • if head == null: head = newNode else newNode.next = head; head = newNode

• Insert with sentinel:

  • newNode.next = sentinel.next; sentinel.next = newNode
  • No null check for head needed.

• Delete first element without sentinel:

  • if head == null: error else head = head.next

• Delete with sentinel:

  • if sentinel.next == null: empty else sentinel.next = sentinel.next.next

Trade-offs

• Small memory overhead: one extra node per list (negligible usually).
• Semantic clarity: you must document that sentinel is not part of data (APIs should expose real head).
• In multithreaded environments, sentinel simplifies locking around head mutations but does not replace proper synchronization.

Use sentinel nodes in backend services when correctness and simpler code paths matter more than a single-pointer memory cost.

Direct answer

An implicit graph never materializes its full node or edge set up front: neighbors are computed on demand by calling produce_neighbors(state), and breadth-first search (BFS) still applies unmodified, since BFS only ever needs "give me the neighbors of this node right now," never the whole graph at once. This is exactly what a state-space search (a puzzle, a game position, an abstract configuration space) needs, since materializing every reachable state ahead of time is often impossible or wasteful.

Structured elaboration

Why BFS still guarantees shortest path here. BFS's core guarantee, the first time a state is discovered it is at its true minimum distance, depends only on exploring states in non-decreasing distance order, never on knowing the graph's shape in advance. Calling produce_neighbors lazily, one node at a time, preserves this exactly: each call happens precisely when that node is dequeued, in the same layer-by-layer order BFS always uses.

Pruning strategies. A visited set is the baseline prune (never re-expand a state already discovered), but implicit graphs often support domain-specific pruning too: reject a neighbor immediately if it violates an invariant (an illegal board position, a state outside a known-safe region) before it is ever added to the queue, saving both the memory to store it and the future work of expanding it. Pruning by domain invariant must never prune a state that could still be on SOME shortest path, or the "shortest" guarantee breaks; a prune based purely on redundancy (already visited) is always safe, a prune based on heuristic judgment is not automatically safe unless proven admissible.

Heuristics. If a heuristic estimate of remaining distance to the goal is available, switching from plain BFS to A* (using the heuristic to prioritize which state to expand next via a priority queue instead of a FIFO queue) can dramatically reduce the number of states visited, at the cost of losing BFS's simplicity and requiring the heuristic to be admissible (never overestimate the true remaining distance) to keep the shortest-path guarantee.

Bidirectional search. When both start and goal are known in advance (not always true in state-space search, but common), growing frontiers from both ends and stopping when they meet bounds the search to roughly the square root of the single-direction node count for a typical branching factor, the same principle as bidirectional BFS on any explicit graph.

Worked example

from collections import deque
from typing import Callable, Iterable, List, Optional, TypeVar

State = TypeVar("State")

def find_shortest_sequence(start: State, goal: State,
                            produce_neighbors: Callable[[State], Iterable[State]]) -> Optional[List[State]]:
    if start == goal:
        return [start]
    parent = {start: None}
    q = deque([start])
    while q:
        s = q.popleft()
        for nxt in produce_neighbors(s):
            if nxt in parent:
                continue
            parent[nxt] = s
            if nxt == goal:
                path = [nxt]
                cur = nxt
                while parent[cur] is not None:
                    cur = parent[cur]
                    path.append(cur)
                return list(reversed(path))
            q.append(nxt)
    return None

if __name__ == "__main__":
    # Abstract 12-state space: from state s, neighbors are s+1, s-1, s+5 (mod 12).
    # Deliberately not a literal grid or puzzle, to make the point that BFS
    # does not care what a "state" actually represents.
    N = 12
    def produce_neighbors(state):
        return [(state + 1) % N, (state - 1) % N, (state + 5) % N]

    path = find_shortest_sequence(0, 7, produce_neighbors)
    print("Shortest sequence 0 -> 7:", path)
    print("Steps:", len(path) - 1 if path else None)

    def is_valid(path, produce_neighbors):
        return all(path[i+1] in set(produce_neighbors(path[i])) for i in range(len(path)-1))
    print("Path uses only real transitions:", is_valid(path, produce_neighbors))

    def full_bfs_dist(start, produce_neighbors):
        dist = {start: 0}
        q = deque([start])
        while q:
            u = q.popleft()
            for v in produce_neighbors(u):
                if v not in dist:
                    dist[v] = dist[u] + 1
                    q.append(v)
        return dist
    ref = full_bfs_dist(0, produce_neighbors)
    print("Matches independent full-BFS distance table:", ref[7] == len(path) - 1)

    print("No path from a state that only transitions to itself:", find_shortest_sequence(100, 200, lambda s: [s]))

Output (actually executed with python3):

Shortest sequence 0 -> 7: [0, 1, 2, 7]
Steps: 3
Path uses only real transitions: True
Matches independent full-BFS distance table: True
No path from a state that only transitions to itself: None

The independent full_bfs_dist helper computes distances to every reachable state from scratch, without reusing the path-returning function's logic, and its distance to state 7 (3) matches len(path) - 1 exactly, confirming the lazily-called produce_neighbors version is genuinely finding a true shortest sequence, not just any sequence.

Complexity

Time $O(N + E)$ where $N$ is the number of reachable states and $E$ is the number of transitions actually explored (both unknown in advance for a true implicit graph, unlike an explicit one where $V$ and $E$ are given). Space $O(N)$ for parent and the queue. Each call to produce_neighbors is charged whatever it costs to compute (in the example above, $O(1)$; in a real puzzle, it might be proportional to board size).

Edge cases

• start == goal: returns [start] immediately, a zero-move sequence, without ever calling produce_neighbors.
• No path exists (as demonstrated by the self-loop-only state 100 in the worked example): the queue drains completely, parent never gains an entry for goal, and the function returns None.
• produce_neighbors yielding a state already on the current path (a state with a transition back to itself, or a cycle in the state graph): handled the same as any other implicit-graph cycle, since the parent dict doubles as the visited set, a state already discovered is never re-enqueued.
• produce_neighbors raising an exception mid-search (a real risk if computing a state's neighbors can fail, for example an invalid board configuration): not handled by the implementation above, and worth flagging explicitly as something a production version would need to decide on: abort the whole search, or treat that state as having no valid neighbors and continue.

Trade-offs and pitfalls

• Common mistake: calling produce_neighbors more than once for the same state (for example, once to check if any neighbor is the goal, and again to actually enqueue them). Since neighbor generation can be expensive in a real state space, the implementation above calls it exactly once per dequeued state and processes each yielded neighbor as it arrives.
• Common mistake: pruning by a heuristic that is not admissible (can overestimate true remaining distance), which silently breaks BFS's shortest-path guarantee; a state that gets pruned because it "looks unpromising" might still sit on the actual shortest path.
• Infinite or unbounded state spaces. Unlike a finite explicit graph, an implicit state space can be infinite (an unbounded counter, an open-ended configuration). Plain BFS on such a space either runs forever if goal is unreachable, or needs an explicit depth cap or iterative-deepening strategy layered on top to guarantee termination even on a "no path exists" input.
• When to reach for A instead.* If a genuinely admissible heuristic exists (an under-estimate of remaining distance that is cheap to compute), A* dominates plain BFS by visiting fewer states while preserving the same shortest-path guarantee; if no such heuristic is available or trustworthy, plain BFS remains the safe default.

Situation & goal
High tail latency on a read-heavy microservice; objective is to add Redis caching to reduce P99 reads without breaking correctness.

1) Diagnose before change

• Profile requests (flamegraphs, p99/p95, op durations) to confirm DB / serialization / network are root cause.
• Identify hot endpoints, traffic patterns, request sizes, and read-after-write consistency requirements.
• Measure current QPS, cacheable ratio, and write frequency.

2) Cache placement

• Start with a remote managed Redis cluster (single-region) for operational simplicity.
• If latency still dominated by network, move to co-located cache instances (sidecar or local Redis) per AZ with replication for failover.
• Consider client-side in-process LRU for ultra-hot tiny objects.

3) Cache key design

• Use deterministic, namespaced keys: service:v1:resource_type:resource_id:fields_hash
• Include version and user-scoped identifiers where relevant; avoid storing unbounded queries (use normalized query signature).
• Keep keys <= 512 bytes; use hashes (sha256) for long query signatures but preserve readable prefixes.

4) Partitioning / sharding

• Use Redis Cluster with key-hash slotting for scalability.
• Ensure key prefixes for related sets map to same shard when you need atomic multi-key ops.
• For client-side sharding, use consistent hashing library.

5) Cache warming and population

• Warm critical hot keys during deploy using background jobs that read DB and write cache.
• Gradual ramp: start with low percentage of traffic routed to cached path (feature flag), use shadow reads (write-through or read-through) to populate without affecting users.
• TTLs: set sensible expirations and use jitter to avoid stampedes. Implement mutex/locking (singleflight) or probabilistic early refresh.

6) Monitoring & alerts

• Track cache hit rate, miss rate, latency (P50/P95/P99) for cache vs DB paths, Redis latency, memory usage, evictions, error rates, and load on origin DB.
• Add dashboards and alerts: hit rate drop, eviction spikes, increased DB QPS, P99 read latency > baseline.

7) Rollback criteria & runbook

• Rollback if:
  • P99 latency doesn't improve or worsens beyond threshold
  • DB load increases unexpectedly (cache miss storm)
  • Data-staleness causing customer-facing errors (consistency violations)
  • Redis errors/evictions causing failures
• Rollback steps: toggle feature flag to disable cache reads/writes, allow TTL expirations, revert deployment config, and run origin warming if needed.

Notes / Best practices

• Prefer read-through/write-through for simplicity; write-back only if safe.
• Add metrics and traces before flip; use canary and gradual rollout.

Direct answer
Holding someone accountable for a genuine pattern of negligence without breaking a blameless culture requires distinguishing a repeated pattern from an unlucky coincidence using evidence, keeping the accountability conversation completely separate from the incident postmortem itself, and framing the response around capability and support rather than punishment, escalating to something more formal only when coaching genuinely hasn't worked.

Structured elaboration

• Distinguish pattern from coincidence. Two incidents with a superficially similar cause aren't automatically a pattern; look at whether the same specific gap (skipping a known safety check, ignoring a documented warning) recurs versus two genuinely different failure modes that happen to involve the same person by chance. A real pattern usually has a common thread beyond just 'this person was involved again.'
• Keep the postmortem and the accountability conversation structurally separate. The postmortem stays blameless and system-focused regardless of who was involved, so the team's trust in the process for THIS and future incidents isn't compromised. The accountability conversation happens privately, between the person and their manager, using evidence from (but not conducted as part of) the postmortem.
• Start with coaching, not discipline. Ask what support, training, or process change would have prevented the repeated pattern; often a repeated 'mistake' is actually a sign of inadequate onboarding, an unclear runbook, or a workload problem, which is itself still a system gap even if it manifests through one person.
• Escalate proportionally and rarely. If coaching, added support, and closer pairing genuinely don't change the pattern over a reasonable period, a more formal process (a documented improvement plan, possibly disciplinary action) may become appropriate, but this is the exception, not the default response to a second incident.
• Protect future reporting. However this is handled, do it in a way that doesn't become the story other engineers hear and conclude 'admitting mistakes here still gets you in trouble eventually.' This usually means keeping the accountability process quiet and dignified rather than a visible warning to the rest of the org.

Worked example
An engineer is involved in their second production incident in two months, both times from skipping a documented pre-deploy check under time pressure. This IS a pattern, not coincidence: the same specific gap recurred. The manager has a private conversation focused on what's driving the pattern: it turns out the engineer is carrying an unsustainable on-call load and has been rushing deploys to keep up, which is itself a systemic and coachable problem, not a character flaw. The response: rebalance the on-call rotation (a real system fix), pair the engineer with a mentor on deploy discipline for a month, and, separately, the postmortem for the second incident still runs fully blamelessly and results in an automated pre-deploy gate that makes the check impossible to skip regardless of who's deploying, which is the durable fix that protects everyone, not just this one engineer.

Trade-offs and pitfalls
The most common mistake is conflating the postmortem itself with the accountability conversation, turning the group meeting into an implicit disciplinary session, which damages trust for every future incident review that person or their teammates attend. A second is either escalating too fast (treating a second incident as proof of negligence without checking for a systemic driver) or never escalating at all even when a genuine pattern persists, which erodes the credibility of accountability existing at all.

Direct answer

Hash each field independently, then combine the per-field hashes with a mixing step, most
commonly the Java-style multiply-add h = 31 * h + fieldHash(field), applied one field at a time
in a fixed order, or an xor-plus-rotate accumulator as an alternative mixing strategy. Handle
null fields with a distinct sentinel value so a missing field never collides with a real value
that happens to hash the same way, and if the key's fields are logically ORDERED (like a
directed edge (from, to)), pick a mixing function that is order-sensitive, since swapping field
order should produce a different combined hash.

Structured elaboration

Multiply-add mixing. Starting from h = 0, fold in each field one at a time:
h = 31 * h + fieldHash(field). The multiplier 31 (an odd prime, chosen historically for being
efficiently computable via a shift-and-subtract on old hardware, and for having good mixing
properties in practice) means each field's contribution is scaled differently depending on its
POSITION, since earlier fields get multiplied by 31 more times than later ones. This is what
makes the combination order-sensitive: combine(a, b) and combine(b, a) generally differ,
because a and b play different roles depending on which position they occupy.

xor+rotate mixing. An alternative: rotate the accumulator by a fixed number of bits, then XOR
in each field's hash: h = rotate_left(h, k) XOR fieldHash(field). This is also order-sensitive
(the rotation happens BETWEEN fields, so which field lands at which rotation phase changes the
result), and distributes bit influence differently than multiply-add; some implementations prefer
it for its simple, fast, branch-free operations.

Handling nulls. A field that is legitimately absent or null must not be silently treated the
same as some default value (empty string, zero) that could also occur as a REAL value, or two
genuinely different composite keys could collide. The fix: define a fixed sentinel hash (for
example, the hash of a marker byte sequence no real field value could ever produce) and use it
whenever a field is null, so (name="Alice", nickname=None) and (name="Alice", nickname="") hash differently, since null and empty string are different values.

Order sensitivity, and when you want it (or don't). If the composite key is inherently
ordered (a directed edge, a version+id pair where the two fields play different roles),
multiply-add or xor-rotate mixing gives you order sensitivity "for free," since each already
depends on field POSITION. If instead the key is a genuinely unordered SET of fields (order
should not matter for equality), you need a different approach: hash each field independently and
combine with a commutative operation, like summing or XOR-ing the individual field hashes
directly (without rotation, which reintroduces order-sensitivity), so permuting the fields leaves
the combined hash unchanged.

Producing stable hashes across language runtimes. A language's BUILT-IN hash function for a
string is frequently randomized per process (to defend against hash-flooding), which makes it
unsuitable as the per-field hash if the combined hash must be reproducible across restarts or
across a different language entirely. Use a fixed, well-specified, content-addressed hash (for
example, a cryptographic digest like SHA-256, or a documented non-cryptographic hash with a
FIXED, published seed) as fieldHash, so the same field VALUE hashes identically regardless of
which process, restart, or language runtime computed it.

Worked example

import hashlib

_NULL_MARKER = b"\x00__NULL__\x00"

def field_hash(value) -> int:
    data = _NULL_MARKER if value is None else repr(value).encode("utf-8")
    return int.from_bytes(hashlib.sha256(data).digest()[:8], "big")

def combine_multiply_add(fields, mask=(1 << 63) - 1):
    h = 0
    for f in fields:
        h = (31 * h + field_hash(f)) & mask
    return h

print(combine_multiply_add(("user-42", None, "US")))
print(combine_multiply_add(("user-42", "", "US")))
print(combine_multiply_add(("alice", "bob")))
print(combine_multiply_add(("bob", "alice")))

Running this: ("user-42", None, "US") and ("user-42", "", "US") produce different combined
hashes (5823293871742902993 versus 8134958508199836266), confirming null and empty string are
never conflated. Swapping field order, combine_multiply_add(("alice", "bob")) versus
combine_multiply_add(("bob", "alice")), produces different hashes (859106286592904078 versus
5917848126298614322), confirming the multiply-add mixing is order-sensitive as intended.

Cross-runtime stability, actually checked (not just claimed)

The claim above, that this scheme is stable across process restarts even though Python's own
built-in string hash() is randomized per process, is worth demonstrating rather than asserting.
This spawns two independent child processes with different PYTHONHASHSEED values and compares
both the built-in hash and the SHA-256-based combined hash between them:

import subprocess
import sys
import os

_CHILD_CODE = '''
import hashlib
_NULL_MARKER = b"\\x00__NULL__\\x00"
def field_hash(value):
    data = _NULL_MARKER if value is None else repr(value).encode("utf-8")
    return int.from_bytes(hashlib.sha256(data).digest()[:8], "big")
def combine_multiply_add(fields, mask=(1 << 63) - 1):
    h = 0
    for f in fields:
        h = (31 * h + field_hash(f)) & mask
    return h
print(hash("user-42"))
print(combine_multiply_add(("user-42", "checkout", "US")))
'''

def run_with_seed(seed):
    env = {"PYTHONHASHSEED": str(seed), "PATH": os.environ.get("PATH", "")}
    out = subprocess.run([sys.executable, "-c", _CHILD_CODE], env=env,
                          capture_output=True, text=True, check=True)
    builtin_hash, combined_hash = out.stdout.strip().splitlines()
    return int(builtin_hash), int(combined_hash)

b1, c1 = run_with_seed(1)
b2, c2 = run_with_seed(999)
print("builtin hash differs across seeds:", b1 != b2)
print("combined hash agrees across seeds:", c1 == c2)

Running this prints builtin hash differs across seeds: True then
combined hash agrees across seeds: True: the two child processes' randomized hash("user-42")
values are different (as expected, since PYTHONHASHSEED changes between them), but the
SHA-256-based combine_multiply_add result for the same composite key is identical in both,
confirming the cross-runtime stability claim rather than just asserting it.

Trade-offs and pitfalls

• Using a language's randomized built-in hash as the per-field hash is the most common bug:
  it works fine within one process's lifetime but silently breaks the moment the combined hash
  needs to survive a restart, be compared across processes, or be recomputed by a different
  language's implementation.
• Order sensitivity is a design DECISION, not an automatic property. Confirm whether the
  composite key is genuinely ordered (use multiply-add or xor-rotate as shown) or genuinely a set
  (use a commutative combination instead); applying the wrong one either silently distinguishes
  keys that should be equal, or silently merges keys that should be distinct.
• Never let null collapse into a real value's hash. This is a subtle correctness bug: it
  usually will not surface in testing until two records that differ only by "field present vs
  field null" collide unexpectedly.
• The multiplier and rotation amount are tuning choices, not magic constants: 31 is a
  well-tested convention (used by Java's own Object.hashCode() combination), but the mixing
  quality still depends on the per-field hash itself being well-distributed; a poor fieldHash
  undermines even a good combination strategy.