The reason to hire specifically for LlamaIndex rather than for a general AI application engineer is that this framework is organised around the data rather than around the model. Its abstractions are about loading, parsing, splitting, indexing and querying documents, and that is a fair description of where retrieval projects actually succeed or fail.

So the hire is closer to a data engineer who understands language models than to a model specialist who happens to handle documents. Getting that the wrong way round is the most common error in these searches.

The work is mostly upstream of anything intelligent

Ask anybody who has shipped a document assistant where their time went, and the answer is rarely the model. It is the PDFs.

Specifically: a scanned contract with two columns and a signature block, a spreadsheet exported as a PDF, a slide deck where the meaning is in the diagram, a document whose headings are visual rather than structural. Extraction from those is unglamorous, fiddly and determines the ceiling on everything downstream, because a chunk that has lost its heading has lost the context that made it answerable.

A candidate who understands this will talk about the documents before they talk about embeddings. One who does not will describe a pipeline that assumes clean text, and will discover the real problem in week three of your project rather than in the interview.

Screening questions about ingestion, which is where the difficulty lives

“How would you handle a 200-page contract where the answer depends on a definition twelve pages earlier?” This is the central problem of document retrieval and there is no clean answer, which is why it discriminates. Strong candidates reach for hierarchical or parent-child indexing, keeping a summary alongside each chunk, or including surrounding context in what gets embedded. Weak candidates make the chunks bigger and hope.

“What breaks when the same document is uploaded twice with one paragraph changed?” You are testing for document identity, deduplication and incremental indexing. Anybody who has run a live corpus has been bitten by this, because the naive answer doubles your index and starts returning two nearly identical passages for every query.

“Which of the framework’s index types have you actually used in production, and which did you abandon?’’ The library offers a lot of them, and most real systems settle on one or two. An honest answer names what was tried and discarded; a memorised list of everything available suggests the documentation rather than experience.

The overlap with the other framework, addressed honestly

You will see both on the same CVs, and you should ask about it directly, because the answer tells you how the person thinks about tooling.

The broad division is that one framework is organised around orchestration — chaining calls, tools, agents — and this one around the data layer. In practice many teams run both, or start with one and grow a thin layer of their own. The reasonable engineer describes that without much ceremony. Somebody who is tribal about it is telling you they have used one thing, and our LangChain developer guide asks the mirror-image question.

The trap in either case is hiring for the library rather than for the problem. If your difficulty is retrieval quality across a large messy corpus, the framework is an implementation detail and the relevant depth is retrieval engineering — which the RAG engineer guide covers in that framing.

How to tell a working system from a demonstration

Retrieval demos are unusually convincing, because a curated question against a small clean corpus always looks good. Three questions puncture that quickly.

  • “How did you know it was getting better?” A held-back set of real questions with expected sources, scored repeatably. Without it, every subsequent claim is an impression.
  • “What did it do when the answer was not in the corpus?” A system that confidently invents an answer to an unanswerable question is worse than one that declines, and handling that is a deliberate design decision rather than an accident.
  • “What happened when the corpus grew ten times?” Retrieval quality frequently degrades with scale as near-duplicates crowd the results, and it is the failure that most often arrives after launch.

What it pays, and who you are competing with

Indicatively £70,000 to £105,000 permanent, with day rates from roughly £500. About 230 UK employers name the framework across the careers pages we index, which is a real if modest market — enough that candidates have options and not enough for a reliable salary benchmark.

Worth knowing: the strongest people for this work are often not labelled as AI engineers at all. Search engineers, data engineers who have handled document pipelines, and anybody who has built an enterprise search system before 2022 frequently convert faster than a candidate whose experience is entirely in the last two years of tooling. The problems are older than the framework.

What a realistic first three months looks like

If the project is new, expect the first month to be almost entirely ingestion — getting documents in, parsed and chunked in a way that survives contact with the awkward ones. Expect the evaluation set to be built in the second month, usually after somebody has been embarrassed by a bad answer in a demonstration. Expect the interesting retrieval work to start in the third.

Teams that plan the reverse order — clever retrieval first, ingestion later — generally spend the third month rebuilding the first. Saying this at the briefing stage is worth more than any interview question, because it sets an expectation the engineer can actually meet.