Meta Software Engineer (Mid-Level) Comprehensive Interview Preparation Guide

Direct answer

CAP theorem (Consistency, Availability, Partition tolerance) says that when a distributed system's network partitions, some nodes cannot talk to others, you must choose between staying available (keep answering requests) or staying consistent (guarantee every reader sees the latest write); you cannot fully guarantee both during that partition. For a product manager, the useful frame is not the three-letter acronym, it is the trade-off it forces: during a network problem, do we serve possibly-stale data, or do we go silent until we're sure the data is correct? Two analogies below make that concrete, plus where each one starts to mislead.

How to build and stress-test an analogy like this

• Start from something the audience already manages themselves so the coordination problem is intuitive without teaching new vocabulary.
• Map only the DECISION the concept forces (here, what happens when parts can't talk), not every mechanism. If you find yourself trying to represent quorum writes or version numbers in the analogy, you've picked the wrong analogy or gone too deep.
• Stress-test it before using it: ask yourself what a sharp follow-up question would reveal is wrong with it. If it has no honest breaking point, you haven't tested it hard enough, you've only used it once.
• Name the breaking point out loud, before they find it. That's the senior move: it turns a limitation into evidence you understand the real system, instead of a gotcha that undermines the analogy later.
• The same loop, familiar system, one decision, explicit breaking point, works for any concept in this family: explaining algorithmic complexity (Big-O) to a PM, a model's bias/variance trade-off to a stakeholder, why a prediction leans on certain inputs (SHAP values), or why Raft consensus needs a leader election before it can make progress.

Worked example

Analogy 1: bank branches during a network outage. A bank has several branches connected by a private network. A customer withdraws money at Branch A. If the network to Branch B is up, Branch B's ledger updates immediately, every branch shows the correct new balance (Consistency). If a cable gets cut between the branches (a partition), Branch B has two choices: let customers keep withdrawing using its last-known balance (Availability, but the balance might be wrong), or refuse withdrawals until the network is fixed and balances can be confirmed (Consistency, but Branch B is unavailable). What it captures well: the forced, binary choice under a partition, and that it's a business decision, not a bug to fix. Where it breaks: real banks resolve most of this with human reconciliation and legal recourse, an incorrect balance gets corrected by staff, with clear liability rules. Distributed databases usually make this choice automatically, in milliseconds, with no human in the loop, so the "someone will sort it out later" comfort the analogy implies isn't actually available.

Analogy 2: two people, one shared paper shopping list, two different stores. You and a partner keep a shared shopping list at home but each take a photo before heading to a different grocery store. While your phones have signal, any item one of you crosses off can be relayed to the other, so the list stays in sync (Consistency). If both phones lose signal at once (a partition), you each keep shopping off your own photo, you stay productive (Availability), but you risk both buying milk, or neither of you buying it, because neither photo reflects the other's crossed-off items. What it captures well: a partition doesn't stop work, it stops coordination, and the resulting inconsistency is a direct, visible consequence of choosing to stay available. Where it breaks: reconciling two shopping lists is cheap and forgiving, worst case you return the extra milk. Reconciling two halves of a financial ledger or an inventory count is not cheap or forgiving in the same way, so the analogy understates how expensive real clean-up can be.

Trade-offs and pitfalls

Don't let either analogy imply CAP is a permanent, top-level architecture choice; it applies at the moment of a partition, and most systems are both consistent and available the rest of the time. That's the single most common misunderstanding a PM walks away with if you aren't explicit about it. Also resist collapsing CAP into "consistency vs speed," that conflates it with the separate latency/consistency trade-offs many systems make even without a partition. And don't use the analogy to make the decision for the PM, the job here is to make the trade-off legible so they can weigh it against the product's actual tolerance for stale data.

Approach

Weigh each option by how much it actually contributes to what matters end-to-end, not by its own narrow percentage, then treat risk and reversibility as the tiebreaker when the raw numbers are close.

Worked example (illustrative numbers)

Suppose CPU time is 50% of total request time and network serialization (the work of converting data to and from a format for sending over the network) is 25%, with the rest being I/O wait or other work. The algorithmic change, a 30% cut on the 50% component, yields roughly 0.5 times 30%, about 15% overall improvement. The systems fix, a 60% cut on the 25% component, yields roughly 0.25 times 60%, also about 15% overall. On paper, they are a wash, which is exactly the situation where risk and reversibility should decide it, not the headline percentages.

Making the risk concrete

Rather than treat "riskier to deploy" as a vague minus, I would ask specifically why: does it touch shared serialization logic other services depend on, is it hard to test at production scale beforehand, or is rollback difficult if something goes wrong. If the algorithmic change is comparably impactful and lower risk, contained to one component, testable in isolation, easy to roll back, I would do that first, bank the equivalent 15% win at lower risk, and either postpone the systems fix or de-risk it, for example shipping it behind a flag to a small percentage of traffic with a fast rollback path, before committing to it fully.

When I'd flip the order

If the systems fix's real-world upside turned out to be meaningfully larger than the algorithmic change once actually measured, not just estimated, that would justify taking it first despite the risk. But I would not choose the higher-risk option on paper numbers alone when a comparable, safer win is available right now.

Direct answer

Least Recently Used (LRU) evicts based on recency of access and fits workloads where "recently touched" predicts "will be touched again soon"; Least Frequently Used (LFU) evicts based on access count and fits workloads where a stable set of items is popular over a long time, even if not accessed in the last few seconds.

Structured elaboration

• LRU mechanics and fit: LRU tracks the order items were last accessed and evicts the item that has gone the longest without a touch. It fits access patterns with strong temporal locality: a session object, for example, is heavily accessed right after login and then goes cold; LRU naturally keeps the currently-active sessions warm and evicts the ones nobody has touched recently.
• LFU mechanics and fit: LFU tracks how many times each item has been accessed (often with some decay over time to avoid permanently favoring old-but-once-popular items) and evicts the least-accessed item. It fits patterns with a stable long-tail of popular items that get accessed periodically but not necessarily continuously, such as a small set of perennially popular catalog items that get read constantly, interspersed with occasional cold reads of rare items; a pure LRU cache would wrongly evict a genuinely popular item just because it happened not to be touched in the last few seconds.
• LRU's weak spot: a single burst of one-time scans (e.g., a batch job reading every record once) can flush an LRU cache of genuinely hot items, because the scan makes every item "recently used" once, pushing out items that are accessed far more often over time.
• LFU's weak spot: new items start at zero frequency and can be evicted immediately even if they would become popular, because they have not yet accumulated enough hits to compete with established items (this is sometimes mitigated with a decay factor or a frequency-boosted admission window).

Worked example

For user session objects that are heavily read right after login and then rarely touched again: LRU is the right default, because the access pattern IS recency-driven, and LFU would keep old, no-longer-relevant sessions around simply because they accumulated a lot of hits while they were active. For a product catalog with seasonal hot items plus a long tail of rarely-viewed products: LFU (or a hybrid) does better, because a genuinely popular item accessed every few minutes should survive occasional bursts of one-time-scan traffic on unrelated items that would otherwise flush it from an LRU cache.

Trade-offs and pitfalls

LFU requires more bookkeeping (a counter per item, often with decay logic) than LRU's simple access-order list, so it costs more memory and CPU per operation; do not reach for LFU unless the access pattern genuinely benefits from it. Neither pure policy handles every real workload well, which is why production caches (Redis's allkeys-lfu, or an adaptive scheme like W-TinyLFU) increasingly blend recency and frequency signals rather than using either in isolation.

