Junior Game Developer Interview Preparation Guide - FAANG Standards

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
Choose the channel based on how much the message needs to be searchable and precise (favor writing) versus how much it benefits from back-and-forth and tone (favor a live conversation), and independently, how permanent a record of it needs to be.

Structured elaboration

• Prefer writing something down when the content needs to be referenced later, when it affects people who weren't in the room, or when precision matters more than speed (a decision with real consequences, a technical spec).
• Prefer a live conversation when the topic is ambiguous, sensitive, or benefits from real-time clarification, or when writing it out first would take longer than just discussing it.
• A common pattern that works well: have the live conversation to work through ambiguity, then follow up in writing to create the durable record of what was decided.

Worked example
Deciding to delay a feature launch by two weeks: a quick chat message to inform close collaborators who need same-day awareness, followed by a short written decision memo (a few sentences: what changed, why, and the new date) that gets linked wherever the original launch date was tracked, so anyone checking that plan later sees the current, correct information rather than a stale date with no explanation.

Trade-offs and pitfalls

• Defaulting to chat for everything because it's fast can leave no durable record of decisions that later need to be reconstructed from memory.
• Defaulting to a formal memo for everything is slow and can feel like overkill for genuinely small updates, training people to skim or ignore them.
• The right choice also depends on the relationship and stakes, not just the content type: the same information might warrant a quick chat with a close collaborator and a more formal memo when the audience includes people who don't have the same context.

Direct answer

Separate the trait from your identity, "I do this," not "I am this kind of person," turn the feedback into one specific, observable behavior to change rather than a vague personality fix, and track the result through what other people start doing differently, not a self-reported feeling.

Structured elaboration

1. Processing the feedback. Interpersonal-style feedback lands harder than technical feedback because it can feel like a judgment of character rather than of output. The reframe that helps is translating it into a specific behavior, "I interrupt people mid-thought in meetings," not "I'm not a good listener," since behaviors are changeable and traits feel fixed and personal.
2. Choosing the concrete change. Pick one observable habit to change, not a general resolution. A rule you can self-check in the moment, "let people finish their sentence before I respond, count one beat of silence first," beats a vague intention to "communicate better."
3. Assessing the result honestly. Interpersonal change is genuinely hard to quantify, so the honest signal is behavioral and relational, not a number: being looped into a discussion earlier than before, a colleague raising a half-formed idea with you again without hesitation, the original feedback-giver mentioning unprompted that they noticed a difference.

Worked example

A skip-level review noted that I tended to jump in with a solution before people finished describing the problem, which read as dismissive even though I didn't mean it that way. I turned that into one concrete habit: in any discussion, let the other person finish their point fully, then pause a beat before responding, even if I already thought I knew the answer. The result wasn't a score, it was that a teammate who'd previously stopped bringing half-formed ideas to me started doing it again, and my manager mentioned in a later one-on-one, unprompted, that meetings with me felt less rushed.

Trade-offs and pitfalls

Reporting a precise, fabricated metric, like "my collaboration score went from 3 to 4.5," for something this qualitative is a red flag to an interviewer, not a strength; interpersonal change is real but rarely cleanly measurable, and claiming false precision undercuts credibility rather than adding to it. Treating the feedback as globally true about your whole personality, rather than true in specific contexts, tends to produce overcorrection, going silent in meetings instead of just pausing. And a change nobody else notices isn't actually demonstrated; the answer needs an external signal, even a small one, not just your own resolve.

Direct answer

Use precise verbs and name teammates' functional roles instead of defaulting to either all-"I" or all-"we." Say "I" for what you personally decided or built and can defend under a follow-up question, and "we" or a named teammate's role for what was genuinely a joint decision or someone else's work.

Structured elaboration

A simple test: for any sentence in your story, ask "could I be asked right now to explain the reasoning behind this, in detail?" If yes, "I" is honest. If the honest answer is "that was a group call" or "someone else decided that," use "we" or name who owned it. This test also protects you: it's exactly the boundary a good interviewer will probe.

Wording patterns:

• Full ownership: "I owned, led, designed, or decided X."
• Partial or joint ownership: "I drove X in collaboration with [role]," or "I contributed X, and [role] handled Y."
• Someone else's piece: "[teammate's role] owned Y; I built on top of it by doing Z."

Avoid two failure modes: blanket "we" for a story that was actually mostly your individual work (reads as evasive, and gives the interviewer nothing specific to evaluate you on), and blanket "I" for a team's work (collapses the moment a follow-up asks you to defend a decision you didn't actually make).

Worked example

