A dependency graph explorer is an evidence browser. It helps someone answer what this entity uses, what uses it, why a path exists, and whether the answer is complete. The picture is only one projection of that evidence.
A small demo can fetch a list of nodes and edges, run a force layout, and draw everything. A production explorer faces much harder questions. Is the graph a complete snapshot or a partial neighborhood? Did a filter hide the connecting node? Does a cycle represent a real architectural knot or a data error? Can a late layout move the selected package after the user opens its details? Is an absent service genuinely unrelated, unauthorized, or simply not loaded yet?
Start with graph identity, query scope, and completeness. Layout comes later.
Clarify the dependency domain
Assume the explorer serves software packages, repositories, services, APIs, data jobs, and deployable artifacts. An entity may have several versions and environments. Edges have direction, kind, provenance, observation time, and confidence. Users can focus an entity, expand dependencies or dependents, find paths, compare snapshots, filter by type or owner, inspect cycles, collapse clusters, pin nodes, share a URL, export evidence, and open source records.
Ask whether edges mean declared dependencies, resolved versions, runtime calls, ownership, deployment ordering, or several typed relations. Clarify the largest logical graph, expected focus-neighborhood size, graph freshness, snapshot consistency, permissions, redaction, live updates, mobile scope, export policy, and accessibility requirements.
These answers decide what an empty region means. A rendering library cannot tell complete absence from unavailable evidence.
The public interview prompt
Design a browser-based dependency graph explorer. Explain:
- stable identities for graph snapshots, entities, versions, environments, dependency edges, evidence, clusters, and layout generations;
- progressive upstream and downstream neighborhood queries, pagination, deduplication, cancellation, retries, completeness, truncation, and stale-response guards;
- adjacency indexes, path search, reverse dependencies, strongly connected components, cycle condensation, cluster membership, and typed relations;
- focus, selection, pinning, comparison, filters, hidden connectors, semantic zoom, minimaps, URL state, and navigation history;
- layout workers, deterministic seeds, anchor preservation, incremental repair, viewport culling, edge simplification, hit testing, Canvas or WebGL rendering, and context loss;
- accessible outlines, treegrid navigation, announcements, keyboard actions, focus restoration, reduced motion, high zoom, and international labels;
- permissions, redaction, caching, exports, observability, testing, degraded modes, performance budgets, and rollout.
What the premium solution covers
The full solution separates graph evidence from the loaded neighborhood, condensed graph, layout projection, viewport paint, selection, and URL state. It follows one focus expansion from query receipt through merge, cycle condensation, worker layout, anchor-preserving commit, and semantic rendering.
Original teaching media includes a frame-verified focus-neighborhood lifecycle, an ownership map, a cycle-condensation receipt, and a focus-context accessibility contract. A deterministic projection budget lab lets readers vary logical size, density, loaded scope, visible scope, layout cost, and paint cost without needing a graph backend.