5 exercises — choose the best-structured answer to common GraphQL Developer interview questions. Focus on schema design precision, DataLoader mechanics, Federation architecture, and production schema evolution vocabulary.
Structure for GraphQL questions
Name the pattern: Connection/Edge, DataLoader, @key directive, persisted queries
Explain the why: cursor vs. offset pagination, Federation vs. stitching criteria
Production awareness: per-request DataLoader instantiation, schema registry CI gate
The interviewer asks: "Walk me through how you would design a GraphQL schema for a social media feed. What are the key design decisions?" Which answer best demonstrates schema design thinking?
Option B is the strongest: it names five concrete design decisions with vocabulary (the Connection pagination pattern, federation boundary, union type, non-null semantics, subscriptions), explains why each decision was made (cursor pagination is stable under inserts; non-null for invariant "must have author"), and uses correct GraphQL SDL notation. Option C is correct and Relay spec compliance is a valid architectural choice — but it doesn't explain the reasoning behind individual decisions, which is what the interviewer is testing. Option A is basic and doesn't demonstrate design depth. Option D is answering a different question (REST vs. GraphQL). Key structure: pagination strategy → type relationships → nullability semantics → real-time approach → explain each choice.
2 / 5
The interviewer asks: "Explain the N+1 problem in GraphQL and how DataLoader solves it." Choose the most complete and technically accurate answer.
Option B is strongest: it quantifies the problem (50 posts = 51 queries), explains both DataLoader mechanisms (batching and per-request caching with their precise behaviour), uses correct SQL notation (IN ()), and includes the critical implementation warning (per-request instantiation). The per-request instantiation issue is a real production mistake — cross-request caching leaks user data. Option D is technically valid (JOINs can work) but doesn't answer the question asked about DataLoader and is impractical for deeply nested or federated schemas. Option C is accurate but shallow — it describes the API without explaining the batching mechanism or the caching caveat. Option A is the basic correct answer but lacks the depth expected of a GraphQL developer. Key tip: batching (event loop tick → one query) + per-request caching + instantiate DataLoader per request.
3 / 5
The interviewer asks: "What is Apollo Federation and when would you use it instead of schema stitching?" Which answer best demonstrates architectural knowledge?
Option B is strongest: it explains the fundamental architectural difference (gateway-level vs. subgraph-level composition), identifies the key coupling problem with schema stitching, explains @key and __resolveReference's role, and gives concrete criteria for choosing each — including a fair statement of when schema stitching is acceptable. Binary "always use X" answers (like Option C) demonstrate lack of nuance. Option D is accurate but only describes Federation's mechanics, not why you would choose it. Option A is correct but minimal. Key structure for architectural comparison questions: explain the fundamental difference → identify the coupling/decoupling axis → give clear criteria for choosing each → know when the "older" option is still valid.
4 / 5
The interviewer asks: "How do you protect a GraphQL API from abusive queries — like deeply nested queries or queries that fetch millions of records?" Choose the best defensive strategy.
Option B is strongest: it identifies the unique attack surface of GraphQL (arbitrary query shapes), then describes five specific, named defences — depth limiting, cost analysis, persisted queries, pagination maximums, and disabling introspection. Each defence addresses a different threat vector. Persisted queries in particular is a production-grade pattern that most REST developers are unfamiliar with. Option D is a reasonable REST-API-style answer, but rate limiting by request count doesn't account for the fact that one GraphQL request can be 1,000x more expensive than another. Option C describes observability, not defence. Option A is incomplete — authentication and gateway rate limiting are necessary but don't address query-shape abuse. Key structure: identify the unique attack surface → depth limiting → cost analysis → persisted queries → pagination limits → disable introspection.
5 / 5
The interviewer asks: "What happens when you need to make a breaking change to a GraphQL schema in production? How do you manage schema evolution?" Which answer best demonstrates production experience?
Option B is strongest: it states the core GraphQL philosophy (no versioning by URL), provides a structured 5-step evolution process using correct vocabulary (@deprecated directive, monitor field usage, argument evolution rules, type migration with parallel fields), and names the schema registry tooling (Apollo schema checks) that enforces this automatically in CI. This demonstrates real production experience — the field usage monitoring step, in particular, is a discipline that distinguishes engineers who have managed a public GraphQL API from those who haven't. Option D is partially correct (introducing parallel types/fields is the right technique) but doesn't cover the deprecation discipline, usage monitoring, or CI safety gates. Option C is the announcement model — it works for internal APIs but fails at scale with multiple client teams. Option A (URL versioning) is explicitly discouraged in GraphQL architecture. Key tip: @deprecated → monitor usage → parallel fields for type changes → schema registry CI gate — no /v2.