Mid-Level Game Developer Interview Preparation Guide (FAANG Standards)

Direct answer

Mark a node visited when it is POPPED (actually processed), not when it is pushed. Marking on pop is what reliably reproduces the exact visiting order of recursive DFS on a general graph; marking on push, a common shortcut, bounds the stack to one entry per node but can silently produce a DIFFERENT visiting order than recursion whenever a node is reachable from the current frontier by more than one edge, which is common on any graph that is not a tree.

Structured elaboration

Why "mark on push" seems right but is not equivalent to recursion. In recursive DFS, when node P is being processed and discovers neighbor X, the recursion immediately dives into X before P finishes examining its remaining neighbors. So X's position in the ordering is locked in the instant it is first discovered, by whichever call is active at that instant. An iterative version that marks visited at push time tries to mimic this by claiming X the moment it is pushed, but pushing does not immediately process X: X sits in the stack, possibly under other nodes pushed afterward by a DIFFERENT parent that reaches X through another edge before X is actually popped. Because X was already marked visited at push time, that second parent's attempt to reach X is silently skipped, which is correct for avoiding duplicates, but the resulting pop-time ORDER of the surrounding nodes can end up different from what recursion would have produced, since recursion never has this "claimed but not yet visited" state.

Why "mark on pop" fixes this. Marking only at pop time means a node's position in the true DFS order is decided at the moment it is actually processed, exactly mirroring what recursion's call-order does. The cost is that the same node can be pushed onto the stack more than once (once per edge that reaches it before it is first popped); the algorithm handles this by checking if node in visited: continue immediately after popping, silently discarding stale duplicate entries.

Worked example

def recursive_dfs(graph, start):
    visited, order = set(), []
    def visit(node):
        if node in visited:
            return
        visited.add(node)
        order.append(node)
        for nbr in graph.get(node, []):
            visit(nbr)
    visit(start)
    return order

def iterative_dfs_mark_on_pop(graph, start):
    '''Mark visited when POPPED (actually processed). Matches recursive DFS order
    exactly, at the cost of a node possibly sitting in the stack more than once
    before it is first popped.'''
    visited, order, stack = set(), [], [start]
    while stack:
        node = stack.pop()
        if node in visited:
            continue
        visited.add(node)
        order.append(node)
        for nbr in reversed(graph.get(node, [])):
            if nbr not in visited:
                stack.append(nbr)
    return order

def iterative_dfs_mark_on_push(graph, start):
    '''Mark visited when PUSHED. Bounds the stack to at most one entry per node,
    but the resulting order can diverge from recursive DFS whenever a node is
    reachable from the current frontier by more than one edge.'''
    visited, order, stack = {start}, [], [start]
    while stack:
        node = stack.pop()
        order.append(node)
        for nbr in reversed(graph.get(node, [])):
            if nbr not in visited:
                visited.add(nbr)
                stack.append(nbr)
    return order

if __name__ == "__main__":
    # A chain where node i has edges to i+1 and i+2 (0..7), closing with a cycle 9->0.
    # Every node here has two distinct parents competing to discover its later
    # neighbors, which is exactly the shape that breaks mark-on-push.
    graph = {i: [i + 1, i + 2] for i in range(8)}
    graph[8] = [9]
    graph[9] = [0]

    rec = recursive_dfs(graph, 0)
    pop_order = iterative_dfs_mark_on_pop(graph, 0)
    push_order = iterative_dfs_mark_on_push(graph, 0)

    print("recursive DFS order:        ", rec)
    print("iterative, mark-on-pop:     ", pop_order)
    print("iterative, mark-on-push:    ", push_order)
    print("mark-on-pop matches recursive order:  ", pop_order == rec)
    print("mark-on-push matches recursive order: ", push_order == rec)

Output (actually executed with python3):

