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.

Approach summary
Design a hybrid, server-side rate limiter using token-bucket for bursty actions (ability casts, chat bursts) and leaky-bucket for steady drains (continuous chat spam). Keep most logic server-side to avoid client tampering; publish client-side cooldown hints only.

Token-bucket vs Leaky-bucket

• Token-bucket: allows bursts up to bucket size then refills at rate R — good for ability casts (players can spend stored tokens for permitted short bursts).
• Leaky-bucket: enforces steady outflow; ideal for chat where even pacing is desired to prevent continuous spam.
• Use token-bucket for gameplay actions where bursts are legitimate; wrap critical actions with short server-side cooldowns to match game design.

Scope of limits

• Per-user (by account ID): primary limiter for gameplay mechanics and chat; preserves fairness across shared IPs.
• Per-IP: secondary limiter to catch mass-bots or single-host floods; apply lower priority and aggregate counts.

Exemptions & tiers

• Privileged users (admins, verified players, paid customers): higher token bucket size or reduced penalty windows. Log and monitor exemptions; allow dynamic revocation.

Handling NAT / shared IPs

• Prefer per-account limits first. For IP-based enforcement:
  • Use adaptive thresholds: scale IP limits by active distinct account count from that IP (e.g., limit = base * sqrt(active_accounts)).
  • Apply soft throttles: delay low-priority actions (chat) instead of hard blocks; present backoff messages.
  • Employ progressive penalties and challenge (CAPTCHA/out-of-band verification) only when correlated abusive patterns appear across multiple accounts.

Implementation notes

• Store state in a low-latency store (in-memory Redis with TTL keys and atomic ops). Use Lua scripts or compare-and-set to avoid race conditions.
• Emit telemetry for tuning: counts, false-positive rates, top offenders.
• Test with load and simulated NAT clusters; provide clear client UX (cooldown timers, informative failures).

Trade-offs

• Strict IP limits reduce abuse quickly but risk false positives for NAT. Account-first logic minimizes that risk but cannot stop bot farms with many accounts — combine both with adaptive rules and human review.

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.

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.

Problem framing & goals
Measure rendering performance reproducibly across mobile devices to compare GPUs/SoCs and detect regressions in CI for a game engine or prototype scene.

Deterministic scene construction

• Build small, self-contained GL/Vulkan/Metal scenes inside the engine (Unity/Unreal) with parameterized content: fixed seed RNG, fixed animation clocks, no user input, locked camera transforms.
• Export scene configs (mesh counts, drawcall patterns, shader variants, particle counts) as JSON so runs are identical.
• Disable non-deterministic subsystems: async loading, dynamic LOD, physics randomness, network.

Eliminate external variance

• Enforce device state: airplane mode, lowest background services, fixed screen brightness, disable adaptive refresh.
• Thermal and battery control: pre-warm devices with a fixed burn-in profile; allow cool-down windows; use external thermal chambers in lab or track thermal throttle and discard runs when temps exceed threshold.
• Use clean OS images or device provisioning via MDM to stop background apps; run before-each-test cleanup scripts.

Trace collection

• Instrument engine to emit per-frame timestamps and GPU fence timings; collect:
  • frame times (render, update, script)
  • GPU frame/time, drawcall counts, memory usage
  • CPU per-thread samples (perf/ATRACE/Android systrace)
  • battery and thermal telemetry (BatteryManager / iOS APIs)
• Save traces as standardized artifacts (JSON + systrace + GPU counters).

Automation / device orchestration

• Local lab: ADB + fastboot scripts, run multiple devices in parallel via host orchestration.
• Enterprise: MDM for provisioning, remote device control, scheduled runs.
• Cloud: integrate cloud labs (Firebase Test Lab, Sauce Labs) for broad device coverage; ship scene APKs and config JSONs.
• Use a runner that:
  • pushes APK, sets device state, starts trace, runs scene for N frames, pulls artifacts, and reboots if needed.
• Handle flaky devices: retry policy, health checks.

CI integration & regression detection

• Ingest artifacts into pipeline: parse traces into metrics (P50/P90 frame, jank count, GPU utilization).
• Store historical baselines in a time-series DB and snapshots (per device model + scene).
• Define thresholds & statistical tests (e.g., median upward shift > X ms or 95% CI) to gate PRs.
• Provide dashboard with per-device diff, flamegraphs, and raw artifacts; on regression fail, attach traces to PR for triage.
• Add scheduled nightly full-suite runs and lightweight PR smoke tests (target a representative device subset).

Trade-offs

• Lab vs cloud: lab gives thermal control and deeper counters; cloud gives breadth. Combine both.
• Determinism vs realism: synthetic deterministic scenes isolate regressions; also include “real gameplay” traces for end-user impact.

This harness gives game teams reliable, automated, and actionable performance regression detection across mobile devices.

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.

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.