← Google Interview Insights

Google·Software Engineer·Onsite - System Design / Architecture·Senior

Senior
May 2026

Summary

Google SWE interview with a meaty system design / data structures problem about modeling an org hierarchy. Not your typical LeetCode grind, this one required actual thinking about correctness guarantees and edge cases under weird input orderings.

Questions Asked (1)

Q1

Design a data structure that supports three operations on an org hierarchy: recording that one employee directly manages another, recording that two employees share the same manager (even if that manager is unknown yet), and querying whether one employee is an ancestor of another in the management chain. Handle out-of-order operations, reconcile implied relationships, and reject cycles.

Algorithms & Data StructuresSystem DesignTechnical Trade-offs
Author's notes

This one took me a while to even parse correctly.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Model the hierarchy as a dynamic forest using union-find with parent pointers and path compression, where each set represents a tree and the root is the topmost known manager. Handle 'same manager' by unioning the two employees under a dummy node if the manager is unknown, and 'directly manages' by linking the manager as parent of the employee, checking for cycles via find operations. For ancestor queries, use a disjoint set union with an additional 'ancestor' relation or maintain a separate structure like a balanced tree or Euler tour to answer reachability efficiently.

Pro tip: Clarify upfront whether operations are online or offline, and discuss trade-offs between time complexity and simplicity—Google values candidates who can articulate why a union-find with path compression gives near O(1) amortized time for merges and finds, but may need augmentation for ancestor queries.

1. Clarify requirements and edge cases

Ask about the expected number of operations, whether queries are interleaved, and if the hierarchy is a tree or can have multiple roots. Confirm that cycles must be rejected and that implied relationships (e.g., transitive management) should be inferred.

2. Choose core data structures

Propose a union-find (disjoint set) with parent pointers for efficient merging and cycle detection, augmented with a separate structure (e.g., a hash map of children lists or an Euler tour tree) to support ancestor queries. Explain why a simple tree with parent pointers is insufficient for out-of-order 'same manager' operations.

3. Define operations and handle out-of-order inputs

For 'manages(A, B)': ensure A is not a descendant of B (cycle check via find), then set A as parent of B and union their sets. For 'sameManager(A, B)': if both have known managers, union them under that manager; if one or both managers unknown, create a placeholder node and union under it. For 'isAncestor(A, B)': check if A is an ancestor of B using the augmented structure (e.g., compare Euler tour entry/exit times).

4. Analyze complexity and trade-offs

Discuss time complexity: union-find gives near O(1) amortized for merges and finds, but ancestor queries may require O(log n) with a balanced tree or O(1) with Euler tour after O(n) preprocessing. Mention space complexity and potential need for path compression and union by rank.

5. Test with examples and edge cases

Walk through a sequence of operations including out-of-order 'same manager' before 'manages', cycle attempts, and ancestor queries. Verify that implied relationships are correctly inferred and cycles are rejected.

Key Points to Mention

  • Union-Find (Disjoint Set Union) with path compression and union by rank for efficient merging and cycle detection.
  • Handling out-of-order operations by using placeholder nodes for unknown managers and later reconciling when the manager is specified.
  • Cycle detection: before adding a 'manages' edge, check if the manager is already a descendant of the employee using find operations.
  • Ancestor query implementation: augment union-find with Euler tour timestamps or maintain a separate tree structure for O(1) or O(log n) queries.
  • Trade-offs between time complexity and implementation complexity: e.g., simple parent pointers vs. augmented structures for ancestor queries.
  • Edge cases: multiple roots, self-management, duplicate operations, and queries before any relationships are defined.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.