"On a 4-person team shipping a new authentication flow, I say: 'I designed and implemented the retry and error-messaging logic, which was the piece causing most of the support tickets before the redesign. A teammate owned the new session service, and another owned the UI. The overall project cut authentication-related support tickets by about a third in the following month, and the piece I can speak to in detail is the retry logic, since that's what I built.' That sentence gives specific, defensible credit for my piece, names what the team did around it, and doesn't claim the whole outcome as solely mine."

Trade-offs and pitfalls

• If you can't name what your teammates specifically did, that's a sign you're either overclaiming your own role or you weren't paying attention, both read poorly.
• Watch for inconsistency between how you describe the project on a resume (often all-"I" bullets, a resume-format convention) and how you describe it verbally; verbally it should read as more nuanced.
• A follow-up asking you to defend a specific technical decision is the moment overstated "I" claims collapse; don't put anything in "I" language you can't defend at that level of detail.
• Undercrediting yourself is also a failure mode; don't hide a real individual contribution behind "we" out of excessive modesty. Interviewers are trying to evaluate you specifically.

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.

Approach (brief)
Use an order-maintenance balanced structure: a skip-list-like indexed doubly-linked list plus an auxiliary std::map from z to list of buckets. Each UI element stores a stable insertion key (64-bit space), a pointer into a doubly-linked list node, and a bucket iterator. Inserts/removes are O(log n) for bucket lookup, O(1) list ops. Reorders of single element adjust its key via neighbor averaging; when key space gets dense, relabel a local range (amortized).

1. Algorithm and C++ sketch

// Simplified: maintain ordered map<key, Element*>
// key: double or int64 fractional label for stability
struct Element {
  int id;
  double key; // ordering label
  // render data...
};

std::map<double, Element*> order; // ordered by key

// Insert between prevKey and nextKey
double make_key(double prev, double next) {
  double k = (prev + next) / 2.0;
  if (k == prev || k == next) relabel_local(prev, next);
  return k;
}
void insert_after(double prevKey, Element* e) {
  auto itNext = order.upper_bound(prevKey);
  double nextKey = (itNext==order.end()? prevKey+1.0 : itNext->first);
  e->key = make_key(prevKey, nextKey);
  order[e->key] = e;
}
void remove(Element* e) { order.erase(e->key); }
void change_z(Element* e, double newPosKeyAround) {
  // find target neighbors and reassign using make_key
}
// For render: iterate order in key-range and batch contiguous elements by material/state

2. Key concepts / reasoning

• Labels provide stable ordering without full sort.
• std::map gives log n finding neighbors; insertion/removal cheap.
• Local relabeling keeps amortized cost low; per-frame only iterate contiguous range for rendering.

3. Complexity

• Insert/remove: O(log n) map ops; key relabel occasional amortized O(k).
• Render iteration: O(n) but cheap pointer traversal; batching done during single pass.

4. Edge cases & alternatives

• Use integer labels (int64) to avoid FP issues; relabel when gap exhausted.
• Alternative: indexed skip list or order-statistics tree for rank queries; or binary indexed tree if z ranges are discrete.

Direct answer

When an urgent security issue and a sales-critical demo land the same day, the deciding factor is exposure, not who asked more forcefully: what could go wrong if the security issue waits, and what can still be preserved for the demo without touching the risky path. Usually both can be partially served: contain or fix the security issue first, and give sales something real to show that doesn't depend on the vulnerable code.

Structured elaboration

1. Triage both in parallel, fast

Read the security bulletin and the demo request together. Identify exactly which services, data, or endpoints the vulnerability touches, and exactly what the demo needs to show.

2. Weigh exposure, not urgency of the ask

A security issue usually carries broader exposure (any affected customer, potential data risk) than a single demo (one prospective deal). That asymmetry is normally the tiebreaker, but it should be checked rather than assumed: a demo that's the last step before a major renewal can occasionally weigh more than a low-severity, well-contained finding.

3. Look for a path that serves both

A scoped hotfix with a canary rollout (releasing the fix to a small slice of traffic first, watching it closely, then rolling out to everyone once it looks clean) for the security issue, paired with a sandboxed or stubbed version of the feature for the demo, often means sales isn't actually blocked on the mainline fix landing first.

4. Communicate the decision and the reasoning immediately

Both sides need a concrete plan with timestamps, not just a priority call: what's happening, by when, and what the other side gets in the meantime.

Worked example

The patch ships to a small share of traffic first while being monitored, then rolls out fully once confirmed clean. In parallel, a second engineer builds a stubbed version of the requested feature specifically for the demo environment, so sales can present it without depending on the code currently under remediation. Both sides get an update within a couple of hours: security gets an ETA for full rollout, sales gets confirmation the demo will work and exactly how.

