Google Embedded Developer (Entry Level) - Complete Interview Preparation Guide

Clarify the problem
Multicore SoCs add complexity because interrupts can land on any core, share hardware paths, and interact with caches and OS schedulers — all of which affect determinism and latency for real-time embedded tasks.

Key complications

• Interrupt routing & affinity
  • GIC/interrupt controller can route to specific cores or a core set. Incorrect affinity causes cache warm-up and cross-core wakeups.
• Shared interrupts
  • Peripherals using shared lines require edge/level handling and ISR demultiplexing; contention increases worst-case latency.
• Per-core ISRs vs forwarding
  • Per-core ISRs minimize context switch and cross-core sync but need duplicate handlers or careful resource partitioning.
  • Centralized ISR with forwarding simplifies logic but adds inter-processor interrupts (IPIs) and extra latency.
• Cache-coherency impacts
  • Wakeups cause cache misses for ISR code/data; cache-line bouncing and write-back invalidate increase tail latency.

Strategies to meet real-time constraints

• Affinity partitioning
  • Pin high-priority device interrupts to a dedicated core (or a pair) to avoid interference; use isolation (no user tasks) on that core.
• Static allocation
  • Assign device drivers and their processing threads to the same core to keep data hot in cache and avoid cross-core synchronization.
• Fast ISR + deferred work
  • Keep top-half ISR minimal (ack, schedule DSR) and do heavy processing in core-local deferred tasks (workqueues or RT threads) pinned to same core.
• Use per-core driver instances
  • Where possible, instantiate lightweight per-core handlers to avoid locks; use lock-free ring buffers for producer/consumer across cores.
• Tune cache behavior
  • Place critical ISR code/data in tightly-coupled memory or mark as non-cacheable if predictable latency is paramount; pre-warm caches at known times.
• Measure & validate
  • Build worst-case latency model (interrupt path + cache miss penalty + IPI cost), run stress tests with contention and show bounds.

Trade-offs

• Isolation increases predictability but wastes cores.
• Centralized handling reduces code duplication but raises latency due to IPIs and contention.
• Non-cacheable memory reduces jitter but lowers throughput.

This approach balances determinism (affinity + isolation + minimal ISR) with practicality (deferred processing, per-core data locality) for embedded multicore real-time systems.

Direct answer

I treat this as a trade-off, not a knowledge threshold: I ship once I understand the parts that are actually load-bearing for correctness and for whoever maintains this afterward, I explicitly flag whatever I still don't understand at that point rather than hiding it, and I shape the first version to limit how much damage an unknown could cause.

Structured elaboration