The idea in plain words

A permutation is an ordering of all the items. For n distinct items there are n! of them (n choices for the first slot, n-1 for the next, and so on). The backtracking idea: fill the slots from left to right; at each slot, try every item that has not been used yet, recurse to fill the remaining slots, then take the item back so the next candidate can try the same slot.

The brute-force alternative, generating all n^n sequences and discarding the ones with repeats, wastes almost all of its work. Backtracking never builds a repeat in the first place.

Approach 1: a used array

Keep path (the arrangement so far) and used[i] (whether nums[i] is already in path). A full-length path is one permutation.

Approach 2: swap in place and swap back

Treat the array itself as the state. Slots before index first are fixed. To fill slot first, swap each candidate arr[i] (for i >= first) into that slot, recurse on first + 1, then swap back. This needs no used array and no separate path list.

from itertools import permutations
from typing import List


def permutations_used(nums: List[int]) -> List[List[int]]:
    result: List[List[int]] = []
    path: List[int] = []
    used = [False] * len(nums)

    def backtrack() -> None:
        if len(path) == len(nums):
            result.append(path[:])          # copy: path keeps changing
            return
        for i in range(len(nums)):
            if used[i]:
                continue
            used[i] = True                  # choose
            path.append(nums[i])
            backtrack()                     # explore
            path.pop()                      # undo
            used[i] = False

    backtrack()
    return result


def permutations_swap(nums: List[int]) -> List[List[int]]:
    arr = nums[:]                           # work on a copy of the input
    result: List[List[int]] = []

    def backtrack(first: int) -> None:
        if first == len(arr):
            result.append(arr[:])
            return
        for i in range(first, len(arr)):
            arr[first], arr[i] = arr[i], arr[first]     # choose: put arr[i] at slot first
            backtrack(first + 1)                        # explore
            arr[first], arr[i] = arr[i], arr[first]     # undo: swap back

    backtrack(0)
    return result


print(permutations_used([1, 2, 3]))
print(permutations_swap([1, 2, 3]))

for n in range(0, 7):
    items = list(range(n))
    expected = [list(p) for p in permutations(items)]
    assert permutations_used(items) == expected
    assert sorted(permutations_swap(items)) == sorted(expected)
