How the interviews run

Imagine that you need someone to repair the electrical wiring in your home. One electrician gives you a list of certificates. Another one says: “Last month I rewired a kitchen in an old house. The old wires had no ground, so first I…” You ask, “Why did you do it in that order?”, and they explain. Then you ask, “What if the fuse box is too small?”, and they think for a moment and tell you honestly what they would check. After ten minutes, you trust the second electrician much more, and the certificates did not help you decide.

A serious technical interview works in the same way. The interviewer listens to what you built, then asks one question after another about it, until they reach the edge of what you know. This page explains that pattern, the five interviews in Casewell’s process, and the coding round where you may use an AI assistant. Then you are ready for Part 3, where five candidates go through the same technical interview.

The five interviews at Casewell

Casewell’s posting lists its process. Most postings do not, so if yours does not, ask the recruiter at the start. Each interview checks something different, with a different person.

1. The recruiter call (30 minutes, Ben Okoro, Recruiter). Ben checks the basics: your experience and level, your pay range, when you can start, and whether you can explain your work to someone who is not an engineer. He also tells you about the company. Prepare a one-minute introduction, your range, and your questions. This is the best moment to ask about on-call and about the rules for the coding round.

2. Practical coding (75 minutes, one of the team’s backend engineers). You get a small FastAPI service in a shared repository, with some tests that fail. You fix the failures and maybe add a small feature. An AI coding assistant is allowed, and the interviewer watches how you check what it writes. We look at this round in detail below.

3. The technical deep dive and design (60 minutes, video, Rafael Mendes, Staff Engineer). This is the interview in Part 3 of this guide. Rafael asks about a backend system that you built or own, and goes deep into it. Then he gives you Casewell’s real problem and asks how you would redesign it. No AI tools in this round. It is only a conversation.

4. System design (60 minutes, Anjali Desai, Principal Engineer). Anjali asks you to design a full system at the scale of all 400 customers. You first write a short design document in a shared file, then you discuss it with her. She looks at the trade-offs: what happens at peak load, what fails first, what it costs, how you release it safely, and how you know that it works.

5. The values conversation (45 minutes, Marguerite Hall, Head of Customer Success). Marguerite was a lawyer before she joined Casewell. She asks how you behave in difficult situations: a customer who found a serious bug, a deadline that conflicts with quality, a disagreement with a colleague. She checks that you understand what confidentiality means to a law firm. This is also where you can learn about on-call and the real speed of the team.

After the last interview, the interviewers meet in a debrief. Each one shares written notes, and Nora Lindgren, the Engineering Manager who is hiring, makes the decision with them. A strong result in one round does not cancel a serious concern from another.

Other kinds of interview that you may meet

Other companies use other rounds for backend roles in AI products:

• Coding without any AI help. At the end of 2025, one industry survey of engineering leaders found that almost two in three companies still did not allow AI in interviews. So do not assume. Ask before every coding round.
• Debugging or code review. You get code with bugs, or a pull request to review, and you explain what is wrong and why.
• A take-home task. You build something small at home, for example an API with a background job. These are less common than before.
• A paid work trial. A few companies ask finalists to work with the team for a few paid days.

A round where AI is allowed has clear rules, and a round where it is not allowed has clear rules too. Follow them exactly (our advice).

The coding round where AI is allowed

Think about a driving test in a car with a navigation app. The app is allowed. It tells you where to turn. But the examiner is not testing the app. The examiner watches your eyes: do you check the mirror, do you see the cyclist that the app does not know about, do you stop when the app says “turn left” into a street with no entry?

The AI-allowed coding round works in the same way. The interviewer already knows that the tool can write code. They want to see you use the tool openly, check its output, and explain your decisions. Candidates who accept everything the tool writes do badly in this round, even if the tests pass.

Here is how to work well in it:

