Coding interviews
Reveal answer and reasoning
A defensible username contract can normalize to a chosen form, apply a documented comparer and enforce a text-element limit, while separately validating allowed characters and security concerns. It should preserve or derive display spelling intentionally. No general Unicode API can decide all product-specific identity and spoofing policies without those requirements.
Parsing all element boundaries takes O(n) work and O(g) index storage for g text elements. The substring result can allocate O(n) code units. This implementation prioritizes a clear boundary contract rather than a minimal-allocation prefix scan. Unicode segmentation behavior follows the runtime implementation. Rune is not the same as a user-perceived grapheme, and string.Length is not a display width. Equal-looking strings can still differ ordinally without normalization.
Input containing unpaired surrogates or requirements for locale-specific presentation need an explicit policy beyond this fixed valid-Unicode fixture.
A good interview explanation derives five code units, four scalars and three text elements from the actual sample rather than memorizing that Unicode is complicated. It shows why slicing at two code units would be unsafe and why a two-element prefix is different. It also reports the boundary-array allocation honestly. A senior answer separates normalization, case matching, display width and security from segmentation.
The runnable reference card supplies an additional representation-and-segmentation counterexample, reinforcing that a correct truncation boundary does not automatically establish a complete text-identity policy. Empty input and a zero-element prefix need direct tests too. The function returns an empty string without indexing beyond the empty boundary array, preserving the declared count semantics.
What a strong answer covers
- A defensible username contract can normalize to a chosen form, apply a documented comparer and enforce a text-element limit, while separately validating allowed characters and security concerns.
- Parsing all element boundaries takes O(n) work and O(g) index storage for g text elements.
- Rune is not the same as a user-perceived grapheme, and string.Length is not a display width.
Common pitfall
Rune is not the same as a user-perceived grapheme, and string.Length is not a display width. Equal-looking strings can still differ ordinally without normalization. Input containing unpaired surrogates or requirements for locale-specific presentation need an explicit policy beyond this fixed valid-Unicode fixture.
Follow-up questions
- Test count zero, a count beyond the element count and precomposed versus decomposed accented text. Hint: compare both preserved code units and element counts rather than assuming normalization occurred.
- How can normalization invalidate offsets that were measured in the original spelling?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.