print("checks passed")
print("empty list:", permutations_used([]), permutations_swap([]))


def leaky(nums):
    result, path, used = [], [], [False] * len(nums)
    def backtrack():
        if len(path) == len(nums):
            result.append(path)             # BUG: no copy
            return
        for i in range(len(nums)):
            if not used[i]:
                used[i] = True; path.append(nums[i])
                backtrack()
                path.pop(); used[i] = False
    backtrack()
    return result


print("without copying:", leaky([1, 2, 3]))


def swap_no_undo(nums):
    arr, result = nums[:], []

    def backtrack(first):
        if first == len(arr):
            result.append(arr[:])
            return
        for i in range(first, len(arr)):
            arr[first], arr[i] = arr[i], arr[first]
            backtrack(first + 1)
            # BUG: no swap back here

    backtrack(0)
    return result


print("swap without swapping back:", swap_no_undo([1, 2, 3]))

Output (the itertools import is only used by the check against the standard library; the solutions do not call it):

[[1, 2, 3], [1, 3, 2], [2, 1, 3], [2, 3, 1], [3, 1, 2], [3, 2, 1]]
[[1, 2, 3], [1, 3, 2], [2, 1, 3], [2, 3, 1], [3, 2, 1], [3, 1, 2]]
checks passed
empty list: [[]] [[]]
without copying: [[], [], [], [], [], []]
swap without swapping back: [[1, 2, 3], [1, 3, 2], [3, 1, 2], [3, 2, 1], [1, 2, 3], [1, 3, 2]]

Both methods find the same six permutations. For a sorted input the used version yields them in lexicographic order, meaning dictionary order: compare first items, and break ties with the second item, then the third (the check above compares it, in order, with itertools.permutations for range(n) inputs). The swap version produces [3, 2, 1] before [3, 1, 2] because swapping reorders the tail (the swap trace below shows exactly where), so compare results as sets or sorted lists, not by position.

Trace of the used version on [1, 2, 3]

This instrumented version of the used recursion prints each choose and undo, indented by depth (depth only controls the indentation); the swap version's instrumented copy follows it in the same block:

from typing import List


def permutations_used_traced(nums: List[int]) -> None:
    path: List[int] = []
    used = [False] * len(nums)

    def backtrack(depth: int) -> None:
        pad = "  " * depth
        if len(path) == len(nums):
            print(f"{pad}full {path} -> record")
            return
        for i in range(len(nums)):
            if used[i]:
                continue
            used[i] = True
            path.append(nums[i])
            print(f"{pad}choose {nums[i]} path={path}")
            backtrack(depth + 1)
            path.pop()
            used[i] = False
            print(f"{pad}undo {nums[i]} path={path}")

    backtrack(0)


def permutations_swap_traced(nums: List[int]) -> None:
    arr = nums[:]

    def backtrack(first: int) -> None:
        pad = "  " * first
        if first == len(arr):
            print(f"{pad}full {arr} -> record")
            return
        for i in range(first, len(arr)):
            arr[first], arr[i] = arr[i], arr[first]
            print(f"{pad}swap slots {first},{i} arr={arr}")
            backtrack(first + 1)
            arr[first], arr[i] = arr[i], arr[first]
            print(f"{pad}swap back {first},{i} arr={arr}")

    backtrack(0)


permutations_used_traced([1, 2, 3])
print("--- swap version ---")
permutations_swap_traced([1, 2, 3])

The first half of its output is the used trace:

choose 1 path=[1]
  choose 2 path=[1, 2]
    choose 3 path=[1, 2, 3]
      full [1, 2, 3] -> record
    undo 3 path=[1, 2]
  undo 2 path=[1]
  choose 3 path=[1, 3]
    choose 2 path=[1, 3, 2]
      full [1, 3, 2] -> record
    undo 2 path=[1, 3]
  undo 3 path=[1]
undo 1 path=[]
choose 2 path=[2]
  choose 1 path=[2, 1]
    choose 3 path=[2, 1, 3]
      full [2, 1, 3] -> record
    undo 3 path=[2, 1]
  undo 1 path=[2]
  choose 3 path=[2, 3]
    choose 1 path=[2, 3, 1]
      full [2, 3, 1] -> record
    undo 1 path=[2, 3]
  undo 3 path=[2]
undo 2 path=[]
choose 3 path=[3]
  choose 1 path=[3, 1]
    choose 2 path=[3, 1, 2]
      full [3, 1, 2] -> record
    undo 2 path=[3, 1]
  undo 1 path=[3]
  choose 2 path=[3, 2]
    choose 1 path=[3, 2, 1]
      full [3, 2, 1] -> record
    undo 1 path=[3, 2]
  undo 2 path=[3]
undo 3 path=[]

Read it as: after choose 1, the slots 2 and 3 are filled by every arrangement of {2, 3}; undo 1 returns path to empty so the first slot can try 2.

