Apple Game Developer (Entry Level) - Comprehensive Interview Preparation Guide

Direct answer

Use a character-then-count convention instead ('aaabb' becomes 'a3b2'): scan once, emitting each run's character followed by its length as an ordinary decimal number, so a run of 12 becomes 'a12' automatically, no extra logic needed for multi-digit counts beyond ordinary integer-to-string conversion. Decoding reads one character, then greedily consumes every digit that follows as its count. Run-length encoding stops being a good idea once the data has little run structure, or, more sharply, once the alphabet itself can contain digit characters, the second case does not just compress poorly, it can silently corrupt the decode.

Structured elaboration

Encoding and decoding. run_length_encode walks the string tracking the current run's length; on each boundary it emits char + str(run_length). run_length_decode reads one character, then reads forward while the next characters are digits, converts that digit run to an integer, and repeats the character that many times. Because Python's str(count) and int(digit_string) both handle any number of digits, a run of 100 encodes and decodes exactly as cleanly as a run of 3, no special-casing needed for the count's width.

When run-length encoding is inappropriate, as the question asks directly:

1. Low-redundancy data. Diverse text with few or no repeated runs can nearly double in size under this encoding, the same argument as the sibling count-then-character convention, just confirmed again below for this format.
2. An alphabet containing digit characters. This is not merely slower, it is a genuine decode-time ambiguity: a digit that is data becomes indistinguishable from a digit that is part of a count, demonstrated concretely below.
3. Data needing random access. Finding the character at an arbitrary offset requires decoding sequentially from the very start; there is no way to jump directly to position 10,000 in the encoded form.
4. Already-compressed or encrypted data. Neither retains any run structure, so applying run-length encoding on top typically expands the data further rather than shrinking it.

Worked example

def run_length_encode(s: str) -> str:
    if not s:
        return ""
    result = []
    i, n = 0, len(s)
    while i < n:
        j = i
        while j < n and s[j] == s[i]:
            j += 1
        result.append(s[i] + str(j - i))
        i = j
    return ''.join(result)

def run_length_decode(encoded: str) -> str:
    result = []
    i, n = 0, len(encoded)
    while i < n:
        char = encoded[i]
        i += 1
        j = i
        while j < n and encoded[j].isdigit():
            j += 1
        count = int(encoded[i:j])
        result.append(char * count)
        i = j
    return ''.join(result)

print(f"run_length_encode('aaabb') = {run_length_encode('aaabb')!r}")
print()

t12 = "a" * 12 + "b"
enc12 = run_length_encode(t12)
dec12 = run_length_decode(enc12)
print(f"run of 12: {t12!r} -> {enc12!r} -> {dec12!r}   roundtrip_ok={dec12 == t12}")

t100 = "z" * 100
enc100 = run_length_encode(t100)
dec100 = run_length_decode(enc100)
print(f"run of 100: 'z'*100 -> {enc100!r} -> roundtrip_ok={dec100 == t100}")
print()

t_digits = "aaa111"
enc_digits = run_length_encode(t_digits)
dec_digits = run_length_decode(enc_digits)
print(f"alphabet-with-digits case: {t_digits!r} -> encoded {enc_digits!r}")
print(f"decoded length = {len(dec_digits)} (expected {len(t_digits)})")
print(f"roundtrip preserved original: {dec_digits == t_digits}")
print()

worst = "abcdefgh"
enc_worst = run_length_encode(worst)
print(f"worst case, no repeats: {worst!r} (len {len(worst)}) -> {enc_worst!r} (len {len(enc_worst)})")

Output:

run_length_encode('aaabb') = 'a3b2'

run of 12: 'aaaaaaaaaaaab' -> 'a12b1' -> 'aaaaaaaaaaaab'   roundtrip_ok=True
run of 100: 'z'*100 -> 'z100' -> roundtrip_ok=True

alphabet-with-digits case: 'aaa111' -> encoded 'a313'
decoded length = 313 (expected 6)
roundtrip preserved original: False

worst case, no repeats: 'abcdefgh' (len 8) -> 'a1b1c1d1e1f1g1h1' (len 16)

