Neo4j — Traversals, Patterns & Common Query Shapes

A common, genuinely different question from "what's reachable" is "what's the shortest connection between these two specific nodes" — degrees of separation, the fewest introductions needed, the shortest chain of transactions between two accounts. Cypher's shortestPath() function, used inside a path assignment, answers exactly this:

MATCH path = shortestPath(
  (alice:Person {name: 'Alice'})-[:FOLLOWS*1..6]-(bob:Person {name: 'Bob'})
)
RETURN path, length(path);

shortestPath() finds the single shortest path (by number of relationships) between the two anchored nodes, stopping as soon as it does — it does not enumerate every possible path first and then pick the shortest, which is what makes it practical on large graphs where the number of all paths between two nodes could be enormous. Bounding the hop count (*1..6 here) is good practice: it gives Neo4j a hard limit on how far to search before concluding no path exists, instead of exploring indefinitely on a graph where Alice and Bob genuinely aren't connected.

Note the relationship direction was left unspecified (-[:FOLLOWS*1..6]-, no arrowhead) — that matches a :FOLLOWS relationship in either direction, useful when "connected to" matters more than "who followed whom first." Keep the arrow (->) when direction is actually part of what you're asking.

MATCH path = shortestPath(
  (alice:Person {name: 'Alice'})-[:FOLLOWS*1..6]-(bob:Person {name: 'Bob'})
)
RETURN path, length(path);

MATCH (me:Person {name: 'Alice'})-[:FOLLOWS]->(friend:Person)-[:FOLLOWS]->(candidate:Person)
WHERE candidate <> me
  AND NOT (me)-[:FOLLOWS]->(candidate)
RETURN candidate.name, count(*) AS mutualConnections
ORDER BY mutualConnections DESC
LIMIT 10;

The two WHERE conditions are both doing real work: candidate <> me throws out Alice herself (she's trivially two hops from herself via any friend who follows back), and NOT (me)-[:FOLLOWS]->(candidate) — a relationship pattern used directly as a boolean condition — excludes people she already follows, since recommending an existing connection isn't useful. count(*) then tells you how many separate mutual friends led to each candidate, which doubles as a genuinely reasonable relevance ranking: more shared connections, better recommendation.

The same shape, product-recommendation flavored, swaps Person/FOLLOWS for Person/PURCHASED/Product:

MATCH (me:Person {id: $userId})-[:PURCHASED]->(:Product)<-[:PURCHASED]-(other:Person)-[:PURCHASED]->(rec:Product)
WHERE NOT (me)-[:PURCHASED]->(rec)
RETURN rec.name, count(DISTINCT other) AS boughtByHowManySimilarCustomers
ORDER BY boughtByHowManySimilarCustomers DESC
LIMIT 10;

This is collaborative filtering, expressed as one readable pattern: people who bought what you bought, what else did they buy, that you haven't bought yet.

MATCH (me:Person {name: 'Alice'})-[:FOLLOWS]->(friend:Person)-[:FOLLOWS]->(candidate:Person)
WHERE candidate <> me
  AND NOT (me)-[:FOLLOWS]->(candidate)
RETURN candidate.name, count(*) AS mutualConnections
ORDER BY mutualConnections DESC
LIMIT 10;

Cycles are a direct pattern match — a variable-length path that starts and ends at the same node:

MATCH (a:Account)-[:TRANSFERRED_TO*3..6]->(a)
RETURN a.accountId;

This finds every account that's part of a money-transfer chain of 3 to 6 hops that eventually loops back to itself — a classic layering pattern used to obscure where money originally came from. A relational equivalent would need a recursive CTE (SQL Mastery, Chapter 10) checking, at every level of recursion, whether the current row's account matches the starting row's account — expressible, but noticeably more code for the same idea, and without the fixed-cost-per-hop traversal from Chapter 01.

Shared-attribute rings are a group-then-filter pattern: group by the shared attribute, and keep only the groups above a suspicious size.

MATCH (a:Account)-[:USES_DEVICE]->(d:Device)
WITH d, collect(a) AS accounts
WHERE size(accounts) > 3
RETURN d.deviceId, size(accounts) AS accountCount;

WITH here pipes the grouped-by-device results forward so WHERE can filter on the aggregate (size(accounts), built from collect()) — the same role HAVING plays after a GROUP BY in SQL, just expressed as a forward-piping clause rather than a dedicated post-aggregation keyword.

MATCH (a:Account)-[:TRANSFERRED_TO*3..6]->(a)
RETURN a.accountId;

Neo4j ships this class of analysis as a separate graph algorithm library — the Neo4j Graph Data Science (GDS) library — rather than as Cypher clauses. Conceptually, it covers two broad families worth being able to name in an interview:

• Centrality algorithms (PageRank-style) — score every node by how "important" or well-connected it is within the graph, useful for ranking influential accounts, key intermediaries in a payment network, or hub products in a purchase graph.
• Community detection algorithms (Louvain-style) — group nodes into densely-interconnected clusters, useful for surfacing fraud rings that don't form an obvious direct cycle, or for finding natural segments in a social or purchase graph.

The practical shape of using GDS: you first project the relevant slice of your graph into an in-memory, analytics-optimized structure, rather than running the algorithm directly against your live transactional graph, run the algorithm against that projection, then write the results back or stream them out. The exact procedure syntax is version-specific and worth looking up directly in Neo4j's GDS documentation when you need it — the interview-relevant takeaway is knowing this class of whole-graph analysis exists, is a genuinely different tool from pattern-matching Cypher, and roughly which family (centrality vs. community detection) fits which question.