How the interviews run

Think about a visit to a good doctor. The doctor does not start with a list of 50 fixed questions. The first question is “What brings you in today?” Then the doctor listens, and every next question comes from your answer: “When did it start?”, “Does it hurt more in the morning?”, “What did you take for it?” After ten minutes, the doctor knows much more than a form could tell them.

A serious technical interview works the same way. The interviewer listens first, and then goes deeper into what you said, one step at a time. This page explains that pattern, and the five interviews in Quillfield’s process. Then you are ready for Part 3, where five candidates go through the same technical interview.

The five interviews at Quillfield

Quillfield’s posting lists its process, which is less common than it should be. Most postings do not describe the interviews at all, so ask the recruiter at the start. Each interview checks something different, and each one is run by a different person.

1. The recruiter call (30 minutes, Hannah Lee, Talent Partner). Hannah checks the basics:

• Does your experience match the level?
• What pay do you expect, and when can you start?
• Can you explain your work clearly to someone who is not an engineer?

She also tells you why the company is a good place to work. Prepare a one-minute introduction and your pay range. Bring your questions about the process too. This is the best moment to ask which tools the team uses and whether there is on-call.

2. The hiring manager (45 minutes, Marcus Chen, Engineering Manager). Marcus wants to know why you want this job, how you work with other people, and whether your past projects match the team’s problems. He asks about projects at a higher level than an engineer would. What was the goal? What did you decide? What went wrong, and what would you do differently? He also wants to know that you will still like the job in a year.

3. The technical deep dive (60 minutes, Nadia Rahman, Staff AI Engineer). This is the interview in Part 3 of this guide. Nadia asks about a project that you built, and goes deep into it. Then she gives you a real Quillfield problem and asks how you would approach it. She checks that your experience is real, how deep it goes, and how you think when you reach the edge of what you know.

4. System design (60 minutes, Owen Fraser, Principal Engineer). Owen asks you to design a complete system, for example the claim-summary feature for all 40 insurers. You draw the parts on a shared board and explain the trade-offs. For example:

• What runs when a packet arrives?
• Where is the data kept?
• What happens when the model service is slow?
• How much does it cost?
• How do you release it safely?
• How do you know that it still works next month?

5. The values conversation (45 minutes, Sofia Alvarez, Director of Claims Operations). Sofia was an adjuster for many years. She asks how you behave in difficult situations. What do you do when an expert disagrees with you? Or when your feature makes a mistake that reaches a customer? Or when the deadline and quality conflict? She also checks that you respect the people who use the software.

After the last interview, the interviewers meet in a debrief: each one shares their written notes, and together they decide. A strong result in one interview does not cancel a serious concern from another one.

Other kinds of interview that you may meet

Other companies use other rounds for AI engineering roles. You may meet:

• A take-home task or a live build: you build something small, for example a question-answering system over a few documents, and you report how well it works with a small set of test questions.
• Practical coding: you write or fix real code, often in a small code base, instead of solving a puzzle. Some companies now allow an AI coding assistant in this round, and watch how you use it. Others do not allow any AI help. Follow the rules of each round, and ask if you are not sure.
• Live debugging: “This agent repeats the same step forever. Find out why.”
• A customer conversation: for roles that work directly with customers, an interviewer plays a customer with a vague problem.

Some companies have also brought back at least one interview in person, partly because some candidates used hidden AI tools during video interviews. We say more about that in our advice.

How a serious interviewer goes deeper

The technical deep dive starts with an open question: “Pick a project that you are proud of, and walk me through it.” (That means: tell me about it, step by step.) Then the interviewer follows your answer. Here is how one sentence from a candidate can grow into twenty minutes of conversation.

Suppose that a candidate says: “I built a chatbot that answers questions about our company’s HR policies.” The interviewer goes down level by level:

From one sentence to the edge

1. 1

   “What did it do, and who used it?”

   Is the project real, and how big was it? A real project has real users and a clear scope.

2. 2

   “How did you split the policy documents into pieces for search?”

   Did the candidate build it, or watch someone else build it? Only the builder knows these details.

3. 3

   “Why that size of piece? What else did you try?”

   Did they make decisions, or copy a tutorial? Good engineers compare options.

4. 4

   “How did you know that the answers were right?”

   Can they measure quality? This is where many candidates stop having answers.

5. 5

   “Tell me about a wrong answer that it gave. What did you change?”

   Do they learn from failures, and can they talk about them honestly?

6. 6

   “What would change with a hundred times more documents, or with personal information in them?”

   The edge: the interviewer wants to see how the candidate thinks beyond their experience.

The interviewer plans the areas to probe, not the exact questions. The questions come from the answers. A candidate who says “I split them into pieces of about 500 tokens, because the policies have short sections” will get a question about sections. A candidate who says “I used the default settings” will get “What were the defaults, and did they work for your documents?”

This is why lists of interview questions help so little. You cannot memorise the answers, because the questions come from your own work. What you can do is 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 want to see what you do when you do not know:

• Do you say clearly that you do not know, or do you try to hide it behind general words?
• 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 stay honest?

Here is a short example of a good answer at the edge.

An example: reaching the edge

Nadia(interviewer):

You said you used a reranker. How does the reranker score a passage differently from the first search?

Candidate(candidate):

Hmm. Honestly, I used it as a library call. I didn’t look inside it.

Nadia(interviewer):

Okay. What do you know about it?

Candidate(candidate):

So, the first search compares a vector for the question with the vectors for each passage. It’s fast, but rough. The reranker, as I understand it, looks at the question and each passage together. So it’s slower, but more precise. That’s why we only ran it on the top 50.

Nadia(interviewer):

Mm-hm.

Candidate(candidate):

But I’d want to read how it really works before I use it for something important.

Why this works

The candidate does not pretend. They say exactly where their knowledge stops. Then they explain what they do know, correctly, and how it affected their design: the slow, precise step runs only on the top few passages. An interviewer learns more from this than from a memorised definition.

The Quillfield problem

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

“Here’s a real problem on our side. A claim packet comes in: 20 to 60 pages, scanned forms, the adjuster’s notes, emails, photos, a contractor’s estimate. Adjusters tell us they spend about 40 minutes reading a packet before they can act. We want to give them a one-page draft summary: the key facts, the open questions, and what’s missing. How would you approach it?”

There is no single right answer. Nadia does not want a finished design in 20 minutes. She wants to see how you start:

• Which questions do you ask first?
• What do you choose to build first?
• How would you know that it works?
• What could hurt someone if it goes wrong?

Then she follows your answer, in the same way as with the project.

Try it before you read the candidates

Take 20 minutes, and write or say out loud how you would approach the Quillfield problem. Use what you learned about the team from the posting and from Read it honestly. Answer these for yourself:

1. Which three questions would you ask Nadia before you propose anything?
2. What would you build first, and what would you leave for later?
3. How would you know that a summary is good? Who decides?
4. What is the worst mistake that the summary could make, and how would you make it less likely?

Keep your notes. When you read the five candidates, compare your answers with theirs. You will see that 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 Nadia, as a conversation. In Daniel’s interview, Marcus Chen also joins. 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 Nadia’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.

The five candidates are:

1. The backend engineer: Daniel has years of production experience, and is new to measuring the quality of AI features.
2. The data scientist: Mariana is excellent at evaluation, and has never owned a production service.
3. The self-taught builder: Yusuf has no professional software job, and one deep, real project.
4. The polished CV: Alex’s CV promises more than his experience can support.
5. The domain expert: Leila was a claims adjuster for years, and learned to build.

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