• Ask about the rules first. Which tools are allowed? Can you use your own setup, or only the one in the shared environment? Can it see the whole repository?
• Read before you ask. Spend the first few minutes reading the code and the failing tests yourself. Say what you see: “The test expects a 409 when the same file is uploaded twice. Right now we return 201.”
• Say what you will ask the tool, and why. “I will ask it to write the duplicate check, because it is boring code. Then I will read it carefully.”
• Read every line it writes. Small, careful steps are better than one large block. If you cannot explain a line, do not keep it.
• Look for what tools often miss in this kind of product. In a multi-tenant service, the most common mistake is a database query or a cache key without the tenant. Also check error handling, what happens when the same request arrives twice, and whether a secret or a document’s text ends up in a log.
• Run the tests, and add one. A passing test suite is not proof. Add a small test for the case that worried you, for example “tenant A cannot read tenant B’s document”.
• Say when you reject its suggestion. “It wants to catch every exception here. I don’t like that, we would hide real errors. I will catch only the timeout.”
• Work without it when that is faster. Nobody gives you points for using the tool as much as possible.

Here is a short moment from a coding round like this one.

An example: checking the assistant's output

Candidate(candidate):

Okay, it wrote the query. Let me read it… Hmm. It selects the document by ID only.

Interviewer(interviewer):

Mm-hm.

Candidate(candidate):

So if I know another customer’s document ID, I can get their document. The tests pass because every test uses the same tenant. I’ll add the tenant ID to the query. And, let me also write a test with two tenants.

Interviewer(interviewer):

Would you not trust the database for that? We have row-level security.

Candidate(candidate):

Maybe it works here, I don’t know how it’s set up in this repo. But I prefer both. If one fails, the other still protects us. And the test shows it in a few seconds.

Why this works

The candidate does not hide that the tool made a mistake, and does not blame it either. They read the code, explain the risk in one sentence, fix it, and add a test that proves the fix. The interviewer’s question about row-level security is a small check: does the candidate depend on one layer? This is exactly the evidence that the round is designed to find.

How a serious interviewer goes deeper

Now back to the deep dive with Rafael. It starts with an open question: “Tell me about a backend system that you built or own.” Then the interviewer follows your answer. Suppose that a candidate says:

“I built the service that receives payment events from our payment provider and updates the orders.”

One sentence can grow into twenty minutes of conversation, level by level:

From one sentence to the edge

1. 1

   “How many events a day, and what does the service do with each one?”

   Is the system real, and how big is it? Real systems have real numbers, even approximate ones.

2. 2

   “What happens if the provider sends the same event twice?”

   Idempotency: running the same request twice gives the same result as running it once. Only someone who built it knows how they did it.

3. 3

   “And if your database is down for two minutes when an event arrives?”

   Failure handling: retries, waiting longer between tries, a place for events that keep failing.

4. 4

   “How do you deploy a change, and how do you know it works after the deploy?”

   Does the candidate run the system, or only write code for it?

5. 5

   “Tell me about the worst incident with this service.”

   Can they describe a real failure in detail, and what they changed after it?

6. 6

   “Now imagine each event takes 30 seconds to process and costs money, and one customer sends ten thousand at once. What changes?”

   The edge: the interviewer moves from their experience to the Casewell problem, and watches how they reason.

The interviewer plans the areas to probe, not the exact questions. The questions come from your answers. A candidate who says “We store the event ID with a unique index” gets a question about that index. A candidate who says “The framework handles duplicates” gets “How? Show me what it does.”

So do not learn lists of questions. Know your own work very well: every decision, every number, every failure.

The edge of what you know

Every candidate reaches an edge. A good interviewer goes there on purpose, because the most useful information is there. They watch what you do when you do not know:

• Do you say clearly that you do not know, or do you talk around it?
• Do you reason from what you do know, step by step, out loud?
• Do you ask a question that makes the problem clearer?
• Do you stay calm and honest?

Here is a short example.

An example: reaching the edge

Rafael(interviewer):

The answer is streaming to the browser, and the user closes the tab. What happens to the model call on your server?

Candidate(candidate):

Hmm. Honestly, I’m not sure. I never tested that case.

Rafael(interviewer):

Okay. What do you think?

Candidate(candidate):

