GraphQL interview questions

The N+1 problem, the central question

A query for 50 posts each with an author naively issues one query for posts and 50 for authors. Every serious GraphQL conversation reaches this.

• DataLoader - batching requests within a tick and caching per request. Be able to explain both halves.
• Why is the DataLoader cache per-request rather than global? Staleness and cross-user data leakage.
• Alternatives: joining in the resolver, or a query-planning layer.
• How would you even detect this? Logging the SQL a single GraphQL query generates.

Schema design

• Nullability - why making everything non-null is risky, since one failure can null out a whole branch.
• Pagination, and why cursor-based beats offset for large or changing sets. Expect the Relay connection shape.
• How do you evolve a schema without versioning? Add fields, deprecate rather than remove.
• Interfaces and unions, and when each fits.
• Where does an error belong - the errors array, or modelled as a result union? A real design opinion question.

Performance and security

• Caching is harder than REST - one endpoint, POST by default, so HTTP caching does not apply. Persisted queries and client-side normalised caches are the usual answers.
• Query depth and complexity limiting - a public GraphQL API without them is a denial-of-service waiting to happen.
• Introspection in production - whether to disable it, and the honest note that it is obscurity rather than security.
• Authorisation at the field level, and why putting it in resolvers scatters it.
• Rate limiting when one request can cost wildly different amounts.

The comparison question

"REST or GraphQL?" The answer interviewers want is conditional: GraphQL earns its complexity when many clients need different shapes of the same data, or when mobile round-trips are expensive. REST stays better when responses are cacheable at the edge, when the API is small, or when the team has no appetite for the operational overhead. Related ground is in REST API interview questions.

How deep it goes by level

• Junior: the fundamentals above, explained clearly. Nobody expects production scars yet, and saying what you have not done reads better than bluffing.
• Mid-level: the same ground plus a schema you have shipped and evolved. Expect follow-ups asking why you made a choice rather than whether you know the syntax.
• Senior: federation or a gateway at scale, and the authorisation model you chose. The recall questions get shorter and the judgement questions get longer.

Whatever the level, say your answers out loud rather than reading them. Most of what candidates lose in a GraphQL interview is lost between knowing something and explaining it under observation - the method is in how to use AI for interview prep.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

What are the most common GraphQL interview questions?

The N+1 problem and how DataLoader solves it, cursor-based pagination, schema evolution without versioning, why caching is harder than with REST, and query depth or complexity limiting on a public API.

What is the N+1 problem in GraphQL?

A nested query issues one database call for the parent list and then one per item for the child field - 50 posts with authors becomes 51 queries. DataLoader solves it by batching the child lookups within a tick and caching them for the duration of the request.

Why is caching harder in GraphQL than REST?

REST gives you distinct URLs that HTTP caches and CDNs can cache natively. GraphQL typically posts every query to a single endpoint, so that layer is unavailable. Teams compensate with persisted queries, normalised client caches, and server-side caching at the resolver level.

When should you not use GraphQL?

When responses are highly cacheable at the edge, when the API is small and has one client, or when the team cannot absorb the operational overhead of complexity limiting and field-level authorisation. Being able to argue this is viewed positively.