Read it honestly

On the previous page, you found the problem behind the posting: lawyers upload many confidential contracts, an AI model reads them, and the system around the model must stay fast, reliable and separate for every customer. Now we read the posting line by line, as an experienced backend engineer would before applying. We put every line in 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 the job does not depend on it.
• Missing: the posting does not say it, but the job clearly needs it. These lines are often the most important ones, 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 backend engineering experience” and “from the first design to production” describe an intermediate to senior engineer. That is someone who can take an unclear problem, design a solution, build it and keep it running, without step-by-step help. Nothing in the posting asks you to lead people or set the technical direction for the whole company.

The range is CAD 130,000 to 165,000, plus equity. It is in the posting because of new Ontario rules. Since 1 January 2026, most public job postings in Ontario must include the expected pay. They must also say if AI is used to screen applicants and if the vacancy exists now, and they must not require Canadian work experience. Small employers and some roles are exempt. That is why the “Good to know” section exists.

Compare the range with the market. The senior backend roles in Toronto that we read showed about CA$160,000 to 230,000, mostly for hybrid work in an office. Casewell’s range is lower and fully remote. That fits an intermediate role. If you are clearly senior, ask the recruiter early how the level is decided, and whether the range can change for a senior hire. It is a normal question.

What is really required

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

1. You have built and run a backend service that real users depend on. “Design, build and run” is the key phrase. Writing an API is one thing. Running it means that you know what happens when it is slow, when the database is busy, when a deploy goes wrong at 4 p.m. on a Friday. Python is the team’s language, but the posting says “any backend language is fine”, and we believe it. A strong Java or Go engineer can learn FastAPI in weeks. What takes years is the judgement.

2. You can design work that happens in the background. The posting says only “make our document processing faster and more reliable”. But reading a 60-page contract with an LLM takes time, and a customer can upload hundreds of contracts at once. You cannot do that work while the user waits for a web page. So the job needs background jobs: the server accepts the upload quickly, puts the work in a queue (a waiting list of tasks), and separate workers do the work later. With that come the hard questions: what happens when a job fails, when it runs twice, or when one customer fills the whole queue? The stack line even names Celery, a Python job queue. Expect this topic in every technical interview.

3. You keep each customer’s data separate, everywhere. Casewell serves 400 organisations from one system. In this kind of software, each customer organisation is called a tenant, and the system is multi-tenant. Every query, every file, every cache and every search must know which tenant it serves. The posting says “Security-minded” and nothing else. Think about the pharmacy from the previous page: this one short line is the job.

4. You can work with an AI model as an unusual dependency. The posting puts “Experience with LLMs” under “Nice to have”, and that is partly true. You do not need to know how models are trained. But your code will call a model all day, and a model is not like a normal API. It is slow. It costs money for every call. It can give a different answer to the same question. It can be confused by text inside a document. You must design for all of that. If you have never called an LLM API, you can learn the basics in a weekend. Do it before you apply.

5. You can talk with people who are not engineers. “Product Engineer” and “own problems, not tickets” mean that nobody will give you a finished specification. You will talk with product managers, customer success, the AI engineers and sometimes customers. The last interview is with a former lawyer. She will check that you understand what a contract means to the people who use the product.

A line that looks like a wish, but is tested

“You are fluent with AI coding tools” sounds like a small modern detail. In this process, it is tested directly: the coding interview allows an AI assistant, and the interviewer watches how you use it. The team does not want to see that you can make the tool write code. They want to see that you can check what it writes, explain it, and reject it when it is wrong. We look at this round in detail on the next page.

The line that is true and important

“No ML experience required.” Many people read this and do not believe it. Here, you should believe it. We saw the same line in real postings, and it matched the work: the backend roles we read asked for the systems around a model, not for the model itself. At Casewell, two AI engineers own the prompts and the measurement of answer quality.

This is the main difference from an AI Engineer role. If you are an experienced backend engineer and you thought that AI products were not for you because you never trained a model, this posting is for you. If you want to design prompts and measure model quality, read the AI Engineer guide instead, and compare.

What is probably a wish

“Experience with LLMs” without any detail. As we said above, you need the basics. But nobody will ask you to compare model families or tune a model.

Temporal or another durable workflow tool. This is an interesting line. The stack says Celery, but the nice-to-have list says Temporal. When a posting names a tool that the team does not use yet, it often means that a change is planned or has started. Ask about it. You may be the person who does the migration.

Docker and Kubernetes. Useful, but the posting never says that you will run the infrastructure. If you know them, mention it once.

Legal tech. It helps you understand the users. It is not a requirement. The values interview will check that you respect how important confidentiality is to lawyers, and you can prepare for that without legal experience.

What is missing, and matters

Queues and streaming are not named. We covered queues above. The other missing word is streaming: “Ask your contracts” shows the answer word by word as the model writes it. That needs a connection that stays open, usually with server-sent events (SSE, a simple way for a server to keep sending small messages to a browser over one HTTP response). What happens when the user closes the tab, or when the model stops in the middle of an answer? These are backend questions, and the posting says nothing about them.

