Hire senior GraphQL engineers in your time zone.

A senior GraphQL engineer owns the schema as a product, not just an implementation detail. They decide how types map to your domain, which fields are nullable, and how the schema evolves without breaking clients that are already deployed and out of your control.

Resolver performance is their responsibility too. Naive resolvers can trigger the N+1 query problem, one query becomes hundreds against your database. A senior engineer reaches for DataLoader or equivalent batching to keep resolvers fast without pushing that complexity onto every consumer of the API.

Authorization in GraphQL happens at the field level, not just the endpoint level, since a single query can touch many types. Getting this right means building authorization checks into the schema itself rather than bolting them on after the fact.

They also guard the API against abuse: query depth limiting, complexity analysis, and rate limiting matter more in GraphQL than REST, since a single malicious query can request an enormous amount of nested data.

Most production GraphQL runs through Apollo Server or a similar runtime, often embedded inside a broader framework like NestJS, Express, or a Python equivalent. A candidate should know the server layer they will actually work in, not just the specification.

On the client side, Apollo Client and its cache normalization is the most common pairing, though frameworks like Next.js and React increasingly wrap GraphQL calls in their own data fetching patterns. Understanding how the client caches and refetches data affects how a schema should be designed.

For teams operating at scale, Apollo Federation is worth probing directly: how a candidate has split a schema across services, and how they handled the tradeoffs of a distributed graph versus a single monolithic schema.

Finally, look for comfort with the databases and services sitting behind the schema, PostgreSQL, MongoDB, or existing REST services, since a GraphQL layer is only as good as the resolvers connecting it to real data.

Start with a schema they designed themselves. Ask why they chose the types and relationships they did, and what they would change if a new client requirement came in tomorrow. Good answers reference tradeoffs, not just syntax.

Ask directly how they have solved the N+1 problem in a real resolver. If the answer stops at "we use DataLoader" without explaining when and why, dig further into whether they understand the underlying batching mechanics.

Authorization is a good filter question too: ask how they restrict access to specific fields versus entire types, and how that logic stays maintainable as the schema grows.

BetterEngineer already runs this kind of evaluation, schema walkthroughs, resolver performance questions, and authorization design, before a candidate ever reaches your calendar, so the profiles you see have already cleared this bar.

Quick evaluation checklist:

• Ask for a schema they designed and why they modeled types the way they did
• Review how they solve the N+1 query problem, DataLoader or otherwise
• Check how they handle authorization at the field level, not just the endpoint
• Probe query complexity and depth limiting for public-facing APIs
• Assess experience with schema evolution without breaking existing clients