'aaabb' encodes to 'a3b2' exactly as given. A run of 12 correctly encodes as 'a12', and a run of 100 as 'z100', confirming multi-digit counts need no special handling. The digit-alphabet case is the sharpest, fully reproduced result here: 'aaa111' (three a's, then three 1's) encodes to 'a313' ('aaa' -> 'a3', '111' -> '13', concatenated). Decoding 'a313' reads the character 'a', then greedily consumes every following digit, '3', '1', '3', as one combined count, and returns 'a' repeated 313 times, a 313-character string, not the original 6-character input. This is an actual, executed failure, not a hypothetical one: the run boundary between the 'a' run and the '1' run was silently destroyed by the encoding itself.

Trade-offs and pitfalls

The digit-alphabet bug above is the sharpest interview signal in this sub-area: naming the fix matters more than the exposure itself. Options include reserving a delimiter character between the character and its count that cannot appear in the source alphabet, escaping digit characters specially before encoding, or simply documenting the scheme as invalid for any alphabet containing digits and validating that precondition before calling it.

Random access remains the wrong-tool problem regardless of compression ratio: even on genuinely repetitive data, if the access pattern needs "the character at position 10,000" without decoding everything before it, run-length encoding is the wrong structure on its own, a different indexed structure, or a hybrid with periodic decode checkpoints, is needed instead.

This character-then-count convention and the count-then-character convention are both valid design choices on their own; the trade-off is between them, not a correctness question of one over the other. What is a genuine bug is mixing the two conventions within one system, or assuming an encoder and decoder from different sources agree on which one is in use.

Direct answer

Maintain an inclusive range [lo, hi] that is the only place the target could still be. At each step, compare the target to the middle element and shrink the range to whichever half could still contain it. The loop ends when lo > hi, at which point the target is not present, so return a sentinel (commonly -1). This runs in $O(\log n)$ time and $O(1)$ space.

Structured elaboration

The loop invariant. Before every iteration, "if the target is present in the array, its index lies within [lo, hi]" holds. Each iteration either returns immediately (found it) or moves lo past mid, or hi before mid, which strictly shrinks the range while preserving the invariant.

Why it terminates. Every iteration where the target is not found at mid removes at least the midpoint from consideration, so hi - lo at least halves (roughly) each time; the range cannot shrink forever without becoming empty, so the loop reaches lo > hi within $O(\log n)$ steps.

Why it never reads out of bounds. mid is always computed strictly between the current lo and hi, both of which start as, and remain, valid indices into the array (or the empty range lo > hi, which the loop condition catches before computing mid at all).