Prompt injection. Customers upload contracts written by other people, sometimes by the other side of a deal. A document can contain text such as “Ignore previous instructions and…”. This is called prompt injection: text inside the data that tries to change what the model does. The backend decides what the model is allowed to see and do, so this is partly your problem.

On-call. The posting does not mention it. Most of the 10 real postings that we studied did not mention it either. But a service that customers depend on needs someone to fix it at night. Ask how often you would be on call, and what a normal week on call looks like.

Cost per customer. Every model call costs money. A large customer that uploads thousands of contracts can cost more than it pays. The posting says nothing about cost, but a good backend engineer in an AI product thinks about it.

Where the data stays. Law firms often require that their data stays in their country. A Canadian firm may require Canada; a UK firm may require the UK. This affects where files are stored and which model service is called. Ask about it.

Who owns a failure. When a chat answer is wrong, is it a bug in the backend or in the prompt? Teams with separate AI engineers and backend engineers sometimes disagree about this. Ask how it works today.

Words that describe the culture

Some words are about the culture, not the work: “fast-paced”, “product-led”, “growing quickly”, “own problems, not tickets”. They can mean good things: trust, freedom, and work that customers see quickly. They can also mean too much work for too few people, or a team that has no time to fix old problems.

You cannot tell which from the posting. So ask questions that people can answer with an example: “What was the last thing that the team stopped to fix properly, and how was that decided?” “What does a normal week look like?” A healthy team answers easily, with a real story.

Who should apply

Nobody matches every line, and the team does not expect it. Use the five requirements above, not the full list. In Part 3 of this guide, you follow one candidate for each of these situations:

• You have years of backend work in a large, strict company, but no LLM features: apply. Your experience with queues, retries and audits is exactly what the team needs. Learn how a model differs from a normal API. (The enterprise engineer)
• You build fast, full-stack, with many AI side projects: apply if you have real backend work to show. Prepare data separation and background jobs very carefully, because they are the most likely gaps. (The full-stack builder)
• You graduated recently, with one internship: this posting is above your level today. Ask the recruiter if the company has a new-graduate program. Some do, and a strong conversation can move you there. (The new graduate)
• You work on large infrastructure at a big tech company: you will probably do very well in the technical rounds. Think hard about whether you want a small product company, with customers, on-call and fast change. (The big-tech engineer)
• You have built software with strict privacy rules, for example in health or finance: apply. The hardest part of this job is your strongest skill. Prepare for scale and for cost. (The security-minded engineer)

Turn the posting into a preparation plan

Now connect each requirement to what the interviewers will probably ask and to the evidence that you need. The table covers the five requirements and two of the missing items.

From the posting	What they will probably ask	Evidence that you need
Run a backend service	“Walk me through a system you own. What broke? How did you know?”	One system that you can explain for 20 minutes, with real numbers and one real incident
Background work (hidden)	“What happens when this job runs twice? When it fails halfway?”	A queue or job system that you designed or fixed, and what you learned
Data separation (one line)	“Where could one customer see another customer’s data?”	A design where the tenant is checked at every layer, and a test that proves it
AI model as a dependency	“The model is slow and sometimes fails. What does the user see?”	A small feature that calls an LLM, with timeouts, retries and a test that does not call the real model
AI coding tools	Shown, not asked, in the coding round	Practice on a small repo: use the tool, check its output, explain each change
Streaming (missing)	“The user closes the tab in the middle of an answer. What happens?”	You can explain SSE and what your server does on a disconnect
Prompt injection (missing)	“A contract says ‘ignore your instructions’. What can go wrong?”	A clear rule: documents are data, and the model cannot take actions on its own

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

Questions to ask at each stage

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

• Recruiter (Ben Okoro): “How is the level decided, and is the range the same for a senior hire?” “Is there an on-call rotation?” “What are the rules for the AI assistant in the coding interview? Can I use my own tool?” “Do you have a new-graduate program?”
• Coding interview (a backend engineer): “Should I treat this code base as production code, or as a quick prototype?” “Can I ask you questions while I work?”
• Technical deep dive (Rafael Mendes): “How do you run long document jobs today, and what is the plan with Temporal?” “How do you test a feature whose output changes from one run to the next?” “What was the hardest production problem this year?”
• System design (Anjali Desai): “Where must customer data stay, and does that affect which model service you can call?” “Do you know the cost of model calls per customer?”
• Values (Marguerite Hall): “When a customer finds a serious bug, how does the company tell them?” “How do engineers learn what lawyers need?”

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 backend posting at a company with an AI product. Sort its lines into the three groups: really required, a wish, missing. Write the problem behind the posting in one sentence. Then find the “pharmacy line”: the thing that the team fears most, even if the posting says it in one word.

Make the preparation table for the 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.

What happens next

On the next page, we look at the five interviews in Casewell’s process: who runs each one, what each one checks, how to work in the coding round where an AI assistant is allowed, and how a serious interviewer moves from what you say to the edge of what you know.