Trace of the swap version on [1, 2, 3]

The second half of the same program's output, after the --- swap version --- line. Each line shows the whole array arr; indentation equals first, the number of slots already fixed:

swap slots 0,0 arr=[1, 2, 3]
  swap slots 1,1 arr=[1, 2, 3]
    swap slots 2,2 arr=[1, 2, 3]
      full [1, 2, 3] -> record
    swap back 2,2 arr=[1, 2, 3]
  swap back 1,1 arr=[1, 2, 3]
  swap slots 1,2 arr=[1, 3, 2]
    swap slots 2,2 arr=[1, 3, 2]
      full [1, 3, 2] -> record
    swap back 2,2 arr=[1, 3, 2]
  swap back 1,2 arr=[1, 2, 3]
swap back 0,0 arr=[1, 2, 3]
swap slots 0,1 arr=[2, 1, 3]
  swap slots 1,1 arr=[2, 1, 3]
    swap slots 2,2 arr=[2, 1, 3]
      full [2, 1, 3] -> record
    swap back 2,2 arr=[2, 1, 3]
  swap back 1,1 arr=[2, 1, 3]
  swap slots 1,2 arr=[2, 3, 1]
    swap slots 2,2 arr=[2, 3, 1]
      full [2, 3, 1] -> record
    swap back 2,2 arr=[2, 3, 1]
  swap back 1,2 arr=[2, 1, 3]
swap back 0,1 arr=[1, 2, 3]
swap slots 0,2 arr=[3, 2, 1]
  swap slots 1,1 arr=[3, 2, 1]
    swap slots 2,2 arr=[3, 2, 1]
      full [3, 2, 1] -> record
    swap back 2,2 arr=[3, 2, 1]
  swap back 1,1 arr=[3, 2, 1]
  swap slots 1,2 arr=[3, 1, 2]
    swap slots 2,2 arr=[3, 1, 2]
      full [3, 1, 2] -> record
    swap back 2,2 arr=[3, 1, 2]
  swap back 1,2 arr=[3, 2, 1]
swap back 0,2 arr=[1, 2, 3]

Read it as: at first = 0, swapping slot 0 with slot 2 turns [1, 2, 3] into [3, 2, 1], so the free tail is now [2, 1] and its first arrangement [3, 2, 1] is recorded before the swap at slots 1,2 produces [3, 1, 2]. That is why [3, 2, 1] precedes [3, 1, 2]. Each swap back line restores the array to what it was before the matching swap, so the next candidate starts from a clean state.

How shared-state bugs are avoided

1. Copy on record: path[:] or arr[:] stores a snapshot. The without copying line of the output shows what happens without it: six entries that are all the same (now empty) list.
2. Symmetric undo: every choose has an exact reverse right after the recursive call (path.pop() plus used[i] = False; the second swap). If one half is missing, later branches see leftovers.
3. The input is not mutated: the swap version copies nums first, so the caller's list is unchanged.

Complexity

• Time: there are n! permutations, each copied in O(n) when recorded, so O(n * n!) just for the output. The search tree (every call, partial and full) has about e * n! nodes in total, where e is the constant 2.718... . At depth j (j slots filled) there are n!/(n-j)! nodes: choices for the first slot times choices for the second, and so on. For n = 3 the depths 0, 1, 2, 3 have 1, 3, 6, 6 nodes, which sum to 16, and 16 / 3! = 2.67. That ratio is already near e and climbs toward it: adding n!/(n-j)! for j = 0 to 7 gives 13700 nodes for n = 7, and 13700 / 7! = 2.7183. So the whole tree is only about 2.7 times the number of leaves. The used version scans n slots at each node, so it is also O(n * n!) overall. The swap version does O(1) work per child (no scan), also O(n * n!) because of the copies.
• Space: O(n) auxiliary (recursion depth n, plus path and used), not counting the output, which is n * n! numbers. If the caller does not need every permutation at once, a generator that yields each one keeps memory at O(n).

Edge cases and common mistakes

• Empty list returns [[]] (one permutation, the empty one); a single item returns [[x]].
• With duplicate values both routines emit repeated permutations. For the used version, sort the input and skip nums[i] when it equals nums[i - 1] and used[i - 1] is false. That sorted-neighbour rule does not carry over to the swap version, because swaps move values around and equal values stop being neighbours; there, keep a set of the values already tried in the current slot and skip any repeat.
• Using used = [] as a list of values and testing x in used makes each check O(n); a boolean array is O(1).
• Forgetting to copy (the without copying line) or forgetting to swap back (the swap without swapping back line, which lists [1, 2, 3] and [1, 3, 2] twice and never produces [2, 1, 3] or [2, 3, 1]).

Running the code

python3.12 permutations_backtracking.py

Save the program above as permutations_backtracking.py. No packages are needed (standard library only).