Let me think… The server writes to the connection, the connection is closed, so at some point the write fails. But the call to the model is a separate thing. I think it can continue, and we still pay for all the tokens. Unless we check for the disconnect and cancel it.

Rafael(interviewer):

And how would you know which one is true?

Candidate(candidate):

I would test it. A fake model that sends one word every second, I close the client after two seconds, and I check if the fake model still gets asked for more. That’s maybe one hour of work.

Why this works

The candidate says exactly where their knowledge stops. Then they reason from what they know, find the real risk (the server may keep paying for an answer that nobody reads), and propose a small test that would give the answer. The test matters here, because the true answer depends on your server code and on the model provider: with some providers, closing the request stops the generation; with others, it may not. Rafael often asks “how would you test that?”, and a concrete test is the strongest reply.

Your English does not need to be perfect

Many people in this process speak English as a second or third language. Rafael does too: he grew up in Portugal. A good interviewer listens for your thinking, not for perfect grammar. If you do not understand a question, ask: “Sorry, can you say it again?” or “Do you mean the upload or the chat?” If you lose your point, say so, and start again. That is much better than a long answer to the wrong question. Read more in our advice. In Part 3, you will see several candidates who are not native speakers, and how little it matters.

The Casewell problem

In the second half of the deep dive, Rafael gives every candidate the same problem. It is the real reason the team is hiring:

“Now our real problem. At the start of a deal, a law firm uploads up to 2,000 contracts at once. Today we process them inside the upload request; it times out, people upload again, we get duplicates. Last month one big upload slowed down every other customer for hours. And — I will be honest with you — we had an incident where one customer saw text from another customer’s document in a chat answer. It was a cache bug, fixed now. How would you redesign document processing and the chat so these things cannot happen?”

There are three problems inside this one question: slow uploads that create duplicates, one customer slowing down everyone, and data that crossed from one customer to another. There is no single right answer. Rafael does not expect a finished design in 25 minutes. He wants to see where you start, which questions you ask, how you make each part safe to retry, and where you would check the tenant. Then he follows your answer, in the same way as with your own project.

Try it before you read the candidates

Take 25 minutes. Write, or say out loud, how you would approach the Casewell problem. Use what you learned from Read it honestly. Answer these for yourself:

1. Which two or three questions would you ask Rafael before you propose anything?
2. What should the upload request do, and what should happen later, in the background?
3. If a user uploads the same 2,000 files again, how does the system know?
4. How do you stop one customer’s upload from slowing down everyone else?
5. List every place where one customer’s data could reach another customer. Think beyond the database: caches, search, background jobs, logs, and the text that you send to the model.
6. How would you test that the cache bug cannot come back?

Keep your notes. When you read the five candidates, compare. Each candidate starts from their own experience. That is normal, and you should do the same.

How to read the candidate pages

Each candidate page shows the same 60-minute interview with Rafael, as a conversation. Blue turns are the interviewer. Green turns are the candidate. Between the turns, notes explain what is happening:

• What the interviewer is checking: the real question behind the question.
• How the interviewer goes deeper: why the next question follows from the answer.
• Why this works: what made an answer strong.
• Where this goes wrong: a weak moment, and why it is weak.
• A stronger answer: the same moment, answered better, in the candidate’s own words.
• Disagreeing well: how a candidate disagrees with an interviewer, with reasons.

Each page ends with Rafael’s written notes, what happened next, and advice for readers with a similar profile. Every candidate has strong moments and weak ones, because every real candidate does. Casewell has one vacancy, so the five stories end in different ways, and not all of them end with an offer from Casewell.

The five candidates are:

1. The enterprise engineer: Samuel has nine years of payment systems at a bank, and has never built an LLM feature.
2. The full-stack builder: Emily builds fast, with many AI projects, and has less backend depth than her CV suggests.
3. The new graduate: Minh finished his degree in May, with one internship and strong fundamentals.
4. The big-tech engineer: Arash knows distributed systems at huge scale, and has never owned a product with customers.
5. The security-minded engineer: Claire built health-records software with strict privacy rules, and one LLM feature.

Read them in any order. Start with the one that is most like you, and then read the one that is least like you.