Every application starts with a job description. Most of us read it once, quickly, and look for one thing: “Do I have these skills?” That is not the best first question. A job description is a message from a team that has a problem. So before you ask whether you fit, find out what the problem is. Then it gets easier to see which parts of your experience matter. You also see which lines are important, and which lines are only words.
Think of a job description like an advertisement for a house. “Charming, cosy, close to everything” tells you something, but not what you need to know. You learn more from other things:
what the photos show,
what the advertisement does not say,
the questions that you ask on the visit.
In this guide, we do the same with a job description. We read it carefully, we notice what it leaves out, and we decide what to ask.
The job description below is for a company that does not exist. We built it from 11 real AI Engineer postings at insurers, fintech companies, software companies and start-ups. We kept their real patterns. Some parts are clear, some are vague, and some have the small problems that real postings have. Then we put it all in one company, so that the whole guide can use the same team and the same product.
Quillfield makes software for insurance claims. When a house floods or a car is damaged, the owner makes a claim: a request to the insurer to pay for the loss. An adjuster at the insurer reads the documents, checks what the policy covers, and decides what to pay. Quillfield’s software is where adjusters do this work.
Quillfield builds the claims platform that more than 40 insurers in Canada and the United States use to handle over 2 million claims a year. We are a fast-paced, high-growth team on a mission to make claims fair, fast and human.
We are looking for an AI Engineer to join our Claims Intelligence team and own LLM-powered features end to end, from 0-to-1 prototypes to production systems used by thousands of adjusters every day. You will work closely with product, design and our in-house claims experts.
This posting is for an existing vacancy. Canadian work experience is not required. We use AI tools to help sort applications; a person reads every application before any decision. If you need an accommodation at any stage, tell our recruiter.
Composite job description for a fictional company, built from 11 real AI Engineer postings.
Before you compare the posting with your CV, try to answer three questions about it. Write your answers down. It takes about ten minutes. Then you can compare them with ours below.
What problem does the team have? Use one sentence, in plain words, with no tool names.
Who uses what this person builds? And what happens to those people when it is wrong?
Which three lines would you remove, if you had to keep the posting honest and short?
Our answers
1. The problem. Adjusters spend a lot of time reading long claim documents and policy wording. Quillfield wants software that reads for them: it pulls out the facts, answers questions about the policy, and writes a first summary, so that adjusters decide faster. Everything else in the posting (RAG, agents, tools) is a way to do this.
2. The users, and the cost of a mistake. Adjusters use it, thousands of them, every day. Behind every adjuster is a person who had a loss and waits for money. If the summary leaves out an important fact, a claim can be paid wrongly or refused wrongly. So this is not a chat feature where a strange answer is only annoying. Quality and the ability to check each answer matter a lot. The posting says almost nothing about this, which is our first sign that the interviews will ask about it.
3. Lines to remove. “Stay up to date with the latest research” is true of every job, and nobody checks it. “Fast-paced, high-growth” tells you about the company’s view of itself, not about the work. And the list of tools (“LangGraph, LlamaIndex and DSPy”, “LangGraph, CrewAI, AutoGen”) is almost certainly longer than what the team uses. A team rarely uses three agent frameworks at once. We come back to this on the next page.
If your answers are different, that is fine. What matters is the habit: start from the problem and the people, not from the list of tools. In the interviews, the conversation will be about the problem. The tools come up only as ways to solve it.
