Apple Staff Game Developer Interview Preparation Guide

Clarify goal & constraints

• Server is authoritative; client may perform local cosmetic "undo" for immediate UX. Undo should feel instant for the player but must not violate game rules or other players’ views.

Semantics

• Local undo = client-side visual reversal only (no game-state mutation) with a short provisional window (e.g., 1–3s).
• If the action hasn’t been acknowledged by server, client sends a cancel request; server may accept/reject.
• If server already accepted and propagated, undo is blocked server-side; client must reconcile.

Conflict resolution flow

1. Player triggers local undo → apply immediate cosmetic rollback and mark action as “provisional-undo” with timestamp and reason.
2. Client sends CancelAttempt(message id, timestamp) to server.
3. Server checks authoritative timeline:
   • If action still reversible (not consumed by other game effects), server responds AcceptCancel; broadcasts reversal to all clients.
   • Otherwise Respond RejectCancel with canonical state and optional compensating action (e.g., spawn refund item).
4. Client receives response:
   • Accept → keep cosmetic change; update local state authoritative flags.
   • Reject → play smooth reconciliation animation: fade/lerp from local view back to server state, show concise UX cue (“Undo unavailable — action already resolved”), apply any compensating feedback (sound, small reward).

UX strategies

• Make provisional undo visually distinct (ghosted, subtle highlight) so player subconsciously expects potential revert.
• Use short undo window and latency-aware timers; show countdown if appropriate.
• Use graceful transitions (animations) rather than snapping to avoid jarring corrections.
• Offer compensations or soft heuristics (e.g., partial refund) when server rejects to reduce frustration.

Example

• Player places a trap and immediately presses undo. Client hides trap (ghost), sends CancelAttempt. If server hadn’t processed placement, it removes trap globally. If server already propagated and another player disarmed it, server rejects; client animates trap reappearing with a short tooltip and gives player a small resource refund.

Trade-offs

• Longer provisional windows increase UX friendliness but raise chances of server conflict.
• Too aggressive cosmetic changes risk confusing other players; visual distinction and clear messaging balance trust and responsiveness.

This approach preserves server authority while maximizing perceived responsiveness through provisional local UX, deterministic reconciliation, and clear user feedback.

Direct answer

Do not treat the metric win and the UX risk as opposing bets. Before building anything, agree with design and product on the primary success metric and on explicit guardrail metrics chosen specifically to catch the kind of harm the primary metric would not see, then validate cheaply with a prototype or a small qualitative test before committing to a live experiment sized to detect both.

Structured elaboration

Agree on what "good" means before anyone builds

The primary metric, say a conversion or engagement number, tells you if the change works on its own terms. Guardrail metrics are chosen specifically because they would catch harm the primary metric is blind to, such as task completion, return usage a week later, or support-ticket volume. Naming guardrails upfront, with agreed thresholds, prevents "we'll know it if we see it" arguments after the fact.

Validate cheaply before going live

A clickable prototype or a small moderated usability session can surface confusion or trust issues that the metric alone cannot catch, at a fraction of the cost of a live experiment. This is not a substitute for the experiment, it is a cheap filter that catches the worst ideas before they reach real users.

Run a bounded experiment, not a full rollout

Start with a small slice of traffic, watch both the primary metric and the guardrails, and decide the stopping rule, meaning what result on which metric ends the test, before the test starts, not after you see the numbers.

Decide and communicate together

If the primary metric improves but a guardrail moves the wrong way, that is a real finding, not a technicality to explain away. Whether to ship, iterate, or drop the idea is a joint call between design, product, and whoever owns the guardrail metric, made against the thresholds agreed upfront.

Worked example

Design proposes reordering a list of recommended items to increase click-through rate. The concern is that users may have learned to expect a stable, predictable order, and reordering it could hurt their ability to quickly find what they are looking for on repeat visits, something click-through rate would not show because a user can click more and still be more frustrated.

