Graph Neural Network Interview Questions: Message Passing, Neighbor Sampling, and Leakage

A graph neural network (GNN) interview answer should trace which information reaches a target, through which connections, and when. One message-passing layer combines a node's representation with its neighbors; two layers can use two-hop context. Neighbor sampling limits computation, but changes each batch's context. A model can look excellent offline if its graph contains future edges, label-derived features, or the edge it must predict. The split protocol is part of the model.

The worked graph and exercises below are original practice, grounded in the GCN and GraphSAGE papers plus current PyTorch Geometric documentation. They are not claims about a particular employer's interview. For a production-flavored follow-up, Design Self-Dealing Detection for Marketplaces asks where a graph model might fit in fraud detection.

Question 1: What does one message-passing layer compute?

Start with nodes, edges, features, and a task. In a buyer–seller graph, an edge may mean a purchase; in a citation graph, one paper cites another. An edge's meaning and direction determine message flow. At layer l, a node receives transformed neighbor representations from layer l-1, aggregates them with a permutation-invariant operation such as sum or mean, and updates its representation. Learned weights and a nonlinearity usually follow. This is an architecture pattern, not one universal formula.

The GCN paper uses normalized graph propagation with self-connections in a specific formulation. GraphSAGE learns an inductive function by sampling and aggregating neighbors; it is useful when new nodes may arrive. Do not describe all GNNs as simple neighbor averaging. Attention, relation-specific weights, edge attributes, and direction choices alter the computation. The interview answer should state the particular layer you are analyzing before calculating it.

For a tiny illustration, use an intentionally simple unweighted mean including self, with no learned weight or activation. Let the undirected edges be A–B, A–C, B–D, and C–E. Initial scalar features are A=2, B=4, C=8, D=10, and E=6. The first-layer value at A is the mean of its own feature and those of B and C: (2+4+8)/3 = 14/3. At B, it is (4+2+10)/3 = 16/3; at C, (8+2+6)/3 = 16/3.

In a second synchronous layer, A aggregates the first-layer values of A, B, and C: (14/3 + 16/3 + 16/3)/3 = 46/9. Now D and E can affect A via B and C, even though neither is directly adjacent to A. This arithmetic is a teaching model, not the normalized GCN update or a trained GraphSAGE network. It makes receptive field and layer order concrete.

Node	Initial feature	First-layer mean	Relevance to target A
A	2	14/3	Self contribution
B	4	16/3	Direct neighbor; carries D in layer two
C	8	16/3	Direct neighbor; carries E in layer two
D	10	Not needed for this calculation	Two-hop input through B
E	6	Not needed for this calculation	Two-hop input through C

If the interviewer asks about directed edges, recompute the neighborhoods according to the specified direction. Adding reverse edges without justification changes what information can reach A.

Question 2: Why sample neighbors, and what does the sampler return?

A full two-hop neighborhood can grow quickly around high-degree nodes. With a fanout of at most k per hop and L hops, a crude per-seed upper bound is on the order of k^L sampled paths; shared nodes and duplicate removal can lower the actual count. A fanout such as [15, 10] means sample up to 15 first-hop neighbors and up to 10 for each sampled first-hop node, not “use 15 layers.” More fanout may improve coverage but increases memory, I/O, and batch time. It does not automatically yield an unbiased estimate of a full-neighborhood model under every aggregator.

PyTorch Geometric's NeighborLoader tutorial distinguishes seed nodes (the examples whose labels contribute to loss) from context nodes sampled to supply messages. input_nodes selects seeds; num_neighbors sets per-hop fanout. In returned batches, batch.n_id maps sampled local node indices back to original IDs, and the first batch.batch_size nodes are the seeds in the documented loader behavior. The tutorial computes loss on the seed slice, not every context node's label. That distinction prevents an accidental training objective on neighbors added solely for context.

Sampling is also a modeling decision. A uniform sampler may underrepresent rare but important edge types or time-sensitive contacts. In a heterogeneous fraud graph, you might set different fanouts for buyer–device and buyer–seller relations, or use a method that preserves recent edges. Measure accuracy and runtime across fanouts; keep evaluation deterministic enough to compare candidates. A two-layer model should receive the graph structure required by its two rounds of propagation. Sampling extra hops that the model cannot use wastes work.

Question 3: Can you trace a sampled batch by hand?

Return to target A. Suppose a two-hop sampler picks only B from A's first-hop neighbors, then D from B's neighbors outside the seed path. The sampled support includes A, B, and D, while the full two-hop neighborhood also contains C and E. The target's sampled computation cannot use information from C or E in that draw. A different sample might select C and E instead. The model's parameters are shared across batches, but the local evidence changes.

Be precise about the subgraph edge set. Depending on loader configuration, sampling returns directed computation edges, bidirectional edges, or an induced subgraph among sampled nodes. These choices can affect whether a deeper model sees the intended messages. The current PyG tutorial calls this out: its default directed subgraph is aligned to the chosen hop depth, while other subgraph types change the message flow. Inspect edge_index and the original-ID mapping; do not assume the diagram you drew is exactly what the batch contains.

When training loss falls but validation does not, log seed count, sampled nodes and edges by hop and relation, degree distribution, randomness, feature freshness, and cold-start performance. Sampling can save memory while obscuring a rare-neighbor signal; increasing depth or fanout needs testing.

