Hierarchical Path Stores

What's being tested

This tests trie/tree modeling for path-addressed state, plus clean API semantics for `create`, `set`, `get`, `remove`, and path validation. Interviewers probe whether you can turn UNIX-style strings into reliable data-structure operations with predictable complexity and well-defined error behavior.

Patterns & templates

• Trie node model — Node { children: Map<String, Node>, value, hasValue }; lookup is O(depth) nodes after parsing.

• Path normalization — implement `splitPath(path)` once; reject empty paths, missing leading /, duplicate slashes, trailing slash ambiguity, and ./.. if unsupported.

• Create semantics — `create("/a/b", v)` usually requires parent `/a` to exist and `/a/b` not to exist; return boolean or throw consistently.

• Set vs create — `set(path, v)` should fail if path missing unless requirements say auto-create; clarify this before coding.

• Remove semantics — decide whether deleting non-leaf paths is allowed; recursive delete is O(size of subtree), leaf-only delete is O(depth).

• Tree distance template — store parent pointers and depth; distance is depth(u)+depth(v)-2*depth(lca(u,v)).

• Complexity accounting — include string parsing cost: operations are O(L) where L is path length, or O(k) components after splitting.

Common pitfalls

Pitfall: Treating `"/a//b"` or `"/a/b/"` as valid accidentally because `split("/")` produces empty tokens.

Pitfall: Conflating missing node with node storing null; use `hasValue` or a sentinel instead of checking value truthiness.

Pitfall: Forgetting subtree deletion and stale parent references when implementing `remove` on an internal node.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.