Trade-offs and pitfalls

• Defaulting to whichever request comes from the louder or more senior stakeholder, rather than actual exposure, is the most common failure mode here.
• Building a demo-only workaround without labeling it clearly as temporary risks it quietly becoming the real implementation, skipping the proper fix.
• Failing to give both sides a concrete timeline turns a reasonable prioritization call into a trust problem, even when the call itself was correct.
• Treating this as strictly either/or, instead of looking for a path that partially serves both, wastes an option that's usually available.

Direct answer. Comment when the code can't express WHY (a business rule, a workaround, a non-obvious trade-off); refactor instead of commenting when the comment only restates WHAT the code already says -- a comment that duplicates the code is guaranteed to drift out of sync with it eventually.

The trivial case

# increment i by 1
i += 1

This comment is pure noise: it tells you nothing i += 1 doesn't already say faster to read. Delete it; if i needs a better name to convey intent (e.g., retry_count += 1), fix the name instead of commenting around it.

A comment that legitimately belongs (explains WHY)

# Stripe requires idempotency keys to be reused for retries within 24h,
# otherwise it treats a retry as a new charge. See INC-4021.
idempotency_key = order_id  # intentionally NOT time-based

No amount of renaming makes 'why we chose this specific value, tied to an external API's undocumented-until-we-got-burned behavior' obvious from the code alone -- this is exactly the kind of context a comment should preserve, ideally with a link to the incident/ticket for anyone who wants the full story.

A comment that's a smell (explains WHAT, redundant with the code)

# loop through all users
for user in users:

The code already says this as clearly as English could; the comment adds a second thing that has to be kept in sync every time the loop changes, for zero reader benefit.

A simple test to apply

Ask: 'if I deleted this comment, would a competent reader lose information, or just lose a restatement?' If deleting it loses nothing, delete it. If deleting it loses the REASON something non-obvious is true, keep it (and consider whether the reason belongs in a commit message / ticket link too, for permanence).

Trade-offs and pitfalls

• Comments that explain why are still at risk of going stale if the underlying reason changes (the external API behavior gets fixed) but nobody removes the now-obsolete comment -- treat comments as code that also needs maintenance, not a write-once artifact.
• Don't over-correct into a 'no comments ever' culture; some domains (financial regulations, security-sensitive code, deliberately non-obvious performance tricks) genuinely need WHY documented, and a codebase that bans comments entirely just pushes that knowledge into people's heads (or nowhere), which is worse.
• A comment that says 'TODO: fix this properly' with no ticket link or date is close to noise too -- if it's worth flagging, it's worth tracking somewhere more durable than an inline string that nobody searches for.

Direct answer

Model the courses as a directed graph where an edge from a prerequisite $B$ to a course $A$ means "$B$ must come before $A$", then run Kahn's algorithm: repeatedly take any course whose remaining prerequisite count (its indegree) is zero, add it to the order, and decrement the indegree of everything it unlocks. If every course gets processed this way, the resulting order is valid. If the queue empties while courses still have a nonzero indegree, those courses form a cycle, a prerequisite loop that can never be satisfied, and finishing all courses is impossible.

Approach

• Build an adjacency list (prerequisite to course) and an indegree array (how many unprocessed prerequisites each course still has).
• Seed a queue with every course that already has indegree zero.
• Repeatedly pop a course, append it to the output order, and for every course it unlocks, decrement that course's indegree; if it hits zero, enqueue it.
• If the final order's length equals the number of courses, it's a valid full order; otherwise the remaining, never-enqueued courses are exactly the ones stuck in a cycle.

from collections import deque
from typing import List, Tuple


def find_order(num_courses: int, prerequisites: List[Tuple[int, int]]) -> List[int]:
    """prerequisites: list of (course, prereq) pairs meaning 'course'
    depends on 'prereq'. Returns a valid order, or [] if a cycle makes
    finishing all courses impossible."""
    adj: list[list[int]] = [[] for _ in range(num_courses)]
    indeg = [0] * num_courses
    for course, prereq in prerequisites:
        adj[prereq].append(course)
        indeg[course] += 1

    queue = deque(c for c in range(num_courses) if indeg[c] == 0)
    order: list[int] = []
    while queue:
        node = queue.popleft()
        order.append(node)
        for nxt in adj[node]:
            indeg[nxt] -= 1
            if indeg[nxt] == 0:
                queue.append(nxt)

    return order if len(order) == num_courses else []


