Lowest Common Manager for Employee Groups
Reported by candidates from Google's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The constraint that matters in this Google OA question, reported September 2026, is that the hierarchy never changes across the whole query batch. That's a hint to preprocess once and answer fast. You're finding the lowest common manager for groups of employees in a binary tree, where IDs go up to a billion and the tree has up to 100000 nodes. It's lowest common ancestor, extended from two nodes to k nodes. If you blank on the setup, StealthCoder runs invisibly during the live assessment and can hand you a working structure. Better to know the trick before you open the invite.
The problem
A company reporting hierarchy is a rooted binary tree. The tree is encoded by parallel arrays employeeIds and managerIds. For each index i, managerIds[i] is the direct manager of employeeIds[i]; the root has manager -1. You also receive a batch of employee groups in queries. For each group, return the employee ID of its lowest common manager: the deepest employee whose subtree contains every employee in that group. An employee is in their own subtree, so a one-employee query returns that employee. Return one manager ID per query in the original query order. The hierarchy is fixed across the entire batch, so preprocess it to support large or frequent groups efficiently. Function lowestCommonManagers(employeeIds: int[], managerIds: int[], queries: int[][]) → int[] Examples Example 1 employeeIds = [1,2,3,4,5,6,7] managerIds = [-1,1,1,2,2,3,3] queries = [[4,5],[4,6,7],[2,4,5]] return = [2,1,2] Employees 4 and 5 report under 2. The group containing 4, 6, and 7 spans both children of root 1. Employee 2 is itself an ancestor of the final group. Example 2 employeeIds = [10,20,30,40,50,60] managerIds = [-1,10,10,20,20,40] queries = [[60],[60,50],[30,60]] return = [60,20,10] A singleton group returns 60. Employees 60 and 50 first meet at 20, while 30 and 60 first meet at root 10. Constraints 1 <= employeeIds.length == managerIds.length <= 100000. Employee IDs are unique integers from 1 through 1000000000. Exactly one entry of managerIds is -1; every other entry names an employee in employeeIds. The manager relationships form one connected acyclic rooted tree, and each manager has at most two direct reports. 1 <= queries.length <= 100000. Each query is non-empty, contains unique employee IDs, and every queried ID exists in the hierarchy. The total number of employee IDs across all queries is at most 100000.
Reported by candidates. Source: FastPrep
Pattern and pitfall
Map each ID to an index first, since IDs go up to a billion. Build children lists from managerIds, find the root, and run an iterative DFS to get Euler tour entry times and depths. Don't use recursion, because a chain of 100000 employees will blow the stack. The trick for a group: the LCA of many nodes equals the LCA of the node with the smallest entry time and the node with the largest entry time. So each query reduces to one min, one max, and one pair LCA. Do the pair LCA with binary lifting or a sparse table over the Euler tour. The common pitfall is folding pairwise LCAs across the group, which works but is slower and messier. Another pitfall is forgetting that a node is its own ancestor, so a singleton returns itself. If the live OA freezes you on the sparse table indexing, StealthCoder is the hedge that keeps you moving.
The honest play: practice the pattern, and have StealthCoder ready for the one you didn't see coming.
You can drill Lowest Common Manager for Employee Groups cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Built for the candidate who saw this exact problem leak two days before his OA and wondered if anyone had a play.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Google's OA.
Google reuses patterns across OAs. Built for the candidate who saw this exact problem leak two days before his OA and wondered if anyone had a play. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Lowest Common Manager for Employee Groups FAQ
What's the trick for this lowest common manager problem?+
Reduce each group to two nodes. Sort by DFS entry time, or just track the min and max entry time in the group. The LCA of those two nodes is the LCA of the whole group. Then answer that pair with binary lifting or an Euler tour sparse table.
How hard is this Google OA question really?+
Medium-hard. Plain LCA is a known pattern. The twist is the group version plus the 100000 limits, which rule out walking up parent pointers per query. If you know the min/max entry time idea, the code is short.
Why can't I just walk up the parents for each query?+
A skewed hierarchy can be 100000 deep. Walking up per employee is O(depth), and across all queries that can hit billions of steps. Preprocessing the fixed tree once gives O(log n) or O(1) per pair.
What edge cases break most solutions?+
Singleton groups, which must return that employee. A group where one member is an ancestor of the rest, which returns that member. Huge IDs that need an index map. And deep chains that crash recursive DFS, so go iterative.
How do I prepare for this in 48 hours?+
Write LCA with binary lifting from scratch twice. Then add the min/max entry time reduction for groups. Practice the ID-to-index mapping and iterative DFS. Test on a 100000-node chain so you know it doesn't overflow the stack.