Almost every knowledge graph project that fails does so for the same reason, and it is not technical. Nobody agreed what the entities were. Two departments both have “customer”, they mean different things by it, and the graph becomes the place where that disagreement finally has to be resolved — usually by an engineer with no authority to resolve it.

So the useful thing to screen for is not query languages. It is whether the candidate has navigated that argument and survived it.

Modelling the domain is the job

Ask how they decided what became a node, what became a relationship, and what became a property. It sounds abstract and it is the most consequential set of decisions in the project, because getting it wrong makes the questions you actually want to ask either awkward or impossible.

The instinct to listen for is starting from the questions rather than from the data. A graph designed to answer “which suppliers are exposed to this shipping route” looks different from one designed to answer “which of our customers are related to each other”, and a schema derived from whatever the source systems happened to contain usually answers neither well.

Follow up by asking what they got wrong and had to change. Graph schemas are painful to migrate once data and queries depend on them, and anybody who has been through a restructure will describe it as a lesson rather than a footnote.

Entity resolution is where the effort actually goes

This is the unglamorous heart of the work: deciding that the customer in the billing system and the customer in the support system are the same person, when the names are spelled differently and one has an old address.

Ask how they approached it. Good answers cover deterministic matching on strong identifiers first, probabilistic matching with a scored threshold for the rest, an explicit decision about what to do with the uncertain middle, and a way for a human to correct a bad merge — because a wrongly merged pair of entities is considerably worse than two unmerged ones and much harder to spot.

This is also where the project timeline is decided. An engineer who estimates the graph build without estimating entity resolution is going to be late, and a candidate who raises it before you do has built one of these.

Do you need a graph database, or just a graph?

A question worth asking candidates directly, because the honest answer is often no.

A dedicated graph database earns its place when the queries are genuinely about traversal — paths, cycles, how many hops between two things, patterns of connection you cannot express as a join. It earns nothing when the real workload is retrieving a record and its immediate relations, which a relational database does perfectly well and which most teams already run.

A candidate who says they have used a relational schema with recursive queries instead, and can explain when that was sufficient, is demonstrating judgement. One for whom every connected-data problem is a graph database problem will build you something requiring specialist operation for a workload that did not need it.

The current reason this role is being hired, and what it demands

A lot of present demand comes from combining graphs with language models: using structured relationships to ground answers, so a system can say something is true because a traversal supports it rather than because a model found it plausible.

That is a genuinely good use and it changes the interview. Ask how they got from a natural-language question to a graph query, and what they did when the generated query was wrong — a malformed traversal is easier to catch than a plausible-but-wrong answer, and turning that into a safe fallback is the engineering. Ask also how they decided what to put in the graph versus what to leave in a document index, because the answer “everything” is the expensive one. The RAG engineer guide covers the retrieval half of that pairing.

Four things a maintainable graph has

  • The schema is written down and owned. Not by the engineer — by somebody in the business who can settle what a customer is.
  • Ingestion is incremental and idempotent. Graphs are built from many sources on different schedules, and re-running a load must not duplicate relationships.
  • Provenance is stored. Which source asserted this relationship, and when. Without it, a wrong edge is untraceable and therefore unfixable.
  • Query performance is measured on the real shape. Traversals that are instant on a sample can be pathological at full scale, particularly through highly connected nodes.

The question to settle before anybody writes a schema

Ask who in the business will arbitrate a disagreement about a definition, and get a name. Not a committee, not a process — a person who can decide that a customer means this and not that, and make it stick across two departments who currently disagree.

If no such person exists, the graph project will stall at exactly the point where it becomes valuable, because the engineer will be asked to make a political decision dressed as a technical one. That is the most common way these projects die quietly, and it is worth discovering before you hire rather than in month three. A candidate who asks you this question in a first interview is showing you they have been there.

Rates, and the backgrounds worth taking seriously

Indicatively £75,000 to £110,000 permanent, with day rates from about £550. Around 110 UK employers mention knowledge graphs and roughly 100 name the best-known graph database, concentrated in pharmaceutical research, financial crime, defence and large-scale product catalogues.

Look for data modelling experience above all. Somebody who spent years designing relational schemas, or who has worked on master data management, frequently makes a better knowledge graph engineer than somebody whose experience is graph machine learning — because the hard part here is representing a domain faithfully, and that skill is older than any of the current tooling. Candidates from library and information science backgrounds are worth taking seriously for the same reason, and are routinely overlooked.