Skip to content

The job description

  • Page 1
  • 8 min
  • Part 1: Read the job description
Page 1 of 9 · Backend Engineer for AI products interviewsThe job description

Think about a small pharmacy that puts a sign in its window: “Help wanted. Friendly, reliable, good with customers.” All of that is true. But the most important part of the job is not on the sign. A pharmacy assistant must never give one person’s medicine to another person. Nobody writes that on the sign, because the owner thinks it is obvious. In the interview, it is the first thing that the owner checks.

Job descriptions often work like that sign. They list the friendly, general words, and they leave out the one thing that the team worries about every day. So before you ask “Do I have these skills?”, ask a different question: “What problem does this team have, and what are they afraid of?” When you know that, you can read the rest of the posting correctly.

The posting below is for a company that does not exist. We built it from 10 real backend postings at AI product companies: legal software, customer-support software, voice products, health software and developer tools. We kept their real patterns: the clear parts, the vague parts, and the small problems that real postings have. Then we put everything in one company, so that the whole guide can use the same team and the same problem.

Casewell makes contract-review software for law firms and for the legal teams inside companies. It has about 180 people, a head office in Toronto, and engineers who work remotely across Canada. About 400 customer organisations use it, in Canada and the UK. Some are small firms with 5 lawyers. The largest has 900.

A customer uploads contracts, usually PDF or Word files. Casewell uses a large language model (LLM) to find the important clauses: who the parties are, how long the contract lasts, how it can end, who pays if something goes wrong. It then compares those clauses with the customer’s own rules and marks the risky ones. There is also a feature called “Ask your contracts”: a chat where a lawyer asks a question across many contracts, and the answer appears word by word, with links to the exact passages it used. Every customer’s contracts are confidential. Many of them are not even public yet.

Job description

Backend Engineer, Product

Casewell · Toronto, Ontario

  • Remote in Canada, one week a quarter in Toronto
  • Full-time
  • CAD 130,000 – 165,000 + equity

Casewell helps lawyers understand their contracts in minutes instead of days. More than 400 law firms and legal teams in Canada and the UK trust us with their most important documents. We are a fast-paced, product-led team, and we are growing quickly.

We hire Product Engineers. That means you own problems, not tickets. You will join our Product Engineering team and build the backend services behind document processing and “Ask your contracts”, from the first design to production. You will work closely with product, design, our AI engineers and our customer success team.

  • Design, build and run the backend services and APIs behind our product.
  • Turn AI prototypes into reliable features that thousands of lawyers use every day.
  • Make our document processing faster and more reliable as our customers grow.
  • Improve performance, reliability and observability across the platform.
  • Take part in design reviews and code reviews, and help the team keep its quality high.
  • 4+ years of professional backend engineering experience.
  • Strong Python. We use FastAPI, but deep knowledge of any backend language is fine.
  • Solid experience with relational databases, ideally Postgres.
  • Experience designing and operating APIs in production, on a cloud platform (we use Azure).
  • You are fluent with AI coding tools (Cursor, Claude Code, Copilot or similar) and use them every day.
  • Security-minded.
  • Clear written and spoken communication.

No ML experience required.

  • Experience with LLMs.
  • Experience with Temporal or another durable workflow tool.
  • Experience with B2B SaaS products and enterprise customers.
  • Experience in legal tech or another regulated industry.
  • Docker and Kubernetes.

Python, FastAPI, Postgres, Redis, Celery, Azure.

  1. A call with our recruiter (30 minutes).
  2. A practical coding interview in a small code base (75 minutes). You may use an AI coding assistant.
  3. A technical deep dive with a staff engineer (60 minutes).
  4. A system design interview (60 minutes).
  5. A values conversation with a leader from our customer success team (45 minutes).

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 10 real backend postings at AI product companies.

Before you compare the posting with your CV, answer three questions about it. Write your answers down. It takes about ten minutes. Then compare them with ours.

  1. What problem does the team have? Use one sentence, in plain words, with no tool names.
  2. What is the worst thing that can go wrong in this product? Think about the pharmacy.
  3. Which lines say less than they should? Find two lines that look small but probably hide a big part of the job.
Our answers

1. The problem. Lawyers upload many confidential contracts, and the system must read them with an AI model, answer questions about them, and stay fast and correct for every customer at the same time. The AI part already exists. The team needs someone who makes the system around it reliable.

2. The worst thing. One customer sees another customer’s contract. For a law firm, this is not a small bug. It can break a promise to their client, and it can end the relationship with Casewell. Slow processing is bad. A wrong summary is bad. But a leak between customers is the thing that a team like this fears most. The posting says it in two words: “Security-minded.” That is our first sign that the interviews will spend a lot of time on it.

3. Lines that say too little. We chose these two:

  • “Make our document processing faster and more reliable as our customers grow.” Processing contracts with an LLM is slow and can fail. So this line almost certainly means background jobs, queues and retries, but the posting never uses those words. Neither does it mention how the chat answer is sent word by word, which is called streaming.
  • “Security-minded.” It is one line, without a single detail, in a product that holds confidential legal documents for 400 customers. It is probably the most important line in the posting.

You may also have chosen “Experience with LLMs” in “Nice to have”, or the line about AI coding tools. Both are good choices. We read them on the next page.

If your answers are different, that is fine. The point is the habit: start from the problem and from what can hurt the users, not from the list of tools.

Many postings at AI companies look similar, so it is easy to mix them up. In the real backend postings that we read, the AI part was almost never the main work. They asked for the systems around the model: accounts and permissions, keeping each customer’s data separate, background processing, reliability, and turning a prototype into a product. They did not ask for prompt design, quality measurement of model output, or model choice. At Casewell, two AI engineers own that work.

So this role is a backend role in an AI product. If you want the role where you design prompts and measure answer quality, read our AI Engineer guide and compare the two postings. Many people are a good fit for one and not the other, and that is useful to know before you apply.

On the next page, we read the posting line by line: what is really required, what is only a wish, what is missing, who should apply, and which questions to ask. After that, we look at the five interviews in Casewell’s process, including the coding interview where an AI assistant is allowed.