Read it honestly

On the previous page, you found the problem behind the posting: adjusters spend too long reading claim documents, and Quillfield wants software that reads for them, reliably. Now we read the posting line by line, as an experienced engineer would before applying. We sort every line into one of three groups:

• Really required: the team cannot hire someone without it, and the interviews will test it.
• A wish: the team would like it, but it is not what the job depends on. Writers of job descriptions add these because a longer list feels safer.
• Missing: the posting does not say it, but the job clearly needs it. These are often the most important lines, because the interviews ask about them and many candidates do not prepare.

Our reading is a careful guess, not a fact. A posting cannot tell you everything, so we also list the questions that turn each guess into an answer.

The level and the pay

“4+ years of professional software engineering experience” and “own LLM-powered features end to end” describe an intermediate to senior engineer. That is someone who can take a vague problem and decide what to build. Then they build it and keep it working. They get some help, but nobody tells them each step. It does not mean a team lead. Nothing in the posting asks you to manage people or to set the team’s technical direction.

The pay range is CAD 140,000 to 175,000, plus a bonus and equity. The range is in the posting because, in Ontario, a public job posting must now include the expected pay. Since 1 January 2026, Ontario postings must also follow three more rules:

• They must say if AI is used to screen applicants.
• They must say if the vacancy exists now.
• They must not require Canadian work experience.

That is why the “Good to know” section exists. If you apply in another province or country, the rules are different, and you may need to ask for the range yourself.

What is really required

Under the long lists, the job needs four things. The interviews will spend most of their time on them.

1. You have built LLM features that real people use, in Python, as part of a backend service. “Production” is the key word. A demo answers one question well in front of a friendly audience. A production feature answers thousands of questions a day for people who did not choose it, and somebody notices when it fails. The posting says “2+ years building with LLMs in production”. Read that as “you have shipped at least one LLM feature that people depend on, and kept it working”. If you have done that for one year, and you can talk about it in depth, the number of years matters less than it looks.

2. You can work with documents: retrieval and extraction. All three products in the posting read documents: claim packets, policy wording, notes. So the posting asks for RAG (retrieval-augmented generation: the software finds the relevant passages first, and then the model answers from them). Expect questions like these:

• How do you split documents into pieces?
• How do you find the right pieces?
• How do you show where an answer came from?
• What happens with scanned pages and tables?

3. You can measure quality. The posting says only “help define our evaluation strategy”. This line is short, but it is the most important part of the job. A claim summary that leaves out one important fact can lead to a wrong payment. So the team must know how often its features are wrong, and in which way. An evaluation (often called an “eval”) is a repeatable test of quality: a set of examples with known correct answers, and a way to score the system’s output against them.

4. You can work with people who are not engineers. The posting names product managers, designers and “claims experts”. In practice, the claims experts decide what a good summary is. You must be able to ask them good questions. You must explain trade-offs in plain words, without jargon. And you must accept that they know things that you do not.

What is probably a wish

The tool lists. The posting names LangGraph, LlamaIndex and DSPy, then LangGraph, CrewAI and AutoGen, then Pinecone, Weaviate and pgvector. A team of six engineers does not use three agent frameworks and three vector databases. Somebody copied lists from other postings, or listed everything that the team discussed once. What the team really wants is simpler. You have used at least one framework of this kind, and you understand what it does for you. And you can work without it when it causes more problems than it solves. Do not try to learn six tools in a week before the interview. Learn one well, and ask the recruiter which ones the team actually uses.

Fine-tuning. “Experience fine-tuning LLMs (LoRA, PEFT)” is in the required list. But none of the products in the posting needs a fine-tuned model to start. Extraction, question answering and summaries are usually built with good prompts, retrieval and evaluation first. Fine-tuning (training an existing model further on your own examples) comes later, if at all. So expect the question “When would you fine-tune, and when not?” more than “Show me how you fine-tune.” If you have never fine-tuned a model, say so, and explain when you would consider it.

The degree. “Or equivalent experience” means that a strong record of work can replace it. It is still a filter at some companies. A referral or a strong project can help your application through this filter.

TypeScript and React. These are in “Nice to have”. If you know them, mention it once. If you do not, ignore them.

What is missing, and matters

How quality is measured. We said above that evaluation is the most important part of the job. The posting says almost nothing about it. A line such as “help define our evaluation strategy” often means that the team does not have one yet. That is an opportunity for you, and it is also a warning: you will build the measurement, not only the features. Prepare to talk about evaluation more than about anything else.

Personal information. Privacy is only in “Nice to have”, but claim packets contain names, addresses, policy numbers and, for injury claims, health information. Any engineer on this team handles personal information every day. Treat it as required in your preparation. Know what personal information is, why it must not appear in logs or test data, and who may see what.