Test scenarios

Establish a baseline at today's concurrency (2 concurrent requests per process) to get today's real latency, throughput, and error numbers, then step through intermediate levels (2, then 4, then 6, then 8) instead of jumping straight to 8. Per-process resource contention, GPU memory pressure, thread contention, internal request batching, often degrades non-linearly, and stepping through finds the actual knee in the curve rather than just confirming the endpoint works or doesn't. Add a sustained soak run AT the target concurrency (8) over a longer window, since some failure modes, GPU memory fragmentation from many small concurrent allocations, gradual memory growth in a long-lived worker process, only surface after sustained concurrent use, not a short burst.

Observability signals to capture

• Latency percentiles (p50/p95/p99, the response times 50%, 95%, and 99% of requests finish faster than respectively; not just an average) at each concurrency step, tail latency is what users actually notice and averages hide it.
• GPU/CPU utilization and memory per process, to see whether higher concurrency is genuinely using more of the accelerator or just queuing behind contention.
• Request queue depth and time-in-queue, if the server batches requests internally.
• Throughput (successful inferences per second) at each step.
• Error and timeout rate at each step, since a server can appear to "handle" higher concurrency by silently dropping or timing out requests rather than genuinely serving them faster.

Chaos testing elements

Kill and restart the model server process mid-load-test to confirm it recovers cleanly at the new concurrency setting without leaking GPU memory from the killed process's in-flight requests. If the model calls out to a downstream dependency (a feature store, another service), briefly saturate that dependency to see whether higher in-process concurrency amplifies a downstream failure into a bigger blast radius than it would at concurrency 2.

Acceptance criteria

• p99 latency at concurrency 8 stays within an agreed bound of the concurrency-2 baseline (tune the exact percentage to the actual SLO, for example no more than 25% higher).
• Throughput per process genuinely increases with concurrency; if going from 2 to 8 doesn't meaningfully raise inferences per second, the process is I/O- or lock-bound and raising concurrency is just adding queuing delay without real gain, that's a finding worth reporting even if it means NOT making the change.
• Error rate stays flat across all steps.
• The process survives the soak run without unbounded memory growth or a crash.

A CRDT (Conflict-free Replicated Data Type) is a data structure whose update and merge operations are mathematically guaranteed to make every replica converge to the same value, with no locking, coordination, or central authority, as long as every update eventually reaches every replica. State-based CRDTs ship the whole replica state and merge it with a commutative, associative, idempotent join function; operation-based CRDTs ship individual operations that must themselves be commutative and be delivered with causal ordering. A grow-only counter (G-Counter) and an observed-remove set (OR-Set) are the two simplest concrete examples of this guarantee in action.

Why convergence is guaranteed

Convergence works because the merge operation is commutative (order doesn't matter), associative (grouping doesn't matter), and idempotent (merging a state with itself changes nothing), so applying merges in any order, any number of times, produces the same final state. Formally, this kind of merge is called a join, and a replica's state is modeled as an element of a join-semilattice: a partially ordered set where the join always computes the least upper bound of two states. That is the actual property behind convergence without coordination: it is not that conflicts never happen, it is that the merge function is defined so a conflict has exactly one well-defined resolution no matter how or when it gets computed.

G-Counter (grow-only counter)

• State: a vector with one non-negative integer slot per replica, c[i].
• Local update: a replica only ever increments its own slot.
• Merge: element-wise maximum across the two vectors.

$c'[i] = \max(c_1[i], c_2[i])$

• Read: sum across all slots.

$\text{total} = \sum_{i} c[i]$

• Because each slot only ever grows for its own replica, taking the max per slot can never lose an increment either side already recorded.

OR-Set (observed-remove set)

• State: a set of (element, unique tag) pairs, split into an add-set and a remove-set of tags.
• Add(e): mint a fresh tag, insert (e, tag) into the add-set.
• Remove(e): copy every tag currently observed for e into the remove-set; it removes only tags this replica has actually seen, never tags added elsewhere that haven't arrived yet.
• Merge: union the add-sets, union the remove-sets.
• An element counts as present if it has at least one tag in the add-set that is not in the remove-set.

Naming the comparators explicitly

Worked example: G-Counter convergence

Three replicas A, B, C start at (0,0,0):

• Replica A processes 2 local increments: its state becomes (2,0,0).
• Replica B processes 3 local increments, concurrently, before hearing from A: (0,3,0).
• Replica C stays idle: (0,0,0).

A and B exchange state and merge (element-wise max): merge((2,0,0),(0,3,0)) = (2,3,0). Read = 2+3+0 = 5. C later merges with that result: merge((0,0,0),(2,3,0)) = (2,3,0). Read = 5. Whichever order the three replicas merge in, the final vector is (2,3,0) and the read is 5, exactly matching the 2+3=5 real increments actually performed. No increment is lost and none is double-counted.

Worked example: OR-Set add and remove race