recursive DFS order:         [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
iterative, mark-on-pop:      [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
iterative, mark-on-push:     [0, 1, 3, 4, 6, 7, 9, 8, 5, 2]
mark-on-pop matches recursive order:   True
mark-on-push matches recursive order:  False

A stress test over 200 randomly generated connected graphs (seeded with random.seed(42), reused across reruns so the count below is reproducible, not a one-off) confirms this at scale:

import random

def random_graph(n, extra_edges, seed):
    '''Connected random digraph: a random spanning structure (each later node gets
    one edge from an earlier node) plus extra_edges random additional edges, which
    is what creates the multiple-parents-racing-for-the-same-child situation that
    breaks mark-on-push.'''
    rnd = random.Random(seed)
    graph = {i: [] for i in range(n)}
    order_nodes = list(range(n))
    rnd.shuffle(order_nodes)
    for idx in range(1, n):
        u = order_nodes[idx]
        v = rnd.choice(order_nodes[:idx])
        graph[v].append(u)
    for _ in range(extra_edges):
        u, v = rnd.sample(range(n), 2)
        if v not in graph[u]:
            graph[u].append(v)
    return graph

random.seed(42)
mismatches = 0
N = 200
for i in range(N):
    n = random.randint(6, 15)
    extra = random.randint(2, 10)
    g = random_graph(n, extra, seed=1000 + i)
    rec = recursive_dfs(g, 0)
    pop_o = iterative_dfs_mark_on_pop(g, 0)
    push_o = iterative_dfs_mark_on_push(g, 0)
    assert pop_o == rec, f"mark-on-pop diverged on graph {i} (should never happen)"
    if push_o != rec:
        mismatches += 1

print(f"mark-on-pop matched recursive in all {N}/{N} cases")
print(f"mark-on-push diverged in {mismatches}/{N} cases ({100*mismatches/N:.1f}%)")

Output (actually executed with python3, same seed reproduces this exactly):

mark-on-pop matched recursive in all 200/200 cases
mark-on-push diverged in 42/200 cases (21.0%)

mark-on-pop matched recursive order in all 200 cases, as the argument above guarantees. Mark-on-push diverged in 42 of 200 (21.0%), roughly 1 in 5 for this graph shape, confirming the divergence is not a property of one contrived example. (An earlier draft of this answer asserted a stress test result, 24 of 200 or 12%, without shipping the code that produced it; re-running an actual seeded test shows both that figure and that direction of rounding were wrong, so the number here is the one to trust and reproduce.)

Complexity

• Both variants: time $O(V + E)$; mark-on-pop can push a node once per incoming edge from the currently-reachable frontier before it is first popped, so the stack can briefly hold up to $O(E)$ entries in the worst case (still linear in graph size), whereas mark-on-push holds at most $O(V)$ entries since each node is pushed exactly once.

Edge cases

• Disconnected graphs: only the component reachable from start is visited, matching recursive DFS's own behavior.
• Self-loops: nbr == node is naturally excluded once node is in visited after being popped.
• A node with no listed neighbors: graph.get(node, []) returns an empty list, no error.

Trade-offs and pitfalls

• If exact recursive-order fidelity does not matter for your use case (many applications only need "some valid DFS order" or "the reachable set," not the specific sequence), mark-on-push is a legitimate, slightly more memory-efficient choice; the two variants always discover the same SET of nodes and the same set of tree edges, they can just differ in the exact sequence.
• This question asks specifically for order-fidelity ("the produced visiting order matches recursive DFS"), which makes mark-on-pop the correct answer, not a stylistic preference.
• Common mistake, and the one this question is designed to probe: assuming "mark on push" is obviously correct because it prevents duplicate stack entries, without checking whether it preserves the actual traversal ORDER a recursive implementation would produce; the two properties (no duplicates, order fidelity) are not the same guarantee, and the stress test above shows they diverge on roughly 1 in 5 random graphs with the tested shape.

High-level difference
AABB: axis-aligned box (stored as min/max in world or local axis). Very cheap to test but doesn’t rotate with objects.
OBB: oriented box (center, half-extents, orientation/rotation matrix or quaternion). Rotates with object and fits geometry tighter, but tests are heavier.

Memory cost

• AABB: 2 Vec3 (min/max) or center+extents = small.
• OBB: center + 3 extents + rotation (3x3 matrix or quaternion) = slightly larger (one extra quaternion/matrix).

Transform & rotation

• AABB: simple to translate; rotation requires recomputing world AABB from local shape (expand extents).
• OBB: stores orientation so rotations are cheap (apply quaternion), no conservative expansion needed.

Overlap test cost

• AABB vs AABB: very fast (component-wise min/max).
• OBB vs OBB: uses separating axis theorem with ~15 axes, more math and branches — higher CPU per test.
• OBB vs AABB or OBB vs sphere: intermediate.

Typical use-cases

• Dynamic players: OBB if you need tight fit and accurate rotation-based collision (e.g., character leaning); otherwise AABB with swept tests for simpler physics.
• Static level geometry: AABB (or axis-aligned BVH) for broadphase spatial partitioning; store OBBs for oriented static props if necessary.
• Fast projectiles: AABB or swept AABB/segment tests (raycasts) — use minimal checks and continuous collision to avoid tunneling; OBB usually overkill.

Platform choice

• Mobile: prefer AABB/broadphase + narrow-phase with simpler shapes; minimize OBBs to reduce CPU and memory.
• Console/PC: can afford more OBBs for tighter collisions and better gameplay feel, especially for player characters and important dynamic objects.

Choose AABB for speed/simple broadphase and memory-sensitive contexts; choose OBB when rotation fidelity and tight fitting reduce false positives and justify extra CPU.

Direct answer

Owning a miss means surfacing it myself before anyone else has to point it out, naming the actual root cause even when part of it sits outside my direct control, and bringing a concrete corrective plan in the same conversation where I admit the shortfall, not a separate one later. The prevention step afterward is what separates genuinely owning a miss from just apologizing for it.

Structured elaboration

The sequence I follow is the same regardless of what specifically got missed, a deadline, a budget, an adoption number, or a quality bar: catch the shortfall through my own tracking rather than waiting to be told, report it proactively with a first-pass explanation and a plan already attached, then do a real root-cause pass rather than settling for the first explanation that comes to mind. The ownership discipline is specifically in how I frame the cause: I name what was actually within my control to have caught earlier, even if the proximate technical or operational constraint belonged to someone else, instead of routing the story toward whichever team is easiest to point at. From there, the corrective steps need a real revised commitment, not a vague "working on it," and the prevention change afterward has to generalize to the class of mistake, not just patch this one instance.

Worked example

Situation: I owned a quarterly initiative to cut checkout latency, committed to leadership as a 30% reduction in p95 (95th percentile) load time, from 800 milliseconds to 560 milliseconds, by the end of the quarter.

Task: deliver that reduction on the committed date.

Action: I found out we were behind through my own mid-quarter metrics review, three weeks before the deadline, not from anyone flagging it to me. At that point the actual reduction was tracking to about half the committed target. I reported the shortfall to leadership the same week I found it, before being asked, and framed it as my initiative being behind schedule with a first-pass reason and next steps already attached, rather than waiting for a status meeting to surface it. The root-cause work showed that our original estimate hadn't accounted for a downstream payment-gateway call that turned out not to be optimizable the way we'd assumed. The real gap wasn't the gateway team's fault; it was that I hadn't validated during initial scoping whether that call's latency was actually tunable, and I said so directly rather than describing it as a dependency problem. The corrective step was adding a caching layer in front of that gateway call to claw back most of the remaining gap, and I asked leadership for three additional weeks with a specific revised number attached, not an open-ended extension.

Result: at the three-weeks-before-deadline check, checkout latency stood at 680 milliseconds, a 15% reduction, half of the committed 30%. After the additional three weeks of corrective work, it reached 570 milliseconds, roughly a 28.75% reduction, close to the original target though three weeks later than committed. Afterward, I added a mandatory dependency-tunability validation step to the estimation template used for any future latency-reduction initiative, so an unverified assumption about whether a downstream call can actually be optimized gets caught during scoping rather than discovered mid-quarter, and I started doing a formal check-in at the halfway point of every quarterly initiative rather than relying on a single review near the end.

Trade-offs and pitfalls

• Reporting a miss before being asked protects trust, but only if it arrives with a credible root cause and a real corrective plan attached; a proactive admission without a plan is just an earlier apology, not ownership.
• It's tempting to frame the cause around the team whose system couldn't be optimized as expected; the actual ownership move is naming that verifying feasibility with that dependency during scoping was mine to have done, even though the technical constraint itself sat elsewhere.
• Asking for more time only stays honest if the revised number and date are specific; a vague "we'll get there soon" undermines the same trust the proactive disclosure was meant to protect.
• A prevention change that only addresses this exact scenario (this one gateway call) isn't real prevention; the estimation-template change and the halfway check-in both target the general class of problem, an unvalidated dependency assumption and a lagging-trend detected too late, not just this one incident.

Clarify goals & constraints

• Move an authoritative match instance mid-game to a closer region with <200–500 ms downtime, no state divergence, and safe rollback if target fails.

High-level flow

1. Quiesce non-critical actions; keep accepting player inputs.
2. Snapshot authoritative deterministic state + RNG seed + tick counter.
3. Transfer snapshot + unprocessed input buffer (or input-forwarding stream).
4. Start target in catch-up mode, run deterministic replay to current tick.
5. Swap traffic with synchronized clocks and state handshake; confirm, then retire source.

State serialization

• Serialize compact binary: game tick, deterministic RNG seeds, entity snapshot diffs (component masks), authoritative components only. Use protobuf/FlatBuffers or custom packed format for speed and versioning.
• Send incremental delta first (last known state) then full if mismatch.

Input handling

• Two options:
  • Transfer unprocessed input buffers (ordered, timestamped) so target can deterministically replay to current tick.
  • Or keep source proxying/forwarding live inputs to target during catch-up; forward acknowledgement when ready.
• Inputs must be idempotent and include player sequence numbers.

Clock sync

• Sync tick counters; use protocol similar to NTP but bounded by game tick resolution. Exchange last-processed tick and measured RTT; target applies simulated latency compensation and runs deterministic ticks until matching source tick.

Minimize downtime

• Start catch-up on target using fast-forwarded deterministic ticks at higher CPU allocation (no rendering) until only few ticks behind; then perform a single “lock-and-swap” window of 1–3 ticks where inputs are paused briefly (<1 tick if possible) and traffic is redirected.

Rollback / failback

• Keep source alive in standby with snapshot checkpoint and input log until target acknowledges acceptance.
• If target fails during catch-up or swap, abort and resume authoritative on source; replay buffered inputs to avoid loss.
• If swap completes but clients detect issues, allow atomic rollback: instruct clients to reconnect to source, which replays inputs from shared log to reach same state; use versioned snapshot IDs to ensure consistency.

Reliability & optimizations

• Transfer via reliable ordered transport (QUIC/TCP) with compression and checksums.
• Prioritize critical state (player positions, health, authoritative timers) first.
• Use hash-based verification of snapshot after transfer.
• Monitor metrics (catch-up time, RTT, tick drift) and only migrate if benefit > cost.

This design balances deterministic replay, low downtime, and safety using input logs, compact authoritative serialization, clock/tick synchronization, and explicit rollback paths.

Definition

Fixed-point representation stores a real number as an integer scaled by an implicit, fixed factor, multiply the real value by 2^n and store the integer result, instead of floating point, which stores a separate exponent so the decimal point can "float."

Why embedded developers use it

Most small MCUs (microcontroller units, the chip running this firmware), especially Cortex-M0/M0+ class and many low-cost 8/16-bit parts, have no hardware FPU (floating-point unit). Floating-point operations there are emulated in software, costing many times more CPU cycles and code (flash) size than an equivalent integer operation. Even on MCUs with an FPU, fixed-point can still win where bit-exact, deterministic results matter, since float rounding behavior can subtly differ across compilers and optimization levels.

Representation, scaling, rounding, overflow

• Representation: a Qm.n format packs m integer bits and n fractional bits into a normal integer type. Q8.8 stores a 16-bit signed value where the low 8 bits represent the fraction, so real value = raw integer / 2^n.
• Scaling: converting to fixed-point is raw = round(value * 2^n); converting back is value = raw / 2^n.
• Multiplication needs rescaling: multiplying two Qn numbers produces a raw product with 2n fractional bits, so you must shift right by n afterward to get back to the original format, and the intermediate product typically needs a wider type (int32 for two int16 Q8.8 operands) to avoid overflow before the shift.
• Rounding: truncating by shifting always rounds toward zero or negative infinity rather than to nearest, a bias that accumulates over many operations. Adding a rounding constant before the shift, (product + (1 << (n-1))) >> n, rounds to nearest instead.
• Overflow: the representable magnitude and precision are both hard limits fixed at compile time, unlike float, which trades precision for range dynamically. An intermediate product that overflows wraps around silently, with no exception, unlike a float overflowing to infinity, which is at least detectable.

Worked example

$\text{raw\_product} = \left\lfloor \frac{a_{raw} \cdot b_{raw}}{2^{n}} \right\rfloor$

Intuition: multiplying two scaled integers doubles the scale factor, so you divide back out by 2^n to land back in the original Qn format. In C this division by a power of two is written as a right shift, (a_raw * b_raw) >> n, one instruction instead of a real divide.

Using Q8.8 (scale factor 256): 3.5 encodes as round(3.5256) = 896, and 2.25 encodes as round(2.25256) = 576. Their raw product is 896576 = 516096 (needs a 32-bit intermediate, it doesn't fit in 16 bits). Rescaling: 516096 >> 8 = 2016. Decoding: 2016/256 = 7.875, matching the true product 3.52.25 = 7.875.

Where it clearly wins

That multiply, on an FPU-less MCU, is one 16x16-to-32 integer multiply and one shift, a handful of cycles. The floating-point equivalent on that same core is typically a software-emulated library call costing many times more cycles and considerably more flash space. For a control loop running at a fixed tick rate, say a PID controller (a common feedback-control loop that continuously corrects toward a target value) ticking every 1 ms, that emulation cost can be the difference between meeting the deadline and missing it.

Reproduce systematically

• Run the build and Editor with the Unity Profiler attached (not Deep only — start with normal sampling). Capture a long trace (30–60s) so the ~5s spikes appear.
• Record Editor + standalone on target device (Android/iOS/PC). Use platform-specific tools (Android Systrace/Perfetto, Xcode Instruments) if device.
• Toggle Deep Profile and “Profile Editor” only after reproducing to avoid changing timings.

Track down allocation sources

• In the Profiler: inspect the “GC Alloc” column in CPU Usage; expand the frames during a spike to see which functions allocate.
• Use the Memory Profiler package to take snapshots before/after a spike and diff them to see new objects and managed heap growth.
• Enable “Detailed GC Allocations” (Deep Profiler or the Allocation Callstacks option) to get callstacks for allocations.
• For native-to-managed marshaling: look for calls into plugins or P/Invoke. Use Managed Call Stacks + Native Profiler or run with IL2CPP to reveal copies. Check for frequent marshaling of strings, arrays, or structs.
• For temporary arrays: search code for LINQ, string concatenation, .ToArray(), .Split(), .Select(), foreach over IEnumerable, Enumerable.Range, and boxing (boxing shows as allocations).
• Use Roslyn/IDE analyzers or Rider/Visual Studio Code inspections for allocations (e.g., Rider’s Unity inspections).

Short-term mitigations

• Pool: implement object pools and reuse frequently created objects (gameplay bullets, UI elements, temporary lists).
• Use ArrayPool<T> for transient arrays and System.Buffers to rent/return.
• Replace allocations from LINQ/anonymous closures with for-loops and preallocated buffers.
• Enable incremental GC or the new “Incremental GC” / “GC.Collect” tuning in Project Settings to smooth spikes while you fix root causes.
• Temporarily throttle nonessential systems to reduce allocation frequency.

Example pool snippet:

// C# example using ArrayPool
using System.Buffers;
int[] arr = ArrayPool<int>.Shared.Rent(256);
try {
  // use arr[0..len]
} finally {
  ArrayPool<int>.Shared.Return(arr);
}

Long-term fixes and architecture

• API changes: prefer NativeArray/NativeSlice, Jobs + Burst for heavy per-frame work to avoid managed allocations; use Span<T>/Memory<T> where applicable.
• Replace P/Invoke marshaling with pinned buffers or pre-allocated native memory (GCHandle.Alloc(pinned) or NativeArray passed to native code) to avoid per-call copies.
• Convert builds to IL2CPP for release: it reduces managed GC overhead in some cases and exposes different allocation profiles (but still avoid allocations).
• Adopt allocation auditing in CI: run profiler traces on a headless automated run, fail on per-frame allocation thresholds.
• Implement coding guidelines (no per-frame allocations, avoid string.Format every frame, no LINQ in hot paths). Add analyzer rules.

Verification

• Re-run the same long trace in Profiler and show GC spikes eliminated or reduced; compare frame-time histograms and CPU > GC usage.
• Use memory snapshot diffs to show no net growth across spikes.
• Run device traces and validate smoothness under representative gameplay scenarios.
• Add unit/integration tests that run hot loops and assert zero GC allocations (using UnityEngine.Profiling.Profiler.GetMonoUsedSizeLong or custom allocation counters).

Trade-offs

• Pools add complexity and possible memory overhead; pinned buffers can fragment native memory. Use telemetry to balance.
• IL2CPP changes behavior; validate across platforms.

This systematic approach isolates the allocation source, applies immediate mitigations, implements safer APIs/architectures, and verifies with measurable profiler evidence.

Approach overview
I treat VFX as a per-frame budget slice of total frame time. First compute frame budget (1000ms / refresh rate), reserve for core systems (game logic, rendering, post), then split remaining between CPU and GPU VFX.

Numeric targets

• Mobile (60fps → 16.67ms): reserve 6ms total VFX
  • CPU VFX: 2ms, GPU VFX: 4ms
  • Draw calls: <= 40 active draw calls for VFX
• Console (60fps → 16.67ms): reserve 8–9ms VFX
  • CPU: 3ms, GPU: 5–6ms
  • Draw calls: <= 80
• High-end PC (144fps → 6.94ms): reserve 2–3ms VFX
  • CPU: 0.8–1ms, GPU: 1.2–2ms
  • Draw calls: <= 120 (but favor GPU particles / instancing)

Targets assume batching/instancing, GPU particles where available.

Runtime enforcement

• Central “VFX budget manager” that tracks per-frame ms (profiling timers) and draw-call tokens; VFX systems request tokens and the manager accepts/rejects.
• Telemetry + rolling-average frame cost; if budget exceeded, trigger fallbacks next frame.

Fallback strategies

• LOD: reduce particle count, lower simulation frequency, switch to cheaper billboard textures or impostors.
• Emission culling: stop spawning when offscreen or occluded; distance-based emission caps.
• Texture mip/quality: force smaller mip levels or shared atlases on mobile; reduce shader complexity or remove additive passes.
• CPU->GPU migration: shift simulated particles to GPU/compute on capable platforms.
• Graceful degrade sequence: 1) reduce emission, 2) lower lifetime/size, 3) reduce shader complexity, 4) disable nonessential VFX.

