GraphQL interview
questions and jobs, 2027

GraphQL lets clients request exactly the data they need from a typed schema in one round trip.¹² It's popular at product companies with several clients — web, Android, iOS — that need different shapes of the same data, and at companies stitching many services into one API layer. It's common in e-commerce, social, media and SaaS products.

Because GraphQL puts query flexibility in clients' hands, interviews focus on what servers must do in return: efficient resolvers, pagination, authorisation and limits. GraphQL usually sits inside back-end and full-stack roles; back-end developers in India typically earned ₹10.6–11.7 lakh on AmbitionBox in October 2026.⁶

Fetches nested data for a whole screen

1 request

The classic GraphQL performance bug

N+1

Typical back-end developer pay in India (AmbitionBox, Oct 2026)

₹10.6–11.7 lakh

Good GraphQL schemas evolve by addition and deprecation

0 versions

Table: How GraphQL is tested (editorial summary)

// Without batching: one query per restaurant
const resolvers = {
  Restaurant: {
    rating: (r, _, { db }) => db.ratings.findOne({ restaurantId: r.id }),
  },
};

// With batching: one query for all restaurants in the request
const ratingLoader = new DataLoader(async (ids) => {
  const rows = await db.ratings.findMany({ restaurantId: { in: ids } });
  const byId = new Map(rows.map((row) => [row.restaurantId, row]));
  return ids.map((id) => byId.get(id) ?? null); // same order as ids
});

const batchedResolvers = {
  Restaurant: { rating: (r) => ratingLoader.load(r.id) },
};

Explain: the loader collects every restaurant ID requested during one tick, fetches them in a single query and returns results in the same order as the keys. Create loaders per request so data isn't shared between users.

"GraphQL vs REST?"

GraphQL: flexible queries, one endpoint, typed schema, fewer round trips — but harder HTTP caching and more server complexity. REST: simple, cacheable, widely understood.

"How do you paginate?"

Cursor-based connections: first/after arguments, edges with cursors and pageInfo with hasNextPage.

"How do you handle errors?"

Partial data with an errors array for field failures; typed error results (unions) for expected business errors such as "insufficient balance".

"How do you prevent expensive queries?"

Depth and complexity limits, pagination limits, timeouts, rate limiting and persisted queries for first-party clients.

"Where should authorisation happen?"

In the business layer the resolvers call, checked per object or field — not only at the gateway.

"How do you change a field's type safely?"

Add a new field, mark the old one @deprecated, migrate clients, then remove it after usage drops.

"What is federation?"

Composing several teams' GraphQL services into one supergraph, each owning part of the schema.

"How do you cache GraphQL?"

Client-side normalised caches, per-request DataLoader caching, response caching for persisted queries, and CDN caching with GET for public queries.

Table: How GraphQL adoption has changed (editorial summary)

1. Build an API — A GraphQL server over a real database with three related types.
2. Measure N+1 — Log queries, add a loader, compare counts.
3. Paginate — Implement cursor-based connections.
4. Add limits — Depth and complexity limits; test with an abusive query.
5. Evolve the schema — Deprecate a field and migrate a client.

Table: Roles using GraphQL and typical pay in India (AmbitionBox, October 2026; indicative)

1. Week 1: Basics — Schema, queries, mutations, fragments; the official Learn pages.
2. Week 2: Server — Resolvers over a database; DataLoader; errors.
3. Week 3: Production — Pagination, auth, limits; read OWASP's GraphQL cheat sheet.
4. Week 4: Prove it — Take the GraphQL Fundamentals Certification.

Related: API Design and Integration and Back-End Development.

• Schema reviews — discussing new types and fields with front-end and mobile teams before anyone writes a resolver.
• Resolver performance — reading query logs, adding loaders and fixing slow fields that one screen depends on.
• Client collaboration — helping app developers write efficient queries and fragments, and spotting over-fetching.
• Deprecations — tracking which clients still use old fields and planning their removal.
• Security limits — tuning depth and complexity limits after a client ships an expensive query.
• Federation work — coordinating schema ownership with other teams in a shared supergraph.

• Do you use GraphQL alongside REST, and how do you decide which to use?
• How is the schema governed — who approves changes?
• How do you monitor resolver performance and expensive queries?
• Are you federated, and which team owns which part of the graph?
• How do mobile clients handle schema changes between app versions?

"What are fragments?"

Reusable sets of fields that components declare and compose into queries, keeping data requirements next to the UI that needs them.

"Queries vs mutations vs subscriptions?"

Queries read data, mutations change it (executed in order), and subscriptions push updates to clients over a long-lived connection.

"How do you handle file uploads?"

Usually outside GraphQL: upload to object storage with a signed URL, then pass the file reference in a mutation.

"How do you test a GraphQL API?"

Unit-test resolvers and business logic, run integration tests against the schema with real queries, and check performance with query-count assertions.

Interviewers often ask candidates to choose, and the best answers are specific about context rather than loyal to a technology.

GraphQL tends to win when many clients — a web app, an Android app, an iOS app, a partner integration — need different slices of the same rich data, when screens combine data from several services, and when a team wants a single typed contract that front-end developers can explore. It also helps mobile apps on slow networks by avoiding several round trips per screen.

REST tends to win for simple resource APIs, public APIs where HTTP caching and familiar semantics matter, file transfers, webhooks, and teams without the capacity to run a GraphQL layer well. Many organisations run both: REST for public and service-to-service APIs, GraphQL as a backend-for-frontend that aggregates them for their own apps.

Whichever you choose, the same disciplines apply: clear naming, consistent errors, pagination, authorisation on every object, observability and careful evolution.

• Ignoring N+1.
• Unlimited query depth.
• Authorisation only at the gateway.
• Offset pagination on large lists.
• Versioning the schema instead of evolving it.

Technical references are the GraphQL Foundation's Learn pages and specification, the DataLoader project and OWASP's GraphQL cheat sheet; pay from AmbitionBox (read October 2026). Test formats and the history table are editorial summaries. Science of Apps publishes the free certification linked here. Last reviewed October 2026.

• Schema — the typed description of everything a GraphQL API offers.
• Resolver — a function that returns the data for a field.
• N+1 problem — one query for a list plus one per item.
• DataLoader — a utility that batches and caches loads within a request.
• Federation — composing multiple GraphQL services into one graph.