Who decides. The posting does not say how a summary is used. Does the adjuster confirm every fact? Can the software make any decision on its own? For insurance claims, a person must stay responsible for the decision. Expect the interviews to check that you understand this, and that you design for it.

On-call. The posting does not mention it. Neither did any of the 11 real postings that we studied. But a production feature needs someone to fix it when it breaks at night. Ask about it. The answer affects your life more than most lines in the posting.

Who labels data. To measure quality, somebody must say what the right answer is for each example. Here, that is the claims experts. How much of their time does the team get? If the answer is “a few hours a week”, the evaluation must be designed for that.

Words that describe the culture

Some words in a posting are about the culture, not the work: “fast-paced”, “high-growth”, “bias for action”, “own end to end”, “0-to-1”. They can mean good things. People trust you, you see your work used quickly, and you do not wait weeks for approval. But they can also mean problems. Maybe the team has too few people. Maybe quality comes second. Or maybe nobody says no to new requests.

You cannot tell which one from the posting. So ask neutral questions that people can answer honestly: “What does a normal week look like for the team?”, “When did the team last slow down to fix something, and how did that decision happen?” A team with a healthy culture answers these easily, with an example.

Who should apply

Nobody matches every line of a posting like this one, and the people who wrote it do not expect that. So use the four requirements above, not the full list:

• You have shipped LLM features in a backend, and you can explain them in depth: apply. Prepare evaluation and privacy carefully, because they are the most likely gaps.
• You are strong in data science and evaluation, but you have not owned a production service: apply. You are strong in the hardest part of the job. Expect the interviews to test production work, and prepare honest answers for it.
• You have no professional software experience, but you have built a complex project and can go deep into it: this posting is probably above your level today. A strong project, and especially a referral, can still get you a conversation, and a conversation can lead to a better-matched role. Be honest about the gap.
• You have worked in insurance or another field that handles claims, cases or documents: your experience is listed as “nice to have”, but for this team it is worth more than it looks. The claims experts are part of the team for a reason.

In Part 3 of this guide, you follow five candidates, one for each of these situations and one more. Each one goes through the same interview.

Turn the posting into a preparation plan

Now connect each requirement to what the interviewers will ask and to the evidence that you can show. The table summarises the four requirements and the two missing items from above.

From the posting	What they will probably ask	Evidence that you need
LLM features in production	“Walk me through something you shipped. What broke? How did you know?”	One project that you can explain for 20 minutes: decisions, numbers, failures
Documents: retrieval and extraction	“How did you split the documents? How did you find the right pieces? How do you show where an answer came from?”	A system that you built over real, messy documents
Evaluation	“How would you know that the summary is good? What would you measure?”	A set of test examples that you built, a score, and what you changed because of it
Work with experts	“Tell me about a time an expert disagreed with your system.”	A story with a real disagreement and what you did
Personal information (missing)	“The packet has health information in it. What changes?”	Clear rules that you can explain: what not to log, who sees what
Human decision (missing)	“Can the summary decide anything?”	A design where the person stays responsible

If you cannot fill the right-hand column for a row, that is your preparation for the next weeks. Our lesson Prepare for applications shows the same method for any posting.

Questions to ask the team

An interview goes in both directions (our advice). The questions below turn our guesses into facts. Ask each one in the interview where it fits best.

• Recruiter: “Which agent framework and vector database does the team use today?” “Is fine-tuning part of the current work?” “Is there an on-call rotation?” “What is the level of this role, and how is it decided?”
• Hiring manager: “What would I work on in my first three months?” “How do you decide that an AI feature is good enough to release?” “How much time do the claims experts have for labelling?”
• Technical interviewer: “How do you measure the intake extraction today?” “What was the hardest bug or failure in production this year?”
• Values interview: “How do engineers and claims experts decide together when they disagree?” “What does the company do when an AI feature makes a mistake that reaches a customer?”

Listen to how people answer, not only to what they say. A clear answer with an example is a good sign. A vague answer to a simple question is also information.

Your turn: read a posting that you want

Find a real posting for a role that you want. Sort its lines into the three groups: really required, a wish, missing. Write the problem behind the posting in one sentence. Then make the preparation table for its main requirements, and write one question for each interview stage.

If you cannot decide whether a line is required or a wish, write it as a question for the recruiter. That is a normal question to ask, and the answer helps you prepare.

What happens next

On the next page, we look at the five interviews in Quillfield’s process. You see who runs each one and what each one checks. You also see how a serious interviewer moves from what you say to the edge of what you know.