These policies are parameterized per platform and tuned with profiling to hit targets while preserving visual fidelity.

Direct answer

Teaching a skill you don't have natural talent for means separating what you know intuitively from what's actually teachable. You diagnose the real gap first, build an explicit, decomposed framework for the skill (even though you perform it by feel), and validate progress by watching the person apply it independently, not by how confident the coaching sessions felt.

Approach to teaching outside your natural strength

Diagnose before prescribing. "Struggles with X" is rarely one problem. Watch or review their actual attempt and separate the layers: is it a knowledge gap (they don't know the structure), a delivery gap (they know the structure but execution is shaky), or a confidence gap (they know it and can do it, but freeze under real stakes). Each needs a different intervention.

Decompose your own tacit skill into explicit steps. If you're good at something without having consciously learned it as a framework, you have to reverse-engineer your own process before you can teach it. Skipping this step and just saying "do what feels right" doesn't transfer anything.

Practice at graduated, increasing stakes. Start with low-stakes reps where mistakes are cheap and recoverable, then move toward the real, higher-stakes version. Jumping straight to the real thing conflates skill-building with performance evaluation in the person's head, which raises anxiety and slows learning.

Give feedback on the mechanism, not just the outcome. "That worked" or "that didn't work" is much less useful than pointing at which specific move in their approach caused the result.

Worked example

Situation: someone you're mentoring is excellent at the core technical work but has a real gap in a skill that doesn't come naturally to you either, say, communicating findings clearly to people outside the immediate team. Their material was always technically sound, but reviews ran long and the point often got lost.

Task: help them close that gap over a defined stretch, without pretending you have natural talent for it yourself.

Action: you watched a recording of one of their sessions together and separated content problems (no clear headline, too much detail up front) from delivery problems (pace, not anticipating pushback). You gave them a simple structure to practice against: state the conclusion first, then the supporting evidence, then the recommendation. You ran a couple of low-stakes rehearsals where you played a skeptical stakeholder, then let them run the real session solo.

Result: over a few sessions, their reviews needed fewer clarifying follow-up questions from the room, and the structure started showing up unprompted in written material too, not just live presentations. The real signal wasn't how the coaching sessions felt: it was watching them handle a session you weren't part of and hearing secondhand that it landed cleanly.

Trade-offs and pitfalls

A common junior-mentor mistake is trying to transfer your own tacit competence directly ("just do what I do") instead of decomposing it. That fails specifically because the skill you're teaching is one you never consciously learned as steps.

Another mistake: avoiding coaching on gaps you don't personally excel at, on the theory you're not qualified. You don't need to be naturally gifted at a skill to teach its structure. You need to be willing to build the explicit framework, which sometimes non-naturals do better than naturals, because they had to learn it deliberately themselves.

The real trade-off is time. Teaching a skill outside your own strength takes longer to prepare for, because you can't rely on instinct in the room. That prep time is where the actual coaching value gets built.

I would frame the discussion around user impact, risk, and reversibility. A workaround is a temporary fix that reduces pain now, while the root issue is the underlying cause we still need to solve. I would ask: how many users are affected, how severe is the problem, and how risky is the workaround itself?

If the workaround is low risk and reversible, I would lean toward shipping it now and scheduling the root fix immediately after. For example, if users are blocked by a broken validation rule and we can safely relax it, I would ship the workaround, monitor errors, and commit to the deeper fix in the next cycle. If the workaround could corrupt data or create a bigger support burden, I would slow down and fix the root issue first.

I would make the decision explicit, document the trade-off, and assign an owner for the follow-up fix. That way the team is not pretending the workaround is the final answer, and users get relief as soon as it is safe to do so.

Responsibilities — high level

• Game logic: implements rules, win/loss conditions, scoring, AI decisions, state machines, level progression, UI flow, scripted events, spawn logic, gameplay timers.
• Engine subsystems: provide low-level services—rendering (GPU draw calls, shader management), physics (collision detection, rigid-body integrator), input (raw device events), audio (mixing, playback), networking (packet send/receive, replication transport).

Concrete examples

• Game logic: “if player.health ≤ 0 then trigger game over”, enemy AI choose target and path via behavior tree, combo/stamina systems, turn-based rules, match-making decisions.
• Engine: broadphase collision queries, contact resolution, GPU draw command submission, audio DSP, UDP/TCP socket layer.

Interface boundaries

• Use clear APIs: engine exposes services (Physics.Scene.Raycast(), Renderer.SubmitMesh(), Network.SendReliable()) while game logic calls them and owns higher-level state (GameState.ApplyDamage()).
• Data contracts: immutable event structs, deterministic fixed-timestep update for gameplay; separate authoritative simulation from rendering.

Why separation helps

• Testability: game logic can be unit-tested with mocked engine interfaces; fast deterministic tests using simulated physics responses.
• Maintainability: clear ownership reduces coupling; artists/engineers can iterate independently.
• Determinism: isolating authoritative simulation (fixed timestep, no non-deterministic engine side effects) yields reproducible replays and easier debugging.