The overflow bug (reviewing someone else's code). Suppose a colleague wrote mid = (lo + hi) // 2. In Python this is safe because integers have arbitrary precision, but in a fixed-width-integer language such as Java or C++, lo + hi can exceed the maximum representable value for a very large array and silently wrap around, producing a corrupted mid that can throw the search out of bounds or into an infinite loop. Writing mid = lo + (hi - lo) // 2 avoids this because hi - lo never exceeds the array's size, so the sum can never overflow the way lo + hi can.

Worked example

def binary_search(nums: list[int], target: int) -> int:
    lo, hi = 0, len(nums) - 1
    while lo <= hi:
        mid = lo + (hi - lo) // 2  # avoids the lo + hi overflow above
        if nums[mid] == target:
            return mid
        elif nums[mid] < target:
            lo = mid + 1
        else:
            hi = mid - 1
    return -1


if __name__ == "__main__":
    nums = [1, 3, 5, 7, 9, 11]
    print(binary_search(nums, 7), binary_search(nums, 4))

Running this prints 3 -1. For target 7: lo=0, hi=5, mid=2 (value 5, too small, lo becomes 3); lo=3, hi=5, mid=4 (value 9, too big, hi becomes 3); lo=3, hi=3, mid=3 (value 7, match, return 3). For target 4: the range keeps shrinking until lo exceeds hi without ever matching, returning -1.

Complexity

Time: $O(\log n)$, since each iteration discards at least half of the remaining [lo, hi] range.
Space: $O(1)$ for this iterative version, since only a fixed number of index variables (lo, hi, mid) are held regardless of the array's size.

Edge cases

• Empty array (len(nums) == 0): lo = 0 and hi = -1 start with lo > hi, so the loop body never runs and the sentinel -1 is returned immediately.
• Target smaller than every element or larger than every element: the range shrinks to empty without ever matching, again returning the sentinel.
• Array with duplicate values: this exact routine returns the index of some matching element, not necessarily the first or last one; that is a distinct, slightly more involved variant.

Trade-offs & pitfalls

A recursive version expresses the same logic but spends $O(\log n)$ call-stack space doing so, where this iterative version uses $O(1)$. The other classic source of infinite loops or off-by-one errors is mixing bound conventions, for example initializing hi = len(nums) (a half-open convention) while writing the rest of the loop as if hi were an inclusive index; pick one convention and keep it consistent throughout.

Situation & Goal
I’m leading a cross-discipline team to replace the live game UI with a modern, performant rewrite while keeping servers and players stable and minimizing churn.

Incremental migration strategy

• Strangler pattern: implement new UI modules as isolated components (main menu, HUD, inventory, matchmaking) behind feature flags.
• Start in a dev branch → internal playtests → limited QA builds → progressive live audience cohorts.
• Use a compatibility layer to translate legacy UI events to new UI contracts so gameplay logic unchanged.

Risk assessment

• High: regressions impacting inputs, performance, net sync. Medium: UX regressions, accessibility. Low: art polish.
• Mitigations: automated input/integration tests, budgeted rollback windows, crash/error budget.

Feature toggles

• Per-module server-side flags + client-side local flags for A/B cohorts.
• Toggle matrix: off, new, hybrid; enforce server-authoritative gating for competitive modes.

Telemetry & KPIs

• Core KPIs: crash rate, frame-time, input latency, menu-to-game time, matchmaking drop, session length, retention (D1/D7), conversion for monetized flows.
• Instrument detailed events: screen load times, button latency, control mapping failures, animation dropouts, error traces with breadcrumbs and user/session IDs.

QA & A/B testing

• Automated UI tests (Unity Test Runner / Unreal automation) + integration tests with bots for deterministic flows.
• Staged playtests: internal, closed beta (power users), randomized A/B on live (1%, 5%, 25%) comparing KPIs.
• Heuristic UX reviews and accessibility checks (screen readers, controller layouts).

Rollout & rollback

• Progressive exposure with kill-switch: 1% → 5% → 25% → 100% with 24–48h observation windows.
• Automatic rollback triggers: crash > 3x baseline, input-lag +50ms, matchmaking failure > 2σ.
• Fast rollback path: server-side flags flip; client receives immediate config and falls back to legacy UI; hotfix pipeline for critical client patches.

Communication

• Players: patch notes, opt-in beta, in-game “Try new UI” toggle, feedback form, known-issues banner, community channels.
• Internal: daily standups during rollout, dashboard with real-time KPIs, escalation playbook, stakeholder updates (prod, design, art, liveops).

Outcome focus
Maintain competitive fairness, minimize regressions, collect quantitative and qualitative feedback, and enable safe, reversible migration.

Direct answer

A* extends Dijkstra's algorithm by adding a heuristic estimate $h(n)$ of the remaining cost from node $n$ to the goal, and expanding nodes in order of $f(n) = g(n) + h(n)$ (cost so far plus estimated cost remaining) rather than $g(n)$ alone. When $h$ is admissible (never overestimates the true remaining cost) A* is guaranteed to find an optimal path, exactly like Dijkstra, but typically explores far fewer nodes because the heuristic actively steers the search toward the goal instead of expanding uniformly outward in all directions. A data-engineering example where this matters: map-matching or shortest-route queries over a road or delivery network, where Dijkstra from a single source explores every direction equally, while A* with a straight-line or great-circle distance heuristic concentrates the search toward the destination.

Structured elaboration

Admissibility. $h(n)$ is admissible if $h(n) \le h^*(n)$ for every node $n$, where $h^*(n)$ is the TRUE optimal cost from $n$ to the goal. This is what guarantees A* never prunes away the actual shortest path: since the heuristic never overpromises, a path that looks worse under $f$ can never actually be better in reality than one A* has already committed to exploring first.

Consistency (monotonicity). A stronger property: $h(n) \le \text{cost}(n, n') + h(n')$ for every edge $(n, n')$, i.e., the heuristic obeys its own triangle inequality along every edge. Consistency implies admissibility, and it additionally guarantees that once a node is popped from the open set with its final $g$ value, that value is already optimal and will never be improved later, exactly the same guarantee Dijkstra relies on for non-negative edge weights. Without consistency (an admissible-but-inconsistent heuristic), A* is still correct, but may need to re-open and re-expand a node whose $g$ value improves after it was first popped, which costs extra work without losing correctness.

Designing or validating an admissible heuristic for a road network. Straight-line (Euclidean) or great-circle distance between two points is a standard admissible heuristic for road routing, since no legal road path can ever be shorter than the straight-line distance between its endpoints; it is also consistent, since the triangle inequality holds for straight-line distance by definition. Validating a CANDIDATE heuristic (for example, a learned or precomputed estimate rather than pure geometry) means checking it never exceeds the true shortest-path cost on a representative sample: run exact Dijkstra from a sample of source nodes, compare the heuristic's estimate at every visited node against Dijkstra's own final distance to the goal from that node, and flag any node where the heuristic's estimate exceeds the true cost, since even a single such violation breaks the optimality guarantee for any query that could pass through that node.

Worked example

10x10 unit-cost grid (each step to an orthogonal neighbor costs 1), start at $(0,0)$, goal at $(9,9)$, with a wall at column 5 blocking every row except row 5 (forcing all paths through that single gap), comparing plain Dijkstra ($h = 0$ everywhere) against A* using the Manhattan distance heuristic $h(n) = |n_r - 9| + |n_c - 9|$ (admissible here because Manhattan distance never overestimates unit-step grid cost, and equals the true remaining cost exactly whenever no obstacle lies on the direct path):

import heapq

def neighbors(pos, grid):
    r, c = pos
    rows, cols = len(grid), len(grid[0])
    for dr, dc in ((1,0),(-1,0),(0,1),(0,-1)):
        nr, nc = r+dr, c+dc
        if 0 <= nr < rows and 0 <= nc < cols and grid[nr][nc] == 0:
            yield (nr, nc)

def manhattan(a, b):
    return abs(a[0]-b[0]) + abs(a[1]-b[1])

def search(grid, start, goal, use_heuristic):
    h = manhattan if use_heuristic else (lambda a, b: 0)
    open_heap = [(h(start, goal), 0, start)]
    best_g = {start: 0}
    expanded = set()
    while open_heap:
        f, g, u = heapq.heappop(open_heap)
        if u in expanded:
            continue
        expanded.add(u)
        if u == goal:
            return g, len(expanded)
        for v in neighbors(u, grid):
            ng = g + 1
            if v not in best_g or ng < best_g[v]:
                best_g[v] = ng
                heapq.heappush(open_heap, (ng + h(v, goal), ng, v))
    return None, len(expanded)

if __name__ == "__main__":
    rows, cols = 10, 10
    grid = [[0]*cols for _ in range(rows)]
    for r in range(rows):
        if r != 5:
            grid[r][5] = 1  # wall column at c=5, gap at row 5

    start, goal = (0, 0), (9, 9)
    d_cost, d_expanded = search(grid, start, goal, use_heuristic=False)
    a_cost, a_expanded = search(grid, start, goal, use_heuristic=True)
    print(f"Dijkstra (h=0): path cost={d_cost}, nodes expanded={d_expanded}")
    print(f"A* (Manhattan h): path cost={a_cost}, nodes expanded={a_expanded}")
    print(f"reduction in nodes expanded: {100*(1 - a_expanded/d_expanded):.1f}%")

Output:

Dijkstra (h=0): path cost=18, nodes expanded=90
A* (Manhattan h): path cost=18, nodes expanded=71
reduction in nodes expanded: 21.1%

Both algorithms agree on the optimal path cost (18 steps), confirming the heuristic did not sacrifice correctness, while A* expanded 71 nodes against Dijkstra's 90, a 21.1 percent reduction, because Manhattan distance actively discourages the search from wasting effort exploring away from the goal, while Dijkstra treats every direction as equally promising until it happens to reach the goal.

Trade-offs and pitfalls

• A only outperforms Dijkstra when the heuristic is genuinely informative.* A degenerate heuristic that is always 0 makes A* mathematically identical to Dijkstra (as shown by the use_heuristic=False branch above, which IS Dijkstra); the benefit is proportional to how tightly the heuristic tracks the true remaining cost, not to using A* as a label.
• An inadmissible heuristic (one that sometimes overestimates) can make A return a suboptimal path*, silently, with no error raised, which is the most dangerous failure mode: the algorithm still terminates and returns SOME path, just not necessarily the shortest one.
• Common mistake: assuming any "reasonable-looking" distance estimate is automatically admissible. A heuristic that accounts for typical road speed (for example, estimating remaining TIME using average highway speed) can easily become inadmissible if the actual route includes a faster-than-average segment, since the estimate could then exceed the true remaining time on that segment; time-based heuristics for road routing need care that pure geometric-distance heuristics do not.
• Bidirectional search and precomputed speedup techniques (Contraction Hierarchies, ALT) typically outperform plain A for production route-finding at scale*, particularly for repeated queries over a largely static road network; A* with a simple geometric heuristic is the right first tool to reach for, but production routing engines usually layer additional preprocessing on top once query volume justifies the added complexity.

Direct answer

Cite one specific, verifiable thing from the company's own public materials (a product decision, an engineering post, a case study), explain concretely why it matters to you, and connect it to a specific piece of your background. Anything that could be copy-pasted into a different company's answer with a find-and-replace is too generic to count.

The framework

1. Name the discovery trigger: how you actually came across the company (a product you used, a post you read, a talk you saw). Optional, but it strengthens credibility because it shows the interest predates the interview.
2. Cite one or two specific, checkable details from their public materials: a product or architecture choice, a stated mission line, a case study result, an engineering blog post. Public materials also include how they compare to a competitor; researching that difference is stronger evidence of real homework than surface reading.
3. Explain why that specific detail matters to you, personally or professionally, in one concrete sentence.
4. Close by connecting it to what you'd bring: a skill, a past project, a stated short-term or long-term goal.

Same move, one altitude up (industry instead of product): "what excites you about our product" and "what excites you about our industry" are two distinct framings of this question, and the construction is the same, just zoomed out. Instead of a product or architecture detail, name one concrete shift or problem in the industry the company operates in, something specific enough that you could be wrong about it, not a vague "this industry is exciting." Then connect it to your background the same way: "[Industry, e.g. healthcare payments] is being reshaped by [specific shift, e.g. the move to real-time claims adjudication], and that's directly related to [a piece of your background, e.g. work you did on a low-latency transaction system], which is part of why this company's position in that shift is what drew me in." The same generic-versus-specific test applies at this altitude: a claim true of every company in the space ("AI is transforming everything") is exactly as weak here as "you're an industry leader" is at the company level.

This same content compresses into a one-page memo or a 60-second pitch: discovery trigger in one sentence, the specific detail plus why it matters in two sentences, the connection to your background in one sentence.

Worked example

I came across [company]'s work through [discovery trigger, e.g. their engineering blog, a product I used, a conference talk]. What stood out was [specific detail, e.g. "a post describing how they redesigned a workflow to solve a particular reliability problem"], because it's the same problem I ran into when I [connect to your background]. That's the kind of work I want to be doing, and I'd bring [a specific skill or experience] to it.

(Domain swap: a Solutions Architect might cite a published case study's architecture pattern; a Product Designer might cite a design-system decision documented publicly; a Cybersecurity Engineer might cite a disclosed incident post-mortem.)

Trade-offs and pitfalls

A detail that's true of almost every company in the space (e.g. "you move fast" or "you care about your customers") signals a skim of the homepage, not research into this company specifically.

Approach summary
Measure using Unity’s profilers and snapshots, identify hot allocation sites from call stacks, then apply targeted fixes (pooling, value types, StringBuilder, avoid LINQ in hot paths).

Tools & metrics

• Unity Profiler (Editor / Development build): CPU Usage, GC Alloc per frame, Total Allocated memory, Mono Heap, Used Heap, GC Collection counts.
• Allocation Timeline (Profiler window → Allocation Callbacks / Detailed): shows per-frame allocations and allocation sites.
• Memory Profiler package: take Memory Snapshots and diff them to find leaking objects and retained sets.
• Deep profiling (sparingly) to capture allocation call stacks.

What to look for in call stacks

• Frequent small allocations per frame (e.g., strings, boxing, IEnumerable/LINQ iterators, closures, anonymous delegates).
• GC.Alloc origins: see user code lines.
• Repeated allocations from Unity API wrappers (e.g., GetComponent in Update returning allocations when misused).
• Boxing of value types or frequent ToString calls.

Common fixes & examples

• Object pooling for bullets, particles, UI elements.
• Use structs for small immutable data to avoid heap allocs (careful with boxing).
• StringBuilder for concatenation in hot paths:

var sb = new StringBuilder();
sb.Append(a).Append(',').Append(b);
var s = sb.ToString();
sb.Clear();

• Avoid LINQ/foreach allocation in Update; use for-loops or manual enumerators.
• Cache components/references, reuse arrays or List<T> (clear instead of new).
• Mark callbacks/static delegates to avoid allocating closures.

Outcome
Iterate: measure → fix largest sources → re-profile to confirm reduced GC Alloc and fewer collections per second.

Direct answer
Cutting a document in half without losing the point means removing words and sentences that restate, hedge, or elaborate past the level of detail the reader needs, not removing content the reader actually needs. Start by identifying the load-bearing sentences, then cut everything else, then tighten what's left.

Structured elaboration

1. Identify the load-bearing sentences first. For each paragraph, ask: if this sentence disappeared, would the reader miss information they need to act? Mark the ones that survive that test.
2. Cut whole sentences before trimming words. Removing a redundant sentence saves more length, with less risk of losing meaning, than trying to shave words from every sentence.
3. Common categories to cut entirely: sentences that restate a point already made in different words; hedging phrases ("it is worth noting that," "we believe that," "in our opinion") that add no information; background the reader already has; and process narration ("first we looked at X, then we considered Y") when only the conclusion of that process matters.
4. Convert paragraphs to lists where the content is genuinely parallel (a set of options, a set of risks); a list of five short items reads faster than one paragraph saying the same five things in prose.
5. Tighten individual sentences last: replace multi-word phrases with single words ("in order to" to "to", "due to the fact that" to "because"), and cut adjectives and adverbs that don't change the meaning.

Worked example
Before (47 words): "It is worth noting that, due to the fact that the vendor contract renewal date is rapidly approaching, we believe that it would probably be a good idea for us to schedule a review meeting sometime in the next two weeks in order to discuss next steps."

After (17 words): "The vendor contract renews soon. Let's schedule a review meeting within two weeks to decide next steps."

That's a 64% cut (47 words to 17) on this one sentence, achieved by removing three hedges ("it is worth noting," "we believe," "probably") and one restated phrase ("in order to" to "to"), not by removing any fact.

Trade-offs and pitfalls

• The risk in aggressive cutting is losing a caveat or edge case that genuinely mattered; after cutting, reread once specifically asking "did I just delete a risk or exception, not just a restatement?"
• Cutting to a target percentage (half the length) as a goal in itself can tempt you to remove real content once the easy hedges are gone; if you run out of filler before you hit the target, the document may have been genuinely that dense, and the honest move is to say so rather than cut substance to hit a number.
• Lists are faster to scan but can flatten genuine nuance between items; use them for parallel content, not for things that need qualification relative to each other.

Approach

Use an array of buckets (a fixed-size list), where each bucket is itself a small list of (key, value) pairs. To find a key, hash it, reduce it modulo the number of buckets to pick a bucket index, then scan that one short list for a matching key (separate chaining: collisions are handled by letting multiple entries share one bucket, rather than probing elsewhere in the array). Track how full the table is (the load factor, live entries divided by bucket count) and double the bucket array once it crosses 0.75, redistributing every existing entry into the new, larger array so buckets stay short.

Code

class ChainingHashMap:
    def __init__(self, capacity=8):
        self._capacity = capacity
        self._size = 0
        self._buckets = [[] for _ in range(self._capacity)]

    def _index(self, key):
        return hash(key) % self._capacity

    def put(self, key, value):
        idx = self._index(key)
        bucket = self._buckets[idx]
        for i, (k, v) in enumerate(bucket):
            if k == key:
                bucket[i] = (key, value)   # update in place
                return
        bucket.append((key, value))
        self._size += 1
        if self._size / self._capacity > 0.75:
            self._resize()

    def get(self, key):
        idx = self._index(key)
        for k, v in self._buckets[idx]:
            if k == key:
                return v
        return None

    def remove(self, key):
        idx = self._index(key)
        bucket = self._buckets[idx]
        for i, (k, v) in enumerate(bucket):
            if k == key:
                del bucket[i]
                self._size -= 1
                return True
        return False

    def _resize(self):
        old_buckets = self._buckets
        self._capacity *= 2
        self._buckets = [[] for _ in range(self._capacity)]
        self._size = 0
        for bucket in old_buckets:
            for k, v in bucket:
                self.put(k, v)

    def __len__(self):
        return self._size


if __name__ == "__main__":
    m = ChainingHashMap(capacity=4)
    m.put("apple", 1)
    m.put("banana", 2)
    m.put("cherry", 3)
    print("get apple ->", m.get("apple"))
    print("get missing ->", m.get("no_such_key"))

    m.put("apple", 99)
    print("get apple after overwrite ->", m.get("apple"))

    removed = m.remove("banana")
    print("remove banana ->", removed, "| get banana after remove ->", m.get("banana"))

    for i in range(20):
        m.put(f"key{i}", i * 10)
    print("size after 20 more inserts ->", len(m))
    print("capacity after growth ->", m._capacity)
    all_correct = all(m.get(f"key{i}") == i * 10 for i in range(20))
    print("all 20 post-resize keys still correct ->", all_correct)
    print("cherry survived resize ->", m.get("cherry") == 3)
    print("get on never-inserted key returns None ->", m.get("zzz_absent") is None)

Output (executed as shown, capacity starts at 4):

get apple -> 1
get missing -> None
get apple after overwrite -> 99
remove banana -> True | get banana after remove -> None
size after 20 more inserts -> 22
capacity after growth -> 32
all 20 post-resize keys still correct -> True
cherry survived resize -> True
get on never-inserted key returns None -> True

Key points

• put on an existing key overwrites its value in place rather than appending a duplicate entry; that scan-then-overwrite check is what makes put idempotent for repeated keys.
• remove returns False for a key that was never present instead of raising, so callers can check the result rather than wrapping every call in a try/except.
• The resize walks the old buckets and calls self.put again for every surviving entry, which is what re-distributes entries across the new, larger bucket count (a key's bucket index depends on capacity, so it generally changes when capacity changes).
• hash(key) % self._capacity is only safe because the prompt guarantees hashable keys; a custom class used as a key would need a correct __hash__/__eq__ pair (equal objects must hash equally) for this to behave correctly.

Complexity

• Average case, all three operations: (O(1)). With a good hash function and a load factor kept under 0.75 by resizing, each bucket holds a small constant number of entries on average, so scanning one bucket is constant time.
• Worst case: (O(n)), if every key collides into the same bucket (a pathological or adversarial hash function), the table degrades to one long list and every operation becomes a linear scan.
• Resize: (O(n)) when it happens (copies every entry), but it happens only when size crosses a growing threshold, so the amortized cost added to any single put stays (O(1)) averaged over a sequence of inserts.

Edge cases

• Updating an existing key: handled by the in-bucket scan in put, which finds the match and overwrites rather than duplicating.
• Removing a key that is not present: returns False rather than raising, verified above (remove is only demonstrated on a present key here, but the loop structure is identical to get's not-found path, which the test above confirms returns None).
• Getting a key that was never inserted: returns None, confirmed by the final assertion in the demo.
• Two different keys landing in the same bucket: correctness still holds because the bucket scan compares full keys with ==, not just the bucket index; only performance degrades, not correctness.
• Resizing mid-lifecycle: the demo forces a resize (capacity grows from 4 to 32) and confirms every one of the 22 live keys, old and new, still resolves correctly afterward.

Direct answer

Compressing a three-month ramp into three weeks means deliberately not becoming broadly competent and instead becoming narrowly reliable on exactly what the project needs, while being explicit about what I'm skipping and how the resulting gap gets covered, whether that's a reviewer, a narrower scope, or stated uncertainty on anything I can't fully back. I would never let three weeks of learning quietly pass as equivalent to three months; the compression only works if everyone downstream knows what they're actually getting.

What compression actually means

Triage by what the project needs, not by the team's usual onboarding order. A normal three-month ramp typically builds broad familiarity before depth. With three weeks, I invert that: identify the two or three things this specific project actually requires me to be right about, and go deep only there, accepting shallow or absent knowledge everywhere else. If the timeline compressed further, to a single day, the triage gets sharper still: I would ask what one piece of context, if I got it wrong, would sink the project, and spend almost all the time there, explicitly skipping everything else rather than spreading thin.

Name the quality bars I refuse to drop even under compression. Compression is about learning less, not about shipping unverified work. I would still hold the same review and testing standards for anything I produce, even if the compressed ramp buys speed on learning but never on care.

Lean on other people's time, and be honest about the cost. The fastest lever available is borrowing a domain expert's attention instead of self-teaching everything from scratch, but that time is not free. I would be specific with the team about how much of someone's time I'm asking for and for how long, rather than letting it show up later as their own work quietly slipping.

Cover the gap with structure, not bravado. Where I know I'm still shallow, I build in a mandatory review step, narrow the scope of what I own until I catch up, or explicitly flag deliverables as carrying more uncertainty than the team's usual standard, rather than letting a compressed ramp quietly lower the bar without anyone deciding that on purpose.

Worked example

Joining a project three weeks before a launch, with the team's usual ramp closer to three months, I asked the lead directly what single area, if I got it wrong, would actually hurt the launch. The answer was one integration point with a partner system, so I deliberately left everything else about the surrounding codebase thin. I spent roughly half of the three weeks almost entirely on that integration, pairing daily with the engineer who owned it, which meant asking for about six hours a week of her time, made explicit up front rather than assumed. For the parts I stayed shallow on, I did not pretend otherwise: I flagged two areas in my own handoff notes as reviewed by me but not independently verified, and asked for an extra reviewer on anything touching them until I had more time. The launch shipped on schedule; the cost was that a change I made in one of the flagged areas weeks later took noticeably longer because I was still building real familiarity with it, a cost I had knowingly deferred rather than avoided.

Trade-offs and pitfalls

The core trade-off is depth for speed: three weeks buys narrow reliability, not the broad judgment three months would have given, and pretending otherwise is the real risk, not the compression itself. The most common pitfall is letting the compressed timeline quietly lower quality bars along with breadth, when only breadth should be sacrificed. A second pitfall is treating borrowed expert time as free; if it isn't planned and bounded, the person you leaned on absorbs the cost you didn't.

Brief flow (typical pattern)

• For each potentially occludable object, compute a conservative bounding box or bounding-sphere in view space.
• Issue a hardware occlusion query (draw the bounds into an occlusion-only pass: depth-only or color with color-mask off) to count samples/pixels that survive.
• Defer using that result until the query completes (usually next frame); meanwhile treat object as visible or use a cheaper fallback.
• When query result arrives, if zero visible samples -> skip full draw of that object; otherwise render normally.

Pitfalls

• GPU pipeline stalls: synchronously reading a query forces CPU/GPU sync, killing parallelism.
• Query latency: results are typically available a frame or more later — you get 1–3 frame lag in visibility decisions.
• False negatives / conservatism: tight bounds can miss visibility (false occluded) and cause popping; loose bounds reduce benefit.
• Work wasted issuing queries themselves (draw calls for bounds) and overhead for many small objects.

Mitigations / Best practices

• Never block: use asynchronous queries. Check availability and fallback to “visible” if not ready.
• Double-buffer / ring-buffer queries: issue query in frame N, use result in N+1 (or N+2) to avoid stalls; maintain multiple query slots per object.
• Coarse occluders & Hi-Z: render a few large occluders to a Hi-Z map and perform cheap software/compute tests (screen-space bounding-box vs Hi-Z) to cull many objects without queries.
• Use conservative bounds: slightly inflate AABB to avoid popping; or use screen-space conservative rasterization to reduce false negatives.
• Batch bounds draws and use depth-only passes with depth pre-pass to leverage early-z and keep query draws cheap.
• Thresholding: ignore occlusion for very small or distant objects (cost > benefit).
• Hybrid: combine CPU frustum/portal culling + coarse software occlusion for many objects, reserve HW queries for big, expensive-to-draw objects.

Example: for large props/NPCs, issue bbox queries on frame N, use ring-buffered results on N+1, rely on Hi-Z for medium objects and CPU frustum for small ones — this balances latency, avoids stalls, and maximizes savings.