• The real question isn't "do I know enough" in the abstract. It's whether I know enough of the parts that matter for this specific decision. I weigh the cost of continuing to study against the cost of the unknown parts causing wrong behavior, against how easily the team that inherits this, including future me, will be able to reason about it later.
• Separate load-bearing unknowns from cosmetic ones. A load-bearing unknown would silently break correctness or be expensive to unwind later; a cosmetic one is something like unfamiliar style conventions or a minor part of the interface I could look up when I need it. Only the first kind should actually block shipping.
• Flag what's still unknown, don't hide it. If something genuinely isn't understood yet at ship time, I say so directly: a comment in the code, a note in the review, or a follow-up item, so it's a visible, tracked risk instead of a silent one that surprises someone later.
• Shape the ship to limit exposure. Smaller surface area, behind a flag (a toggle that turns the new code path on for only a slice of users, so it's cheap to switch back off), easy to reverse, reviewed by someone who does know the tool well: all of these reduce how much damage an unknown can do if I turn out to be wrong about it.

Worked example

Picking up a new library for managing application state under a real deadline, I got comfortable enough with the common patterns within a couple of days but hadn't dug into how it handled a specific edge case around concurrent updates. I decided that edge case was load-bearing, since getting it wrong could cause silent data corruption, so I spent an extra half-day specifically verifying that one behavior with a small isolated test, while deciding I didn't need to fully understand the library's less-common configuration options, since those were cosmetic and easy to look up later if we ever needed them. I shipped behind a flag on a low-traffic part of the product first, and in the code review I explicitly flagged that I hadn't yet tested how the library behaved under our heaviest load, since I hadn't had time to simulate that realistically, and the team agreed that was an acceptable known gap to track rather than block on, given the limited blast radius of where it first shipped.

Trade-offs and pitfalls

The clearest failure on one side is perfectionism: waiting until you feel fully confident before shipping anything, which in practice means never shipping, since real fluency usually only comes from using something for real. The failure on the other side is shipping recklessly without distinguishing which unknowns actually matter, or worse, not flagging them at all, so the team inherits invisible risk they didn't agree to take on. The trade-off only works if the parts you decide are safe to ship with gaps genuinely are cosmetic, and you're honest with yourself, and with reviewers, about which unknowns you're actually still carrying.

Situation & goal
Design a memory strategy so real-time control loop never suffers unbounded allocation/deallocation latency; allocations must be bounded worst-case and observable.

Approach overview

• Use statically sized pools (slab or fixed-block) or TLSF for general-purpose but deterministic requirements.
• Prefer per-task (per-thread/ISR) arenas with fixed-size freelists to eliminate cross-task contention.
• Partition pools by size-class and by priority/core to avoid blocking lower-priority tasks.

Allocator choices

• Fixed-block pools (power-of-two or size classes): O(1) alloc/free, deterministic.
• TLSF: true O(1) with fragmentation control — good if many sizes but validate worst-case on target.
• Bump allocators for short-lived bulk allocations in scheduling windows (resettable).

Pool partitioning & per-task arenas

• Create N arenas: one per control-thread + one for ISR. Each arena holds free-lists per size-class.
• Size classes chosen to minimize internal fragmentation (measure real allocations).
• Optionally allow borrowing: atomic transfer of fixed-number blocks between arenas with bounded steps.

Lock contention mitigation

• Avoid global locks: use per-arena lock-free single-producer single-consumer freelists for fast paths.
• For multi-producer cases, use bounded spin with priority-inheritance mutex, or interrupt-disable short critical sections (keep duration constant).
• Use allocation fast-path that pops from per-CPU/ per-task freelist; slow-path logs and blocks only if empty.

Example fast-path (C-like):

// single-producer lock-free pop (Treiber-like)
node_t *pop(freelist_t *f) {
  node_t *n;
  do {
    n = atomic_load(&f->head);
    if (!n) return NULL;
  } while (!atomic_compare_exchange_weak(&f->head, &n, n->next));
  return n;
}

Worst-case time analysis

• Fixed-block alloc/free: bounded by constant number of atomic ops and at most one cache line write → O(1) deterministic latency.
• If borrowing/slow-path allowed, worst-case equals bounded slow-path steps (set strict cap and preallocate emergency pool).

Runtime detection of long-tail delays

• Instrument allocator to timestamp start/end; maintain sliding-window histogram and EWMA of latencies.
• Expose counters: alloc_count, slow_path_count, max_latency, tail_percentiles (p99, p999).
• On exceeding threshold: trigger diagnostic (dump free-list sizes), raise watchdog event, or switch control loop to preallocated emergency arena.

Practical notes

• Measure on target HW (cache effects, DMA). Tune block sizes and arena counts.
• Prefer static allocation of pool memory at boot to avoid heap behavior.
• Test worst-case by fault-injection: deplete arenas, simulate interrupts, and verify bounded response.

Direct answer
Cover the current state, what has already been tried (including what didn't work), and what to watch for next, so whoever picks this up doesn't waste time repeating steps you've already ruled out.

Structured elaboration

1. Current state: what's actually happening right now, in concrete terms, not just a label. "Service is degraded" is weaker than "response times are 3x normal but the service is still serving requests."
2. What's been tried, including attempts that didn't work. This is often the most valuable part of a handoff, since it prevents the next person from re-trying something you've already ruled out.
3. What to watch for: the specific signal that would indicate the situation is getting better, getting worse, or that a particular hypothesis is confirmed or ruled out.
4. Anything time-sensitive: a deadline, an escalation that's already in motion, or a promise already made to someone waiting on an update.
5. Keep it scannable. A handoff note that's read under time pressure needs to be skimmable in under a minute, not a full narrative.

Worked example
"Current state: checkout latency is elevated (roughly 2x baseline) but not failing outright. Tried: restarted the payment service (no change), checked for a recent deploy (none in the last 24 hours, ruling that out). Not yet tried: checking the database connection pool, which is my next suspicion since the timing correlates with a traffic spike. Watch for: if latency crosses 3x baseline, that's the threshold where we'd start failing requests, escalate immediately if you see that."

This tells the next person exactly what's confirmed, what's ruled out, what's still suspected, and the specific threshold that changes the urgency, without requiring them to re-derive any of it.

Trade-offs and pitfalls

• Omitting what didn't work is the most common gap; a handoff that only says what you tried, without saying it didn't help, can lead the next person to redundantly retry it.
• A handoff written too tersely to be useful ("still broken, working on it") forces the next person to start from scratch; a handoff written as a full narrative takes too long to read under time pressure. The right length states facts plainly without either extreme.
• If you genuinely don't have a next hypothesis, say so honestly rather than implying more progress than you've made; "no clear lead yet, still gathering information" is a legitimate and useful handoff.

Approach (brief)

Use the standard bit-twiddling trick: find the rightmost non-trailing zero, flip it, clear bits to its right, then insert (count_ones-1) ones at the least-significant positions. This is O(1) with few bit ops.

C implementation

#include <stdint.h>

// Return next higher uint32 with same popcount, or 0 if none exists.
uint32_t next_with_same_ones(uint32_t x) {
    if (x == 0) return 0;
    uint32_t smallest = x & -x;            // rightmost 1
    uint32_t ripple = x + smallest;        // flip rightmost non-trailing zero
    if (ripple == 0) return 0;             // overflow -> no larger number
    uint32_t ones = x ^ ripple;            // bits that changed
    ones = (ones >> 2) / smallest;         // shift the ones to the rightmost positions
    return ripple | ones;
}

Why it works

• smallest = isolate lowest 1.
• ripple adds smallest giving the next carry to flip the zero above the trailing ones.
• ones computes the trailing ones that need to be packed at LSB side.
• Division by smallest and shift align the ones.

Complexity & edge cases

• Time: O(1) constant bit operations. Space: O(1).
• Returns 0 on overflow (no higher with same popcount) and for input 0.

Notes

• Works on two's-complement; well-suited for embedded C.

High-level goal
Create a single traceable change-control flow so every production unit has a known (hardware rev, schematic, BOM, firmware hash, factory-test vector) tuple before shipping.

Required tooling

• PLM/ALM (single source of truth) linking ECOs to part numbers and schematics
• Git for firmware branches + CI/CD (build artifacts stored in an artifact registry with signed hashes)
• ECO tracker (Jira + structured templates) generating immutable ECO IDs
• BOM comparison tool (e.g., OpenBOM or internal) and schematic/versioned CAD system
• Factory MES with barcode/QR scan and test station orchestration (checks artifact hash)
• Release dashboard showing mappings and approvals

Metadata to capture

• Hardware Revision ID (e.g., HW-R1.2) and PCB serial pattern
• ECO ID (ECO-2026-045) with description, owner, date
• Schematic revision & CAD commit hash
• BOM version and approved vendor/lot constraints
• Firmware branch/tag and artifact hash (SHA256)
• Factory test vector version and test SW version
• Signoff timestamps and approvers

Gating & signoff

• Gate 1: Design review — hardware engineer signs ECO; PLM records schematic/BOM changes.
• Gate 2: Firmware build — CI verifies target HW matrix; artifacts signed and linked to ECO ID.
• Gate 3: System verification — integration test on representative HW rev; test report attached.
• Gate 4: Release board — QA and Manufacturing signoff; MES entry requires matching hw rev and firmware hash before programming.

Rollback & emergency fix

• Maintain immutable build artifacts and "golden" firmware for each HW rev.
• Factory can downgrade/uprev via OTA or local programmer using artifact registry entries.
• Emergency ECO flow: hotfix branch → expedited CI → signed artifact → controlled pilot build (10–100 units) with full traceability before wide rollback.

Avoid mismatches

• Enforce factory gate: MES reads PCB revision code (silkscreen/EEPROM) and requires matching firmware SHA before flashing.
• Cryptographically sign firmware; bootloader verifies signature and rejects unsuitable HW-target firmware.
• Embed HW-ID check in firmware startup; if mismatch, enter safe mode and flag serial to PLM.
• Daily dashboard alerts for any unit failing HW/FW mapping checks, and blocked shipments until resolved.

This process makes every shipped unit auditable, minimizes human error, and provides deterministic rollback paths while keeping embedded constraints (small bootloader verifier, artifact signing) in mind.

Answer (Embedded Developer perspective)

Summary recommendation

• LoRaWAN is the most realistic to meet 2-year battery life with wide range; BLE is good for short-range, low-latency, and gateway-carried devices; Wi‑Fi is unlikely to meet 2-year battery life unless using rare low-power variants and very large batteries.

Power

• BLE (BLE 5.0, peripheral sending 30 B every 10 min): very low TX energy (tens–hundreds µJ per packet). With aggressive sleep and radio off, a small Li-ion coin cell or AAA can last years if connection stays minimal. Typical MCU+BLE estimate: ~50–200 µA average.
• LoRaWAN (SF7–SF12 trade-off): single TX might be several mJ–100s mJ depending on spreading factor; average current often <100 µA for low duty. Practically can achieve 2+ years on a 2400 mAh Li battery for 30 B/10min.
• Wi‑Fi (802.11n): high TX power and long association overhead; average currents in mA–100s mA when active — impractical for 2-year with small batteries.

Range

• BLE: ~10–40 m (indoors), up to 100 m line-of-sight with BLE Long Range.
• LoRaWAN: kilometers (rural tens of km; urban ~1–5 km).
• Wi‑Fi: ~30–100 m typical; depends on environment.

Latency

• BLE: low (ms) for connected; suitable for near-real-time.
• LoRaWAN: higher and variable (seconds to minutes) due to duty cycle, ADR and class (A/C).
• Wi‑Fi: low (ms), suitable for real-time.

Network topology

• BLE: star/mesh (with Bluetooth Mesh) — often gateway or phone-centric.
• LoRaWAN: star-of-stars (end nodes → gateways → network server).
• Wi‑Fi: star (AP-centric) with local LAN/internet.

Industry use cases

• BLE: wearable sensors, asset tags, phone-proxied sensors, firmware updates via phone.
• LoRaWAN: remote environmental sensors, agriculture, smart meters requiring years of life and long range.
• Wi‑Fi: high-throughput sensors, on-prem devices with mains power (cameras, firmware-heavy devices).

Concrete consideration for this device

• If you need 2-year battery, multi-km range, and small payloads every 10 min → choose LoRaWAN (optimize SF and ADR).
• If device is near a phone/gateway and needs low latency/config via mobile → BLE.
• Avoid Wi‑Fi unless mains power or very large battery is acceptable.

Situation & summary recommendation
Choose a lightweight RTOS when your product needs clear concurrency, modularity, and future feature growth. Use a bare-metal super-loop for the simplest, fixed-function designs where memory and overhead are extremely constrained.

Maintainability

• RTOS: threads/tasks isolate sensor sampling, filtering, radio stack — easier to test, reuse, and extend.
• Super-loop: simpler to read initially but tends to become spaghetti as features (retries, backoff, power states) are added.

Concurrency

• RTOS: native task-level concurrency and synchronization primitives (mutexes, semaphores, queues) simplify producer/consumer patterns (ADC → filter → radio).
• Super-loop: must use state machines and careful flag handling; ok for few deterministic tasks.

Latency

• RTOS: deterministic if using priority-based scheduling + bounded ISRs; better for strict deadlines (sampling jitter, radio ack).
• Super-loop: can have lower worst-case interrupt-to-task latency if tasks are short but harder to guarantee under growth.

Memory overhead

• RTOS: stack per task and kernel footprint — choose tiny kernels (FreeRTOS, Zephyr minimal) for constrained MCUs.
• Super-loop: minimal RAM/ROM, preferable on very small MCUs.

Interrupt handling

• RTOS: keep ISRs short, offload work to tasks via queues; simplifies complex ISR logic.
• Super-loop: ISRs typically set flags; careful to avoid long critical sections.

Team experience & risk

• RTOS: faster onboarding for teams familiar with RTOS patterns; reduces concurrency bugs long-term.
• Super-loop: OK for teams with strong low-level discipline and when certification/simplicity is prioritized.

Choose RTOS if you expect concurrency, feature growth, or hard real-time needs; pick super-loop for ultra-constrained, fixed-scope products.

Clarify goal & constraints

• Reduce generated code across TUs and link time while preserving type safety and low RAM/flash for embedded targets. Keep predictable performance and no RTTI if constrained.

Practical techniques

1. Explicit instantiation / extern template

• Move heavy template impl to one .cpp and instantiate only needed types.

// heavy.h
template<typename T> T heavy_op(T);
// heavy.cpp
#include "heavy.h"
template<typename T> T heavy_op<T>(T x){ /*...*/ }
template double heavy_op<double>(double);
// user.cpp
extern template double heavy_op<double>(double);

• Result: only one copy of code emitted.

2. Pimpl / move implementation to single TU

• Expose thin non-template façade in headers, template internals in .cpp via concrete types or small virtual interface when few types exist.
• Trade-off: small vtable overhead vs code size savings.

3. Type-erasure / runtime-polymorphism for many template combos

• Use small type-erasure wrapper (inlined small-buffer) to hold different concrete instantiations but compile one implementation path.

// simplified: store callable with erased type to avoid templating across TUs
class Erased {
  struct I { virtual void run()=0; };
  template<typename F> struct Impl : I { F f; void run() override{ f(); } };
  std::unique_ptr<I> p;
public:
  template<typename F> Erased(F fn): p(new Impl<F>{fn}){}
  void run(){ p->run(); }
};

• Preserves safety at runtime, reduces template explosion.

4. Reduce template parameter space

• Narrow template axes: prefer traits, enums, tag types, or constexpr parameters grouped into bitfields so compiler sees fewer unique instantiations.
• Example: replace bool template params with runtime flags or a single enum tag.

5. Move heavy templates to single TU (monolithic instantiation)

• If a template truly needs to be generic, provide explicit instantiations for supported types only; reject others with static_assert.

Trade-offs & metrics

• Measure binary size and link time before/after; check stack/heap impact of indirection/vtables.
• Prefer explicit instantiation for deterministic embedded performance; use type-erasure when many combinations impossible to statically enumerate.

Recommendation
Start with extern template/explicit instantiation for top offenders, add Pimpl for large classes, then consider type-erasure or parameter consolidation if instantiation count remains high.

Direct answer

Canonicalize before you hash: run every incoming string through the same fixed pipeline (Unicode normalization, then case folding, then trimming) so that logically-identical strings always produce byte-identical input to the hash function, then hash the canonical form with a cryptographic-strength function (SHA-256 or similar) to get a fixed-size, stable index key. The canonicalization step is what makes "logically identical" strings compare equal; the hash choice is what makes accidental collisions between genuinely different strings astronomically unlikely rather than a realistic operational risk.

Structured elaboration

Why canonicalization has to come first, in a fixed order. Two user-supplied strings can be logically the same identity (the same email address, the same username) while differing in raw bytes: different capitalization, incidental leading or trailing whitespace, or different Unicode encodings of the same visible character. If canonicalization doesn't happen before hashing, two representations of the same logical value hash to two different keys and the DB index silently treats one user as two.

NFC versus NFD, and why NFC is the more common default. Unicode allows the same visible character to be represented as one composed codepoint (NFC: Normalization Form C, "Canonical Composition") or as a base character plus separate combining marks (NFD: Normalization Form D, "Canonical Decomposition"). Either form works correctly as a canonicalization target as long as it is applied consistently to every string before comparison or hashing, since the goal is only that all logically-equal strings land on the same representation. NFC is chosen here specifically because it is the more compact form and the one most web platforms, databases, and the Unicode Consortium's own guidance treat as the default for stored text, so choosing it avoids surprising a downstream system that also normalizes to NFC independently.

Case folding versus lowercasing. Case folding is used instead of a plain lowercase conversion because case folding is defined specifically for caseless matching and correctly handles cases a naive lowercase does not (the German sharp s, ß, case-folds to ss, matching how it is treated as equivalent to ss in caseless comparisons, whereas simple lowercasing leaves it unchanged).

Trimming. Leading and trailing whitespace differences (a stray space from a copy-pasted email address, for instance) should not create a distinct identity. Trimming needs to operate on Unicode-aware whitespace, not just the ASCII space character, since a user could paste text containing a non-breaking space or other Unicode space character that a naive ASCII-only trim would miss.

Producing a stable hashed key. Once the string is canonicalized, hashing it with a cryptographic hash function (rather than a fast, non-cryptographic hash meant for in-memory hash tables) is the right choice specifically because the resulting key is going into a durable DB index: a cryptographic hash's output is effectively uniformly distributed over its output space, so two different canonical strings colliding to the same key by accident has probability governed by the birthday bound on the hash's output size, not by any structural weakness an attacker could exploit to deliberately engineer a collision. A domain-specific fixed prefix (not a secret, unlike a password salt) can be mixed in before hashing purely to avoid accidental key collisions with some other unrelated use of the same hash function elsewhere in the system; it does not need rotation.

Security and collision considerations, scoped to this problem. The relevant question here is "how likely is it that two different logical identities accidentally hash to the same key," which for a well-distributed cryptographic hash with a 256-bit output is not a practical concern at any realistic directory size. What this design does NOT need to get into is how the hash function itself resolves collisions internally, bucket layout, or table resizing: those are hash-table implementation concerns, not string-key-design concerns, and they belong to a different discussion about the data structure storing these keys rather than the process of producing the keys themselves.

Worked example

Full runnable code with pinned test cases:

import unicodedata
import hashlib


def canonical_key(raw):
    """Canonicalize a user-supplied string into a stable DB lookup key.
    Steps: NFC normalize -> casefold -> strip leading/trailing whitespace.
    Order matters: normalize before casefolding so composed/decomposed
    variants of the same character land on the same casefolded form."""
    return unicodedata.normalize("NFC", raw).casefold().strip()


def hashed_key(raw, salt=b"interviewstack-demo-salt-v1"):
    """Stable hashed index key: canonicalize first, then hash with a
    cryptographic-strength function (SHA-256) so accidental collisions are
    only as likely as the function's own security bound, not an accident of
    a weak custom hash. The salt is a fixed domain-separation prefix (not a
    secret, and not rotated like a password salt would be)."""
    canon = canonical_key(raw)
    return hashlib.sha256(salt + canon.encode("utf-8")).hexdigest()


if __name__ == "__main__":
    variants = [
        "Alice.Smith@Example.com",
        "  alice.smith@example.com  ",
        "alice.smith@example.com",
    ]
    for v in variants:
        print(f"{v!r:35} -> canonical={canonical_key(v)!r:28} hashed_key={hashed_key(v)}")

    # Built from explicit codepoint escapes so composed/decomposed forms are
    # unambiguous regardless of source-file encoding.
    precomposed_name = "Jos" + "é"          # J o s e-acute (1 codepoint)
    decomposed_name = "Jos" + "e" + "́"     # J o s e + combining acute (2 codepoints)
    print()
    print("precomposed raw:", repr(precomposed_name), "len", len(precomposed_name))
    print("decomposed raw: ", repr(decomposed_name), "len", len(decomposed_name))
    print("precomposed canonical:", canonical_key(precomposed_name))
    print("decomposed canonical: ", canonical_key(decomposed_name))
    print("canonical keys equal? ", canonical_key(precomposed_name) == canonical_key(decomposed_name))
    print("hashed keys equal?    ", hashed_key(precomposed_name) == hashed_key(decomposed_name))

Output (actual run):

'Alice.Smith@Example.com'           -> canonical='alice.smith@example.com'    hashed_key=681f25f0265fa3187a5bd4c9e8c2d2af8bcf8126195ddf8ad7e7fb4c49435c1a
'  alice.smith@example.com  '       -> canonical='alice.smith@example.com'    hashed_key=681f25f0265fa3187a5bd4c9e8c2d2af8bcf8126195ddf8ad7e7fb4c49435c1a
'alice.smith@example.com'           -> canonical='alice.smith@example.com'    hashed_key=681f25f0265fa3187a5bd4c9e8c2d2af8bcf8126195ddf8ad7e7fb4c49435c1a

precomposed raw: 'José' len 4
decomposed raw:  'José' len 5
precomposed canonical: josé
decomposed canonical:  josé
canonical keys equal?  True
hashed keys equal?     True

All three raw variants of the same email address (different capitalization, extra whitespace) collapse to the identical canonical form and the identical SHA-256 hashed key. The precomposed and decomposed forms of the same name also collapse to the same canonical key and the same hash, which is exactly the property the normalization step exists to guarantee.

Trade-offs and pitfalls

• Hashing the raw string directly (skipping canonicalization) is the most common wrong turn: it looks correct on ASCII-only test data and then silently creates duplicate "different" identities in production the moment a real user's name or email contains an accented character, mixed case, or incidental whitespace.
• Choosing a fast, non-cryptographic hash (something optimized for in-memory hash table buckets) instead of a cryptographic one is a reasonable choice for a purely in-memory structure, but is the wrong choice for a durable, security-relevant index key, since non-cryptographic hashes are explicitly designed to be fast and are not designed to resist deliberately engineered collisions.
• Normalizing to NFD instead of NFC (or mixing the two inconsistently across different code paths) is a real, subtle bug source: consistency of the chosen form matters far more than which specific form is chosen, and inconsistency between, say, a signup path and a login path is exactly how two supposedly-canonical keys for the same identity end up different.
• Case folding can change the number of characters in a string, so any length-based validation (a minimum-username-length check, for example) needs to run on the canonical form, not the raw input, if the check is meant to reflect what will actually be stored and compared.
• Locale-dependent case folding (Turkish dotless/dotted i is the classic example) is a real further wrinkle beyond the scope of a general-purpose canonicalization scheme; if the directory needs to support such locales correctly, a locale-aware folding step would need to be chosen deliberately rather than assumed, which is worth naming as a known limitation rather than silently ignoring.