Replicas R1 and R2 have already converged on a set containing 'milk' with tag t1. The two replicas are then partitioned from each other:

• R1's user removes 'milk': remove-set gains {t1}, the only tag R1 has ever observed for 'milk'.
• R2's user, unaware of the removal, re-adds 'milk': add-set gains a brand-new tag {t2}, so the add-set is now {t1, t2}.

On merge: add-set = {t1, t2} (union), remove-set = {t1} (union). 'milk' is present because t2 is in the add-set and not in the remove-set. This is the correct outcome: R2's re-add introduced a tag the remover never saw, so it survives, exactly the observed-remove semantics the name describes.

Trade-offs & pitfalls

• Storage and bandwidth: every element needs extra metadata (a vector slot per replica for counters, a unique tag per add for sets), and removed elements don't disappear until a garbage-collection pass establishes causal stability across replicas.
• The edge case that catches teams out: CRDTs don't compose across non-commutative operations. A G-Counter or OR-Set is safe because the operations that define it (increment, tagged add and remove) are commutative by construction. But if you build an append-only log CRDT and then bolt on an application-level 'delete the last 3 entries' operation defined by position, that composition is not well-defined under concurrency: 'last 3' means something different on each replica depending on how many entries have been concurrently appended there at the time the delete runs, so two replicas can end up deleting different entries even though each individually applied a correct-looking CRDT merge. The fix is the principle OR-Set already uses: target deletions by a stable element identifier, never by position or count.
• When to avoid: anywhere a global invariant spans multiple keys (uniqueness, a balance that must never go negative), or the business logic genuinely isn't commutative. CRDTs solve convergence, not arbitrary correctness.

Direct answer

Sort the three-valued array in one pass with three pointers, low, mid, high, that carve it into a growing "already-placed-0s" region, a "confirmed-1s" region, and a "not-yet-placed-2s" region, swapping at most once per position and using no extra storage (the Dutch National Flag algorithm). The same low/high swap idea generalizes directly to a two-way in-place partition by any predicate, but that direct generalization is not stable: swapping elements out of place can scramble the relative order of items that land in the same output region, so keeping order stable needs an extra step beyond just relabeling the predicate.

Structured elaboration

The three-way invariant

At every point during the scan: everything before low is 0, everything in [low, mid) is 1, everything after high is 2, and mid is the next unclassified element. When nums[mid] == 0, swapping it to low and advancing both pointers is safe because the element that lands at mid from the swap was already known to be 1 (it came from inside [low, mid)). When nums[mid] == 2, swapping it to high and only decrementing high (not advancing mid) is required because the element swapped in from the unexplored tail is unclassified and must still be examined.

Generalizing to an arbitrary predicate, and where stability breaks

Collapsing the three categories to two, "satisfies the predicate" versus "does not", turns this into the standard in-place two-way partition: scan with a single pointer, swap anything satisfying the predicate to the front. This preserves the $O(n)$ time, $O(1)$ space profile, but it is not stable: a swap moves an element across positions that may already hold other same-category elements, and nothing about the swap preserves their relative order. The demonstration below shows two items in the same category (both satisfying the predicate) ending up reordered relative to each other purely because of how the swaps landed, even though the partition itself (which items are in which category) is correct.

To keep relative order stable while partitioning in place, the pointer-swap approach is not enough on its own. Two honest options:

• Trade space for stability (simple): scan once, appending predicate-true and predicate-false items to two separate output lists in encounter order, then concatenate. This is $O(n)$ time and stable by construction, at the cost of $O(n)$ auxiliary space, no longer in-place.
• Keep $O(1)$ space, pay in time (advanced): a genuinely in-place and stable partition is possible using a recursive divide-and-rotate scheme, partition each half of the array independently, then merge the two halves' boundary regions by rotating the "false" suffix of the left half past the "true" prefix of the right half. This is the same technique behind library-grade in-place stable partitions (for example, C++'s std::stable_partition is specified to do at most $O(n \log n)$ swaps in the general case, or a single linear pass if it is allowed to allocate a temporary buffer). It is a materially different algorithm from the plain DNF swap, not just the same three-pointer idea relabeled.

Worked example

Approach

First, the DNF sort itself:

def dutch_national_flag(nums):
    low, mid, high = 0, 0, len(nums) - 1
    while mid <= high:
        if nums[mid] == 0:
            nums[low], nums[mid] = nums[mid], nums[low]
            low += 1
            mid += 1
        elif nums[mid] == 1:
            mid += 1
        else:  # nums[mid] == 2
            nums[mid], nums[high] = nums[high], nums[mid]
            high -= 1
    return nums

print(dutch_national_flag([2, 0, 2, 1, 1, 0]))

This prints [0, 0, 1, 1, 2, 2].

Second, the two-way generalization by predicate, showing the instability directly on tagged items so reordering is visible:

def unstable_partition(items, pred):
    lo = 0
    for i in range(len(items)):
        if pred(items[i]):
            items[lo], items[i] = items[i], items[lo]
            lo += 1
    return items

labeled = [('a', 1), ('b', 0), ('c', 1), ('d', 0), ('e', 1)]
print(unstable_partition(labeled[:], lambda t: t[1] == 1))

def stable_partition(items, pred):
    true_bucket = [x for x in items if pred(x)]
    false_bucket = [x for x in items if not pred(x)]
    return true_bucket + false_bucket

print(stable_partition(labeled[:], lambda t: t[1] == 1))

This prints:

[('a', 1), ('c', 1), ('e', 1), ('d', 0), ('b', 0)]
[('a', 1), ('c', 1), ('e', 1), ('b', 0), ('d', 0)]

The swap-based version reorders 'b' and 'd' relative to each other (both are category-0, and 'd' ends up before 'b', the reverse of their original order), while the extra-buffer version preserves 'b' before 'd' exactly as encountered.

Key points

• The DNF three-pointer scan and the two-way predicate partition are the same swap mechanism; only the number of categories changes.
• Correctness of which bucket each item lands in is unaffected by the instability; only the order within a bucket is at risk.
• Stability and true in-place ($O(1)$ space) are in tension for this problem: you can have both only by accepting $O(n \log n)$ time via the rotation-based approach, or you can have $O(n)$ time by giving up in-place-ness.

Complexity

DNF: time $O(n)$ (single pass, mid never revisits a position), space $O(1)$.
Unstable two-way partition: time $O(n)$, space $O(1)$.
Stable partition via extra buffer: time $O(n)$, space $O(n)$.

Edge cases

• Empty array, single element, or an already-sorted array: the DNF loop terminates immediately or after trivial no-op passes.
• All elements identical (all 1s, for instance): low never advances, mid sweeps straight to high with no swaps.
• A predicate that is trivially true or false for every element: the two-way partition degenerates to a no-op copy.

Trade-offs & pitfalls

