Hiring GraphQL Engineers in Singapore: the 7 Steps That Stop You Buying a Slow API in 18 Months

GraphQL hires go wrong in a distinctive way. The engineer you hired delivered quickly, the front-end team was delighted for two quarters, and then something shifted: pages got slower in ways nobody could attribute, the schema acquired fields no client used but nobody dared remove, and a performance question that would be trivial on a REST endpoint turned into an afternoon of archaeology. Nothing was done incompetently. The screen simply tested the wrong things, because the skills that make a GraphQL layer pleasant to launch are not the skills that make it survivable.

Step 1: Decide Whether You Actually Need GraphQL

This is a hiring step, not an architecture aside, because the most expensive GraphQL mistake is made before anybody is interviewed.

GraphQL earns its complexity in one situation: several clients need different shapes of the same underlying data, and the cost of maintaining a bespoke endpoint for each of them has become real. A mobile app that needs a thin payload, a web dashboard that needs deep nesting and a partner integration that needs something else again. That is the problem it was built for, and it solves it well.

If you have one web application consuming one backend, you are buying a caching problem, an observability problem and an authorisation problem in exchange for a flexibility you do not need. Standard HTTP caching stops working the way your team expects, every request looks identical to your monitoring unless you do extra work, and a per-endpoint permission model no longer maps onto anything. Those costs are real and they are paid by the team that inherits the system.

So write one paragraph justifying the choice before you open the requisition: who the clients are, how their needs differ, and what you currently pay for that difference. If the paragraph is hard to write, the honest outcome is that you need a good API engineer rather than a GraphQL specialist, and that is a cheaper and easier hire.

Step 2: Screen for the N+1 Problem With a Concrete Case

This is the highest-signal technical question available for this role, and it takes one sentence: a client requests fifty orders, each with its customer and its three line items. What happens to my database?

The naive resolver implementation issues a query per field per row. Fifty orders becomes one query for the list, fifty for the customers, fifty for the line item sets, and the pattern worsens every time a client adds a nested field. This is the N+1 problem, and it is the defining performance characteristic of the technology.

An engineer who has run GraphQL under load reaches for batching without prompting. They will describe collecting the identifiers needed during a resolution pass and fetching them in one query, name the data loader pattern, and give you a rough query count for both approaches. The better ones will add the uncomfortable part: batching helps per request, and it does not stop a client from writing a query that is simply too expensive, which is what step 5 is about.

A candidate who answers this in terms of resolver syntax, or who says the framework handles it, has built something that worked at demo scale. That is not a disqualification for a mid-level hire with supervision. It is a disqualification for anybody who will own the layer.

Step 3: Test Schema Design Judgement, Not Schema Syntax

Schema design is where the long-term cost of a GraphQL layer is actually set, and it is almost never screened for, because it looks like a matter of taste until the consequences arrive.

The exercise I use: show the candidate a schema whose types map one-to-one onto database tables, with foreign key relationships exposed as nested fields, and ask what they think. The answer worth hiring identifies that the schema is modelling storage rather than client use cases, and then explains what that costs: clients have to know your internal structure to ask for anything useful, every database refactor becomes a breaking API change, and once three teams depend on it you are no longer free to change your own tables.

The answer to be wary of is enthusiasm. A schema that mirrors tables looks elegant, it is fast to produce, and a candidate who praises it is telling you they have never had to change one while four client teams depended on it.

Step 4: Probe Authorisation at Field Level

Ask: any client can request any field in the schema. Where does authorisation live?

This question matters because the familiar answer is wrong. In a REST system, permissions often sit at the route, and the gateway can enforce much of it. In GraphQL there is typically one endpoint, so the gateway can tell you who is calling but not what they are about to ask for. A client can request a deeply nested path that reaches data the direct query would never have exposed.

Candidates with production experience push authorisation down into resolver middleware or into the data access layer, so a field cannot be resolved without the check running regardless of the path taken to reach it. They will usually mention that nested relationships are where leaks appear, because the parent object was authorised and the child quietly inherited that permission. If a candidate places authorisation entirely in the gateway, that is the answer, and it should change your assessment of their production exposure. Our page on API security engineers covers where this responsibility usually sits when the two roles are split.

Step 5: Ask About Cost Control and Abusive Queries

A GraphQL endpoint exposed to clients you do not control is an availability question. The flexibility that makes the technology attractive also means a single request can ask for an enormous amount of work, and a deeply nested query against a cyclic schema can be expensive enough to matter without anybody intending harm.

Ask what they put in place. Good answers include depth limiting, complexity scoring with a per-query budget, pagination required on list fields, timeouts, and persisted queries so that only known operations are accepted in production. The best answers include what they measured afterwards, because a complexity limit set without reference to real traffic either blocks legitimate queries or permits everything.

A candidate with no answer here has only ever served first-party clients on an internal network. That is common and it is fine for an internal tool. It is not fine for a public or partner-facing API, and the distinction should match the role you are filling.

Step 6: Run a Paid Schema Review, Not a Coding Test

For this role, replace the coding exercise. Pay for two to three hours in which the candidate reviews an existing schema, ideally a sanitised version of yours, and writes a short migration note: what they would change, in what order, and what would break.

This works better than a greenfield exercise for a straightforward reason. Nobody is going to hand this person a blank schema. They are going to inherit yours, with its inconsistencies and the two fields that exist because of a deadline in 2024. A review tests the skill the job actually requires, and it gives you something concrete to evaluate: can they identify the real problems, do they sequence changes by risk, and can they write about it in a way your front-end leads will understand?

Pay for it. In the Singapore market the senior engineers worth hiring are employed and decline unpaid multi-hour assignments, so an unpaid exercise does not filter for commitment, it filters out your strongest candidates. For the scoping side of this, our note on SaaS development in Singapore covers how to resource an API layer alongside feature delivery.

Step 7: Close With Deprecation Ownership Written Into the Role

The step almost everybody skips, and the one that determines whether your schema is still workable in three years.

GraphQL schemas grow monotonically by default. Adding a field is safe and easy, so fields get added. Removing one requires knowing which clients use it, persuading those teams to migrate, and waiting. Since nobody owns that process, nothing is ever removed, and in four years you have a schema where a meaningful share of fields are unused but unremovable because nobody can prove they are unused.

Write three things into the role. Who decides a field is deprecated. How client usage is measured, which requires per-field operation tracking to exist at all. And what authority this person has when a client team declines to migrate, because without an answer that question escalates to whoever is least busy rather than whoever should decide.

Then give them one measurable deliverable in the first thirty days: per-field usage visibility in place, or one deprecation carried end to end on a field nobody wants. Either establishes the pattern while the schema is still small enough to govern, and both are achievable without a quarter of platform work first.

FAQ: Hiring GraphQL API Engineers in Singapore