Before building, the group agrees the primary metric is click-through rate, and the guardrails are task completion rate (did the user's search end in the outcome they were after) and a return-usage check at one week out. A moderated usability test with a handful of participants on a clickable prototype surfaces that new users find the reordered list fine, but a couple of returning participants mention it "looks different" and take longer to find what they normally click first. That is a signal, not a stop sign: the team ships the change to a small slice of traffic, watches both metrics for an agreed window, and only expands the rollout if task completion holds steady alongside the click-through gain.

Trade-offs and pitfalls

Over-instrumenting every change with a full guardrail suite slows teams down and trains people to skip the process for anything that feels small. Guardrails should be chosen deliberately for the specific risk in question, not applied as a blanket checklist.

The sharpest failure mode is agreeing on guardrails in principle but not on thresholds, so when a guardrail moves slightly, the debate about whether it is a real regression happens after the data is already in and someone has already committed emotionally to shipping. Fixing the threshold before the test removes that fight.

Strategy overview
Manage complexity with a layered approach: limit variants at authoring time, strip unused permutations at build, and provide runtime fallbacks. Target high-end with full features, mid-tier with reduced dynamic features, low-end with baked or simplified approaches.

Authoring & variant structure

• Organize features into orthogonal toggles (e.g., NORMALS, PARALLAX, SSR, MSAA) and group mutually exclusive options (e.g., FORWARD vs DEFERRED).
• Use multi-level shaders: Base shader core + small feature include files so combinations are explicit and testable.
• Prefer static keywords (shader_feature in Unity) for rare toggle sets; use dynamic branching for cheap boolean switches.

Compile-time stripping

• Maintain a whitelist of valid keyword combinations per platform and use build-time variant stripping (e.g., Unity’s ShaderVariantCollection and strip rules, or build scripts to exclude permutations).
• Limit multi_compile usage; replace with per-platform shader LODs and fallback shaders to reduce explosion.

Runtime fallbacks & quality tiers

• Implement Graphics Quality tiers with mappings:
  • High: full dynamic lighting, SSAO, SSR, high-res post-process
  • Medium: reduced shadow cascades, limited dynamic lights, cheaper SSAO
  • Low: baked lightmaps, single directional light, simplified BRDF, screen-space effects downsampled or disabled
• At runtime detect GPU capabilities (feature bits, GL/Metal limits) and select appropriate shader LOD, number of lights, and post-process chain.

Lighting & post-processing specifics

• Lighting: use forward-renderer with clustered/tiling for high-end; deferred or baked lighting for mid/low; fallback to one specular per-pixel or simple Blinn-Phong on low.
• Post-processing: chain with conditional passes; use lower resolution buffers, combine passes (tone map + color grading), or skip expensive effects (bloom, volumetrics) on mobile.

Testing & telemetry

• Automated build tests per tier, shader warm-up to avoid hitches.
• Collect runtime telemetry (frame time, shader compile failures) and adjust strip rules or add variants as needed.

This balances visual fidelity and performance while keeping shader compile times and binary size manageable.

Detecting contention — what I look for

• Open the engine/platform profiler (Unreal Insights, Unity Profiler, Linux perf/VTune) and inspect thread views:
  • Worker thread timelines: long solid blocks labeled “Waiting” or “Blocked”
  • CPU Sample view: hotspots inside mutex/lock APIs (std::mutex, CRITICAL_SECTION)
• Key metrics:
  • Thread wait time (total/avg per frame)
  • Mutex hold time (time spent inside lock)
  • Contention counters (number of failed lock attempts, wait counts)
  • Lock acquisition latency distribution and tail latency (99th percentile)
• Signs: increasing frame-time variance, many threads idle while one holds a lock, high spin-wait CPU usage

Strategies to reduce contention (game-focused)

• Reduce critical sections: move expensive work outside locks; prefer atomic reads for stats
• Sharding / stripe locks: partition shared state by entity ID or spatial cell so threads lock different shards
• Per-thread queues: each worker has its own job/command queue and only occasional steal; reduces shared queue lock frequency
• Lock-free structures: use lock-free ring buffers for audio/producer-consumer paths where ordering is simple
• Actor/command pattern: schedule all state mutations through single-threaded actor or command buffer applied on main thread to avoid coarse-grained locks
• Hybrid: combine small mutexes + read-mostly RW locks, measure after each change

Validation

• After changes re-measure wait time, hold time, and frame variance; target reduced 99th-percentile frame time and fewer blocking events per frame.

Direct answer

I score build vs. buy on total cost of ownership (the full multi-year cost, not just the sticker price), time-to-value, and strategic differentiation, and I treat "buy now with a build trigger later" as a real third option, not a temporary version of "buy." The framework holds for a game engine subsystem too, but the weights shift hard: real-time performance constraints and tight integration with the engine's core loop usually push toward build or a deep customization of a bought component, even when a backend service in the same situation would clearly say buy.

The framework

• Total cost of ownership: upfront build cost plus ongoing maintenance, versus subscription or license fees plus integration cost. Buy is rarely "free" after the sticker price; integration, data migration, and vendor management all cost real engineering time.
• Time-to-value: how fast each option gets you to a working, shippable state.
• Strategic differentiation: does this capability directly differentiate the product, or is it commodity infrastructure everyone needs. The more it's the former, the more building (and owning the roadmap) is worth paying for.
• Lock-in and exit cost: how hard is it to leave a vendor later, and does the vendor's roadmap risk diverging from what you need.

I put these into a simple weighted score so the trade-off is explicit rather than argued from vibes, rather than leaving each criterion as a separate, incomparable argument.

Worked example

Say a team is choosing between building an internal capability and buying a vendor product, with these inputs on a 0-10 scale (higher is better for that option):

$\text{Build} = 0.4(3) + 0.4(3) + 0.2(8) = 1.2 + 1.2 + 1.6 = 4.0$
$\text{Buy} = 0.4(7) + 0.4(9) + 0.2(3) = 2.8 + 3.6 + 0.6 = 7.0$

Buy wins on the initial score. I don't stop there, though: I set an explicit trigger for revisiting, for example if strategic differentiation is later assessed at 7 or higher and the cost gap closes within a defined payback window, that's the signal to build. That turns a one-time decision into a standing policy instead of a decision that quietly goes stale.

How the game engine case changes the answer

The same criteria apply, but two of them move a lot. Time-to-market for a bought subsystem often looks fast on paper but hides a large hidden integration cost: a third-party rendering, physics, or VFX tool has to slot into the engine's frame budget, asset pipeline, and existing tooling, and a mismatch there can cost more engineering time than building the narrower thing you actually need. Cost also shifts, since game middleware often comes with per-seat or per-title licensing and sometimes runtime royalties that compound with scale in a way a typical software as a service subscription doesn't. And lock-in is sharper: proprietary asset formats and pipeline dependencies from a bought tool can be more expensive to migrate away from than a backend vendor's API, because the whole content pipeline gets built around them. A team choosing between building or buying a VFX graph editor for its engine, for instance, is really weighing "commodity enough to trust a vendor's roadmap" against "core enough to the game's visual identity that owning it fully pays for itself," which is the strategic-differentiation axis doing more work than the cost axis.

Where this generalizes

The same weighted framework applies whether the thing under debate is an internal engineering tool, an analytics or observability stack, a feature store or model registry, or a database choice being decided mostly on service-level agreement guarantees versus cost. Two variants are worth naming explicitly because they flip the framework's direction: negotiating a multi-year exclusive vendor contract adds a lock-in cost that should be modeled explicitly as a negative weight on the buy side, not treated as a footnote; and open-sourcing an internal component you already built is the build-vs-buy question in reverse, where the "cost" is ongoing maintenance burden for external users and the "benefit" is community leverage and hiring signal, not revenue.

Trade-offs and pitfalls

• Scoring only the sticker price. The build side's maintenance cost and the buy side's integration and lock-in cost are usually the parts that get underestimated, not the headline numbers.
• Treating "buy" as permanent. Setting no revisit trigger means the decision never gets re-examined even after the strategic picture changes.
• Cutting corners to hit a deadline instead of making the trade-off explicit. Cutting automated test coverage to hit an eight-week deadline is a real build-vs-buy-adjacent trade-off (build fast and thin vs. build right and slower); naming it as a deliberate, documented trade-off is different from letting it happen by default.
• Applying a backend service's weights to a performance-critical or pipeline-integrated subsystem without re-deriving them. The framework is the same; the inputs are not, and skipping that re-derivation is how teams end up with a vendor tool wedged awkwardly into a frame budget it was never designed for.

Grooming, spike triggers, and spike deliverables are three separate decisions, and treating a spike as a substitute for a clarifying question that already has a known answer is the single most common mistake here.

Questions to ask in grooming. "What's the acceptance criteria, how will we know this is actually done?" surfaces a missing definition of done. "Is there a design or mock, or an existing pattern in the codebase we're extending?" surfaces a missing design. "Does this touch a system we don't fully understand yet, a third-party API, a legacy module, an unfamiliar data model?" surfaces a real technical unknown. "What's explicitly out of scope?" prevents scope from silently creeping in mid-build. "Does this depend on another team or story that isn't finished yet?" surfaces a sequencing risk before it becomes a blocked sprint.

When to recommend a spike, not just more grooming. A spike is warranted when the story can't be estimated within a reasonable confidence band because of a genuine unknown, specifically: the team's estimates disagree by an order of magnitude, for example someone says 2 days and someone says 3 weeks, or the story depends on an external system whose real behavior the team hasn't verified firsthand, or it requires touching unfamiliar legacy code with no test coverage. If none of those apply and the team simply hasn't discussed it yet, that's a grooming gap you close with a clarifying question to the PM or stakeholder who already knows the answer, not a spike; reaching for a spike here just delays getting an answer that was already available.

What a spike needs to produce for the story to become estimable and schedulable. A written answer to the specific unknown that triggered the spike, not a general write-up of everything explored. A rough order-of-magnitude estimate for the real story, with a stated confidence level. A list of any new sub-tasks or dependencies the spike uncovered. An explicit note that any code produced is throwaway, not production-ready, flagged as such so nobody accidentally ships it hardened but unreviewed. And if the spike itself runs out of its timebox without an answer, a predefined response: either re-timebox once with a narrower, more specific question, or escalate to the PM that the story likely needs to be broken down further rather than estimated as one unit.

Worked example. A story reads "add support for syncing calendar events from a partner's calendar API." Grooming questions surface that nobody on the team has used this particular partner API before, and its rate-limit and webhook behavior under a bulk sync is undocumented, a genuine unknown, with the team's estimate spread running from 3 days to 3 weeks. That spread is the trigger to recommend a 2-day spike. The spike's deliverable: confirmation that the API supports webhooks rather than requiring polling, a documented rate limit of 500 requests per hour, a revised estimate of 5 to 7 days at medium confidence, and a newly surfaced dependency, a webhook receiver endpoint the story hadn't originally scoped.

Approach summary
I’d pick the method based on target hardware and correctness budget: full, exact compositing (A-buffer / depth-peeling) for high-end PC/console when correctness matters; approximations (weighted blended) for mobile or many layers where performance trumps absolute correctness.

Depth-peeling

• What: Multi-pass rendering that peels layers by depth. Exact order-independent results.
• Memory/Perf: High GPU time — O(L) passes where L = layers (or until opaque). Heavy bandwidth and draw cost. Minimal extra memory beyond multiple render targets.
• Complexity: Moderate — needs multiple depth textures, synchronization; tricky for many transparent layers.
• Feasible on: High-end PC/console (for limited L). Not suitable for mobile or scenes with many overlaps.

Per-pixel linked-lists (A-buffer, LL-OIT)

• What: Fragment lists per pixel in GPU memory (SSBO/atomic alloc + head pointers), then sort/compose in a resolve pass. Exact (or with per-pixel limits).
• Memory/Perf: Memory scales with fragments (worst-case large). Random memory writes and atomics cost; sorting per-pixel adds work. Requires substantial VRAM and fast random access.
• Complexity: High — allocator, memory fragmentation handling, handling overflow.
• Feasible on: High-end PC and modern consoles (with DX11+/Vulkan). Marginal on mobile; some modern mobile GPUs support it but memory and atomics are expensive.

Weighted blended OIT (WBOIT)

• What: Single-pass approximate OIT using pre-multiplied alpha blending with accumulated weights and colors, then normalization. No sorting.
• Memory/Perf: Low memory, single-pass — excellent performance and bandwidth characteristics. Approximate color/alpha, can fail with high-frequency depth variation.
• Complexity: Low — easy to integrate into existing pipelines.
• Feasible on: All platforms — ideal for mobile and large-scale scenes where performance is critical.

Recommendation & trade-offs

• If exact correctness and many thin layers are required: A-buffer on PC/console.
• If a moderate number of layers and deterministic results: Depth-peeling but limit passes.
• For broad use, lowest cost: WBOIT — use for particles, foliage, or when slight inaccuracies are acceptable. Combine: use WBOIT generally and fall back to A-buffer/depth-peel for critical viewports or cinematic shots.

Direct answer

Both strategies handle two keys hashing to the same bucket, but they store the overflow differently. Separate chaining keeps a small list (or similar container) at each bucket, so a collision just means appending to that bucket's list; insert, lookup, and delete all cost $O(1)$ on average. Open addressing instead keeps every entry directly in the single backing array, and on a collision probes a deterministic sequence of other slots (linear probing tries the next slot each time; quadratic probing tries slots at increasing squared offsets) until it finds an empty one. This keeps memory compact and cache-friendly, but makes delete trickier: removing an entry by simply clearing its slot can break the probe chain for entries that were placed after it.

Structured elaboration

Insert, lookup, delete, side by side

Load factor and resizing

Load factor $\alpha = \dfrac{n}{m}$ (n entries, m slots) governs both strategies' health. Chaining degrades gracefully as $\alpha$ rises past 1, since the expected cost per lookup is $O(1 + \alpha)$: the average list length just grows linearly with $\alpha$. Open addressing degrades sharply as $\alpha$ approaches 1, since probe sequences get long and clusters grow, so implementations typically resize (allocate a bigger table, commonly doubling it, and rehash every entry) once $\alpha$ crosses a fixed threshold, often around 0.7 for open addressing, versus a looser threshold for chaining since it tolerates a higher load factor before performance visibly suffers.

Why quadratic probing exists

Linear probing (always try the next slot) causes primary clustering: once a run of occupied slots forms, it tends to grow, since anything hashing into that run has to probe past all of it. Quadratic probing spreads probe offsets out (offsets $0, 1, 4, 9, \ldots$ from the original hash) to reduce, though not eliminate, that clustering; the trade-off is that not every slot in the table is guaranteed reachable unless the table size and probing constants are chosen carefully.

Worked example

A table of size $m = 8$ with a resize threshold of $\alpha = 0.75$ triggers a resize once $n$ would exceed $0.75 \times 8 = 6$ entries, i.e., on the 7th insert. After doubling, the new table has $m = 16$ slots and the same threshold now allows up to $0.75 \times 16 = 12$ entries before the next resize. This is the same amortized (averaged over a sequence of operations) argument as a doubling dynamic array: the expensive full-table rehash happens rarely enough, relative to the cheap inserts between resizes, that insert stays $O(1)$ amortized even though a single insert that triggers a resize costs $O(n)$.

Trade-offs & pitfalls

• Chaining costs extra memory per entry for list-node overhead, but tolerates a high load factor and makes deletion simple; a poorly-distributed hash function can degrade one bucket to $O(k)$ for that bucket's $k$ entries (worst case $O(n)$ if everything collides), which some standard library implementations guard against by converting a sufficiently long chain into a balanced tree.
• Open addressing has excellent cache locality (everything contiguous in one array) and no per-entry pointer overhead, but needs a lower load factor to avoid probe-length blowup, and its deletions need tombstones, which themselves need periodic cleanup: enough accumulated tombstones can make a lookup scan nearly the whole table before it reaches a truly empty slot.
• The most common wrong turn on open addressing: deleting an entry by clearing its slot outright. That "empty" slot is exactly the signal that stops a probe search, so a lookup for a different key that was displaced past the deleted slot will wrongly conclude that key isn't present, even though it's still sitting further along the probe chain.

Direct answer
"Unclear requirements" is a real cause sometimes and a convenient explanation other times, so the first job is figuring out which, using evidence rather than taking the explanation at face value. Look at the pattern across several instances, not just the latest miss, separate estimation problems from execution problems from actual requirement gaps, then fix the specific mechanism, not the person's attitude.

Diagnose using the pattern, not the excuse

• Pull several recent examples, not just the most recent miss. Was the requirement genuinely ambiguous every time, or does "unclear requirements" get invoked even when the ticket had clear acceptance criteria? The former is a process problem; the latter is a signal something else is going on (confidence, avoidance, poor estimation).
• Look for where in the workflow it breaks down: did they ask clarifying questions before starting and get bad answers, or did they not ask and guess? Did the requirement change mid-task without being re-scoped? Did they commit to something they didn't actually understand, to avoid looking behind?

Separate the possible root causes

• Genuine ambiguity: the requirement really was underspecified and nobody caught it before work started.
• Estimation or planning gap: the requirement was clear but the person didn't break it down enough to notice the ambiguous parts until they hit them.
• Avoidance: asking clarifying questions feels risky (looks like not knowing), so they guess and then have a ready explanation when it goes wrong.
• Skill gap under a different name: they may not yet have the judgment to know what "clear enough to start" looks like.

Fix the mechanism that matches the cause

• Genuine ambiguity: introduce a lightweight definition-of-ready check before work starts, owned jointly, not something you police alone.
• Estimation or planning: practice breaking a ticket into sub-tasks together and flag the ambiguous piece explicitly before committing to a date.
• Avoidance: make asking clarifying questions cheap and normal, model it yourself, and separate "I don't know yet" from an evaluation of competence.
• Skill gap: pair on a couple of tickets so they see what "clear enough" actually looks like in practice, rather than being told about it abstractly.

Worked example
A mentee on a team I supported kept missing sprint commitments, and the stated reason was always some version of unclear requirements. Looking at the last four tickets together, not just the most recent one, a pattern showed up: on three of the four, the acceptance criteria were actually written clearly, but the mentee hadn't asked any clarifying questions before starting, then hit an edge case mid-task and treated the whole ticket as ambiguous from the start. On the fourth, the ticket genuinely was underspecified.

The fix wasn't "communicate more clearly" in the abstract. It was two things: a short pre-work check where we'd both look at a ticket before it was picked up and flag anything genuinely unclear (catching the real ambiguity case), and a habit of the mentee sending one clarifying question per ticket before starting, even a small one, to break the avoidance pattern. The signal it was working wasn't a single metric; it was that "unclear requirements" stopped being the explanation for misses, because the real ambiguity was being caught earlier and the avoidance pattern had a lower-stakes outlet.

Trade-offs and pitfalls

• Taking "unclear requirements" at face value every time lets a deeper issue (avoidance, skill gap) hide behind a plausible-sounding excuse indefinitely.
• Assuming it's never true is just as wrong; requirements genuinely are underspecified sometimes, and treating every instance as a character problem erodes trust.
• The fix has to match the actual cause. A definition-of-ready checklist won't help someone avoiding asking questions, and coaching someone to "just ask more" won't help if the requirements really were bad.

Approach (brief)
Compute normal impulse from relative velocity along contact normal including restitution, apply inverse masses (support invMass = 0 for static). Then compute tangential (friction) impulse using Coulomb: clamp tangential impulse magnitude ≤ frictionCoeff * normalImpulse. Update linear velocities only (no rotation given).

C# implementation

// posA, velA, invMassA, posB, velB, invMassB: Vector2, contactPoint, contactNormal: Vector2 (normalized)
// restitution: float [0,1], frictionCoeff: float >= 0
void ResolveCollision(
    ref Vector2 posA, ref Vector2 velA, float invMassA,
    ref Vector2 posB, ref Vector2 velB, float invMassB,
    Vector2 contactPoint, Vector2 contactNormal,
    float restitution, float frictionCoeff)
{
    // relative velocity
    Vector2 rv = velA - velB;
    float velAlongNormal = Vector2.Dot(rv, contactNormal);
    if (velAlongNormal > 0f) return; // separating

    // normal impulse scalar
    float invMassSum = invMassA + invMassB;
    if (invMassSum == 0f) return; // both static

    float j = -(1f + restitution) * velAlongNormal;
    j /= invMassSum;

    Vector2 impulseN = j * contactNormal;
    // apply normal impulse
    velA += impulseN * invMassA;
    velB -= impulseN * invMassB;

    // recompute relative velocity for tangential (friction)
    rv = velA - velB;
    Vector2 tangent = rv - Vector2.Dot(rv, contactNormal) * contactNormal;
    float tLen = tangent.Length();
    if (tLen > 1e-6f) tangent /= tLen;
    else tangent = new Vector2(0,0);

    float jt = -Vector2.Dot(rv, tangent);
    jt /= invMassSum;

    // Coulomb friction clamp
    float maxFriction = frictionCoeff * j;
    Vector2 frictionImpulse;
    if (Math.Abs(jt) <= maxFriction)
        frictionImpulse = jt * tangent; // static (stick)
    else
        frictionImpulse = -maxFriction * Math.Sign(jt) * tangent; // kinetic (slip)

    velA += frictionImpulse * invMassA;
    velB -= frictionImpulse * invMassB;
}

Notes, complexity, edge cases

• O(1) time and space.
• Handles static bodies via invMass = 0.
• Assumes no rotation; to include angular effects, incorporate r×n and inverse inertia.
• Ensure contactNormal is normalized and guard against very small tangents.