This is a verified interview question from Lseg---london-stock-exchange. Candidates reporting seeing this problem in recent Online Assessments (OAs) and onsite rounds. Mastering "Dependency Graph Impact (Bugfix) - LSEG London Stock Exchange Online Assessment RNS Institute" covers key patterns like Arrays.
"Pattern : It consists of 7 Tasks 4 DSA, 2 Debugging(coding based) and 1 MCQ --- ### Bugfix Given a list of service dependencies `(service, depends_on)` pairs, a service is **blocked** if it is part of a dependency cycle, or if it depends (directly or indirectly) on a service that is part of a cycle. `solution` must return the sorted list of blocked services. **Rules**: the same pair may appear more than once (duplicate edges — no effect on result). A service may depend on itself directly (a cycle of length 1). A service that never appears as the first element of any pair has no outgoing dependency and can never be part of a cycle. Output: blocked services, no duplicates, sorted ascending by byte value (plain ASCII order — `"10"` before `"9"`, uppercase before lowercase). **Constraints**: 0 ≤ length(dependencies) ≤ 2,000; each service name is 1–50 whitespace-free characters. **Bug found in given stub**: In a DFS-based cycle detector using `visiting`/`visited`/`cycleNodes` sets, when a node is already fully processed (`visited`), the buggy code did `return false` unconditionally — losing the information that this node might already be part of a cycle. This causes nodes that depend on an already-processed cyclic node (via a different entry point) to be wrongly reported as *not* blocked. **Fix**: `if (visited.count(node)) return cycleNodes.count(node) > 0;` instead of `return false;` ---"
Join thousands of developers practicing for Lseg---london-stock-exchange.