Question 4: Is seeing a validation node through an edge leakage?

It depends on the declared task. In a transductive node-classification benchmark, the graph structure and unlabeled features of validation/test nodes may be available during training, while their labels are withheld. A training seed can aggregate from an unlabeled test neighbor if that topology and feature are permitted by the protocol. Calling every cross-split edge “leakage” would misdescribe this setting. In an inductive setting where validation nodes or an entire graph are unseen at training time, allowing their topology or features into the training graph violates the intended split.

The safe question is: “At prediction time, what nodes, edges, features, and labels could the system really know?” Split seed labels before fitting scalers, target encoders, or embeddings that use labels. Recompute any graph feature according to that split. A “fraud-neighbor count” derived from confirmed labels that arrive later is a future-label leak even if the edge itself already existed. Conversely, a historical shared-device edge may be a legitimate predictor if it existed before the decision.

Do not confuse message passing with GraphRAG retrieval. A GNN learns representations and parameters over graph-structured training examples; GraphRAG retrieves graph facts as context for a generative answer. Both use relationships, but their training objectives, evaluation, and leakage surfaces differ. This post concerns the learned GNN's information boundary.

Question 5: What is edge leakage in link prediction?

Suppose the label is whether buyer U will transact with seller S next week. If the very U–S future transaction edge is present in the graph used for message passing, a link predictor may simply observe what it is supposed to predict. Remove held-out target edges from the training message graph and construct historical features as of each prediction cutoff. PyG's LinkNeighborLoader documentation warns that supervision edges are not automatically masked from sampled message-passing edges when the two sets overlap. Use a genuinely disjoint edge setup when the task requires it.

That does not imply deleting every relationship between U and S. If the task is predicting a new transaction and older transactions between them are known, those historical edges may be legitimate features; the target event itself is not. Write the target as a time-stamped event, define which prior edges can remain, and avoid collapsing a multigraph into a binary edge that accidentally includes the future transaction.

Negative sampling has its own trap. A pair labeled negative because no edge appears in a partial observation window may later become positive. Specify the observation and maturation window; exclude pairs with unknown status or evaluate the consequences of approximate negatives. A sampler that looks at the complete future graph to filter negatives may also convey information unavailable at decision time. The Open Graph Benchmark link-prediction documentation provides an example of a chronological collaboration split: earlier edges train the model, later edges are held out to predict future relationships.

Question 6: How do you audit time leakage in a production graph?

Create a timeline for every input. For a prediction at 2026-04-01 09:00, ask whether a node feature was measured by then, whether an edge had occurred and been ingested by then, and whether a label had matured. Event time alone may not suffice if ingestion is delayed. A graph snapshot built from all data available today can contain future transactions even when the training row's timestamp is in March.

Data item for a March prediction	Allowed if known by cutoff?	Audit question
Buyer–device edge observed in February	Usually yes	Was it ingested before prediction?
Chargeback label finalized in May	No	Did a neighbor-risk feature use it?
Seller account metadata revised in April	No, unless historical version exists	Did the join use an as-of snapshot?
Future buyer–seller transaction being predicted	No	Is target edge in message graph?
Unlabeled validation node in a transductive benchmark	Protocol-dependent	Does the benchmark allow topology and features?

This is an original as-of audit, not a universal ban on transductive evaluation. Lock a train/validation/test timeline, materialize graph snapshots as of each cutoff, and keep supervision edges out of the message graph where required. Rebuild graph-derived features separately for each fold if they depend on labels or future edges. A random node split on a dynamic commerce graph often gives an easier task than forecasting genuinely future events.

Question 7: When is a GNN worth deploying?

Begin with a baseline: degree and recency features, shared-device counts, or a simple tabular model. Then ask whether learned multi-hop structure adds value at the actual operating point—such as precision at a fixed review budget—after accounting for inference latency, graph freshness, sampling cost, and explainability. A large offline AUC gain is weak if it came from a future-edge leak or if serving cannot assemble the required neighborhood before the decision deadline.

For a fraud case, a two-stage design can compute historical graph features offline or nearline, generate a small high-recall candidate set, and reserve a GNN reranker for cases where the graph signal is likely to matter. For recommendations, graph embeddings can complement content-based retrieval, especially when interaction history is useful; cold-start items still need non-graph paths. These are architecture options to validate, not automatic prescriptions.

When an interviewer asks why the model underperforms on new users, separate missing neighbors from a flawed sampler and from label delay. Report metrics by degree, age of account, edge type, and data freshness. Change one variable at a time: fanout, relation features, temporal snapshot, or baseline. A clean leakage audit may reduce the headline metric while making the result credible.

Sources and further reading

• Kipf and Welling, Semi-Supervised Classification with Graph Convolutional Networks — primary GCN formulation.
• Hamilton, Ying, and Leskovec, Inductive Representation Learning on Large Graphs — primary GraphSAGE sampling and aggregation work.
• PyTorch Geometric NeighborLoader tutorial — seed nodes, fanouts, local IDs, and subgraph behavior.
• PyTorch Geometric loader reference — LinkNeighborLoader edge-overlap warning.
• Open Graph Benchmark link prediction datasets — task-specific and chronological split examples.