The most common mistake when moving from three-way DNF to a two-way predicate partition is assuming the result is automatically stable "because it's the same kind of algorithm." It is not, and that distinction matters directly whenever a partition needs to preserve, for example, insertion order or timestamp order within each output group (a very common real requirement, such as partitioning a task queue into "ready" versus "blocked" while keeping each group's original ordering). Reaching for the swap-based version there without checking the stability requirement is a silent correctness bug, not just a style choice. When stability genuinely is not required, the swap-based version remains the better default: no allocation, single pass, and it generalizes cleanly to $k$-way partitioning by widening from two pointers to $k-1$ boundary pointers.

Direct answer

An assertion checks a condition that your own code's logic guarantees should always be true if nothing upstream has a bug; an exception handles a condition that the outside world (a user, a file system, a network) can legitimately produce regardless of whether your code is correct. Assertions catch developer errors early and cheaply; exceptions handle the world being unpredictable.

Structured elaboration

What an assertion is for. An assertion encodes an invariant: a statement that, given correct code, must hold at this point in the program no matter what valid input arrives. If it fails, the bug is in the code that led to this point, not in the input or the environment. Because of this, assertions are cheap to reason about (you never need a recovery path for them, the correct response to a failed assertion is to fix the bug) and, in several languages, can be compiled out entirely in optimized production builds, which is precisely why they must never be relied on for something the outside world can trigger.

What an exception is for. An exception handles a condition that is a normal, expected possibility given a correct program: a file that does not exist, a network call that times out, a user who submits invalid input. These require an actual recovery path (retry, a default, informing the user) because they will happen in production no matter how correct the code is.

Preconditions, postconditions, and invariants (design by contract). A precondition is what a function requires to be true of its inputs to behave correctly; a postcondition is what it guarantees to be true of its output if the precondition held; an invariant is a condition that must hold at every observable point in an object's lifetime. Assertions are the natural implementation mechanism for all three inside a single codebase's own internal logic: asserting a precondition at function entry catches a caller who violated the contract due to a bug in their own code, which is different from validating an input that arrived from outside the trust boundary and might be malformed for entirely legitimate reasons.

The line between the two. The test is not "is this input bad", it's "could this input be bad even if every line of my own code is correct". A negative array length passed internally between two functions you wrote and control, where nothing external can produce that value if your code is right, is an assertion case. A negative quantity field parsed from a JSON request body is an exception (or validation-error) case, because a malicious or buggy client can produce it no matter how correct your server code is.

Worked example

A function withdraw(account, amount) internal to a ledger system might assert assert account.balance >= 0, "invariant violated: account balance went negative" right after debiting, because if the debit logic is correct, the balance should never go negative; if this assertion fires, there's a bug in the debit logic itself, and the fix is to find that bug, not to add a check that reacts gracefully to a negative balance in production. Contrast this with the same function's very first line, which must instead RAISE an exception (not assert) if the caller passes a negative amount: a negative withdrawal amount is exactly the kind of thing an upstream caller (a request handler parsing user input) can produce, whether or not the ledger's own internal logic has any bugs at all, so it needs a real, always-active check, and the right response is to reject the request, not to crash a debug build's assertion and silently no-op in production.

Trade-offs and pitfalls

The most costly mistake is using an assertion to validate something a real caller can trigger: because assertions can be disabled in optimized builds in several languages (C's NDEBUG, Python's -O flag), a check that only exists as an assertion can silently vanish in production, meaning the exact case it was meant to guard against reaches production code entirely unchecked. The opposite mistake, wrapping every internal invariant in a full exception with a try/catch elsewhere in the codebase, adds real performance and readability cost for something that, if your own code is correct, should genuinely never happen and does not need a recovery path at all, only a way to fail loudly and immediately during development and testing.

I’d facilitate the conversation around the shared objective first, because people usually disagree on solutions, not the user problem.

My approach:

• Restate the goal and the decision we need to make.
• Ask each function to explain what they need and why.
• Separate must-haves from preferences.
• Use clear criteria: user impact, effort, risk, and release timing.

Then I’d surface the trade-offs openly: if we choose the designer’s version, what slips? If we choose engineering’s approach, what user value do we lose? That makes the decision concrete instead of political.

If the team still can’t align, I’d make the call based on the agreed criteria and explain the rationale. I’d also make sure the decision is documented so nobody feels blindsided later.

What matters most is tone: I’d be firm on the decision but respectful of every viewpoint. People can disagree and still feel heard, which protects the working relationship after the release.

Worked example
Say the release in question is an onboarding redesign: the designer wants a fully polished new flow with custom illustrations and micro-interactions, while engineering proposes a simplified version that reuses existing components to hit the release date. Scoring both against the agreed criteria (user impact, effort, risk, release timing) shows the simplified version delivers most of the user-impact gain at a fraction of the effort and with no timeline risk, while the fully polished version would slip the release by three weeks for a comparatively small additional lift in user impact. So the simplified version ships first, and the custom illustrations and micro-interactions move into a fast-follow scoped for the next release, which is the trade-off made concrete instead of staying a hypothetical "what if."

Direct answer

Use synchronous scoring only when the action on the score must happen before the transaction completes, such as blocking a fraudulent charge. If the action can wait (nightly review, retraining labels), batch scoring buys a heavier, more accurate model at a fraction of the cost. The deciding question: what does a delayed decision cost you, versus an always-on low-latency fleet?

Structured elaboration

Real-time: one hop in a hard end-to-end latency budget, needs near-zero-staleness features (a hot feature store: a system that serves the same precomputed input values, like a rolling transaction count, to the model at scoring time; "hot" means it's updated in near real time rather than nightly), and an always-on fleet sized for peak plus a fallback if the call times out.

Batch: runs on a schedule, so it can use a bigger, slower model on cheaper bursty compute, but adds a detection lag equal to the batch interval, and a partial failure is a silent under-score, not an outage.

Worked example

A 250ms authorize/decline budget, with auth, ledger, and notification already at 180ms:

$\text{fraud model budget} = 250\text{ms} - 180\text{ms} = 70\text{ms}$

Subtract 20ms network/serialization overhead:

$\text{compute budget} = 70\text{ms} - 20\text{ms} = 50\text{ms}$

That rules out heavy ensembles (combining predictions from several models, which multiplies the per-request compute cost) needing multiple feature joins (a feature store lookup that assembles several separate precomputed values into one input record, each join adding its own latency): illustratively, a 3-model ensemble with 2 extra feature joins might cost 90-120ms on its own, already over the 50ms budget, which is what "rules out" means here concretely. For batch: 10 million transactions overnight, 500 records per inference batch, 50ms per batch on one GPU:

$\text{batches} = \frac{10{,}000{,}000}{500} = 20{,}000, \quad \text{GPU time} = 20{,}000 \times 50\text{ms} \approx 16.7\text{ min}$

Across 4 GPUs, about 4 minutes wall time, no idle fleet cost during the day.

Trade-offs and pitfalls

Real-time buys speed but pays for peak capacity around the clock and widens the request's failure surface. Batch is cheaper but the fraud can complete before you act. A common mistake is defaulting to real-time without pricing the fleet against the actual cost of delay. The answer flips when either side of that equation moves: if fraud losses from a delayed decision start to dwarf the cost of an always-on fleet, or a cheaper real-time model becomes accurate enough to fit the leftover latency budget, you're pushed toward real-time; if the model needs more compute than the authorization path can spare, or false declines against legitimate customers become the bigger cost, you're pushed back toward batch.

What the interviewer probes next

Hybrid streaming or micro-batch designs, detecting a batch job that fails partway through, and how the answer shifts if a missed fraud case gets an order of magnitude costlier.