if __name__ == "__main__":
    # course 1 needs 0, course 2 needs 0, course 3 needs 1 and 2
    print(find_order(4, [(1, 0), (2, 0), (3, 1), (3, 2)]))
    # cycle: 0 needs 1, 1 needs 0
    print(find_order(2, [(0, 1), (1, 0)]))

Running this prints [0, 1, 2, 3] for the first case (course 0 has no prerequisites, unlocks 1 and 2, which both unlock 3) and [] for the second (a two-course cycle where neither course ever reaches indegree zero).

Key points

• The indegree count is exactly "how many prerequisites this course is still waiting on"; a course only becomes eligible once that count hits zero.
• Multiple valid orders can exist whenever more than one course is simultaneously eligible; if a canonical, reproducible order matters (for example a deterministic build or test replay), swap the queue for a min-heap to always take the smallest eligible course id next, which costs $O(\log k)$ per pop instead of $O(1)$, where $k$ is the number of currently eligible courses.
• A directed acyclic graph (DAG) is the name for the acyclic case that always has at least one valid topological order; the moment a cycle exists, no such order can exist for the courses on that cycle.

Complexity

Time: $O(V + E)$ where $V$ is the number of courses and $E$ is the number of prerequisite pairs (each course and each edge is processed exactly once). Space: $O(V + E)$ for the adjacency list and indegree array.

Edge cases

• Disconnected components or isolated courses (no prerequisites and nothing depends on them) are scheduled immediately, since their indegree starts at zero.
• A course listed as its own prerequisite is a one-node cycle and is caught by the same length check.
• Duplicate prerequisite pairs inflate the indegree count but don't change correctness, since the count still reaches zero at the same logical point (one extra decrement per duplicate, which the duplicate edge itself supplies).
• An empty prerequisite list means every order of the courses is valid.
• Checking only "did the queue run empty" without also checking that the output length equals the course count is the most common bug: a graph can have one small cycle alongside many unrelated, fully resolvable courses, and skipping the length check silently returns an incomplete, invalid order.

Direct answer

Normalize both strings to the same Unicode normalization form and case-fold them, rather than just lowercasing, before counting characters. The same visual text can be represented by different underlying code point sequences, and case folding, not naive lowercasing, is the operation Unicode actually defines for caseless comparison across scripts. With that one extra normalization step, the same O(n) time, O(k) space frequency-map technique from the basic version still applies unchanged, k bounded by the number of distinct normalized characters.

Structured elaboration

Normalization forms. NFC (Normalization Form Canonical Composition, preferring a single precomposed character wherever one exists) and NFD (Normalization Form Canonical Decomposition, preferring a base character followed by separate combining marks) are two different, both entirely valid, code point sequences for the exact same visual text. "café" typed as a precomposed é is 4 code points; the same visual text with é written as "e" plus a combining acute accent is 5 code points. A character-by-character frequency count of the two, with no normalization step, sees different counts for literally identical text.

Casefold, not lower(). Python's str.lower() does not implement full Unicode case folding. The clearest example is German eszett: "straße".lower() leaves ß alone (still 6 characters), while "straße".casefold() expands it to "ss" (7 characters), which is the standard case-insensitive equivalence Unicode defines (ß case-folds to ss). casefold(), not lower(), is the correct building block for caseless comparison across languages.

Stated assumptions. This technique operates at the code point level after normalizing and case-folding, not at the full grapheme-cluster level (a base letter with several stacked combining marks, common in Vietnamese or Devanagari text, is a deeper case addressed only as a boundary note below, not solved here). str.isalnum() in Python is Unicode-aware across scripts, not an ASCII-only check, so it correctly drops whitespace and punctuation in non-Latin text too. Whichever normalization form you pick, NFC or NFD, must be applied consistently to both input strings, the specific form chosen does not matter as long as it is the same on both sides of the comparison.

Worked example

import unicodedata
from collections import Counter

def _normalize_for_anagram(x: str, form: str = "NFC"):
    x = unicodedata.normalize(form, x)
    x = x.casefold()
    return [c for c in x if c.isalnum()]

def is_anagram_unicode(s: str, t: str) -> bool:
    ns, nt = _normalize_for_anagram(s), _normalize_for_anagram(t)
    if len(ns) != len(nt):
        return False
    return Counter(ns) == Counter(nt)

cafe_nfc = "caf" + chr(0x00E9)
cafe_nfd = "caf" + chr(0x0065) + chr(0x0301)
print("NFC form code points:", [hex(ord(c)) for c in cafe_nfc])
print("NFD form code points:", [hex(ord(c)) for c in cafe_nfd])
print()

def is_anagram_naive(s, t):
    def normalize(x):
        return [c.lower() for c in x if c.isalnum()]
    ns, nt = normalize(s), normalize(t)
    return len(ns) == len(nt) and Counter(ns) == Counter(nt)

print(f"is_anagram_naive(NFC {cafe_nfc!r}, NFD {cafe_nfd!r})   = {is_anagram_naive(cafe_nfc, cafe_nfd)}  (WRONG: same text, flagged as non-anagram)")
print(f"is_anagram_unicode(NFC {cafe_nfc!r}, NFD {cafe_nfd!r})  = {is_anagram_unicode(cafe_nfc, cafe_nfd)}  (correct: same text -> True)")
print()

strasse = "stra" + chr(0x00DF) + "e"
print(f"{strasse!r}.lower()    = {strasse.lower()!r}  (len {len(strasse.lower())})")
print(f"{strasse!r}.casefold() = {strasse.casefold()!r}  (len {len(strasse.casefold())})")
print(f"is_anagram_naive({strasse!r}, 'strasse')   = {is_anagram_naive(strasse, 'strasse')}  (WRONG: length mismatch under .lower())")
print(f"is_anagram_unicode({strasse!r}, 'strasse')  = {is_anagram_unicode(strasse, 'strasse')}  (correct: casefold equates ss/eszett)")
print()

import random
base = "ΟΔΥΣΣΕΥΣ"
shuffled = list(base.casefold())
random.Random(42).shuffle(shuffled)
shuffled_str = "".join(shuffled)
print(f"shuffled multilingual case: {base!r} vs {shuffled_str!r}")
print(f"is_anagram_unicode -> {is_anagram_unicode(base, shuffled_str)} (expected True: same multiset of letters, just reordered and re-cased)")
other = "ΑΘΗΝΑ"
print(f"is_anagram_unicode({base!r}, {other!r}) -> {is_anagram_unicode(base, other)} (expected False)")

Output:

NFC form code points: ['0x63', '0x61', '0x66', '0xe9']
NFD form code points: ['0x63', '0x61', '0x66', '0x65', '0x301']

is_anagram_naive(NFC 'café', NFD 'café')   = False  (WRONG: same text, flagged as non-anagram)
is_anagram_unicode(NFC 'café', NFD 'café')  = True  (correct: same text -> True)

'straße'.lower()    = 'straße'  (len 6)
'straße'.casefold() = 'strasse'  (len 7)
is_anagram_naive('straße', 'strasse')   = False  (WRONG: length mismatch under .lower())
is_anagram_unicode('straße', 'strasse')  = True  (correct: casefold equates ss/eszett)

shuffled multilingual case: 'ΟΔΥΣΣΕΥΣ' vs 'σσυσυεοδ'
is_anagram_unicode -> True (expected True: same multiset of letters, just reordered and re-cased)
is_anagram_unicode('ΟΔΥΣΣΕΥΣ', 'ΑΘΗΝΑ') -> False (expected False)

The NFC-versus-NFD case is the sharpest demonstration: the same literal text "café", represented two different (both entirely valid) ways, is wrongly flagged as not an anagram of itself by a naive .lower()-plus-Counter check, and correctly flagged as one once both sides are normalized to the same form first. The eszett case shows the same pattern for casing: .lower() leaves the two strings at different lengths (a real bug, not a subtlety), while .casefold() correctly equates them. A genuine multilingual anagram (the Greek letters of "ΟΔΥΣΣΕΥΣ", deterministically shuffled with random.Random(42)) confirms the technique still does its actual job, correctly returning True for a real anagram and False against unrelated Greek text ("ΑΘΗΝΑ").

Trade-offs and pitfalls

Code-point-level comparison after normalization is the practical, standard-interview-depth answer, but it is not full grapheme-cluster equality: text that stacks multiple combining marks on one base character can, in principle, be grouped differently by two representations that both eventually normalize to the same NFC form by a different path. In practice NFC handles the overwhelming majority of real-world multilingual text correctly; fully grapheme-cluster-safe comparison is a further, rarely-needed step beyond what this answer implements.

Order matters: normalize first, then case-fold, not the reverse, and not .lower() after normalizing instead of .casefold(). Applying case-folding to whichever normalization form you've already settled on gives a consistent answer regardless of how the input arrived; mixing the order or substituting .lower() reintroduces exactly the bugs demonstrated above.

This machinery, normalize plus casefold, is the multilingual, standards-based extension of the same technique as plain .lower(). Reach for it specifically when the input is genuinely multilingual or user-generated text, not as the default on every anagram check, the plain version is simpler and sufficient for ASCII-only input.