Prepare for your own interview

You have now watched five people go through the same interview. They had different experience, but the strong moments had the same causes. The candidate knew their own work in detail. They said clearly what they did not know. They reasoned out loud from what they did know. And they treated the interview as a conversation, not a test.

None of this comes from reading. It comes from preparation and practice, like a musician who plays a piece many times before the concert. The concert still feels different, but the hands know what to do. This page is a plan for that practice. It takes about three weeks of short sessions.

Step 1: Choose one posting, and read it properly

Do not prepare for “AI Engineer interviews” in general. Prepare for one real posting, then adapt for the next one. Read it in the way that you saw on The job description and Read it honestly:

1. Find the problem behind it.
2. Sort the lines into required, wish and missing.
3. Make the preparation table.

The table shows you two things. First, the stories that you already have. Second, the gaps that you must either close or explain honestly.

Step 2: Write drill-down notes for your projects

Choose the one or two projects that you will talk about. For each project, write answers to the levels that a serious interviewer goes through. Use real numbers wherever you have them.

1. What and who: what did it do, who used it, and how many people?
2. How: how did each main part work? Which parts did you build yourself, and which did others build?
3. Why: what did you choose at each important point, and what else did you consider? Why did you reject the other options?
4. How you knew: how did you measure that it worked? What was the number before and after your change?
5. What failed: the worst bug or wrong result, how you found it, and what you changed.
6. The edge: what would change with 100 times more data or users, with personal information, or with a stricter deadline? Which part of the system do you understand least?

Level 5 matters more than most people think. Interviewers trust a candidate who can describe a failure in detail, because only the person who did the work remembers it that way. Level 6 is where you will probably reach the edge of what you know, so think about it before the interview.

If you cannot answer level 4 for a project, that is the most useful thing that you can learn now. Go back to the project, build a small set of test examples, and measure it. Even 30 examples with a clear score is much better than “users liked it”. You saw why in The backend engineer and The data scientist.

If you have no project of real difficulty, build one before you apply for roles at this level. Read our advice and The self-taught builder first.

Step 3: Practise the opening out loud

The deep dive starts with “Walk me through a project”, which means “tell me about it, step by step”. Your first two minutes decide where the conversation goes, because the interviewer asks about what you say. So say the things that you want to be asked about.

Prepare a two-minute walkthrough. It can follow this order:

• the problem, and who it was for,
• what you built,
• one important decision, and why you made it,
• the result in numbers,
• one limit.

Then say it out loud, and record it on your phone. Listen to the recording once. Most people find that they talk about tools too much and about decisions too little. Our lesson Explain decisions shows this step in detail.

Step 4: Practise the company’s problem

Most technical interviews include a problem from the company’s own work. You can usually guess it from the posting. Quillfield’s posting names claim summaries, so the claim-summary problem was not a surprise.

Write the problem that you expect, in two or three sentences, like Nadia’s. Then answer it out loud for 20 minutes, with a timer. Start with your questions. Then say what you would build first and how you would measure it. End with what could hurt someone if it goes wrong. Do this two or three times, on different days. Each time, you will notice a gap that you can read about before the next time.

Step 5: Get interviewed by a person

Practice alone is useful, but it cannot surprise you. Ask a friend or a former colleague, ideally an engineer, to interview you for 45 minutes. Give them your CV and the six levels from step 2, and ask them to go deeper on whatever you say. Ask them for one strength and two things to improve afterwards.

Then change places, and interview them. Being the interviewer teaches you a lot: you will see quickly how a general answer sounds, and how much a specific one helps.

You can also practise with an AI assistant: ask it to play a strict interviewer who follows up on your answers and never accepts a general answer. This is good practice. It is very different from using AI during a real interview, which we ask you never to do (our advice).

Step 6: Prepare for the edge

You will reach the edge of your knowledge in every good interview. Prepare for it like any other part.

Write down three topics from the posting where you expect to reach your edge. For each one, write what you do know, and how you would find out the rest. Then practise saying it: “I haven’t worked with that directly. What I know is… If I had to decide today, I would start by…” It feels uncomfortable the first few times, and then it becomes normal. Interviewers notice the difference.

Also prepare for the other kind of edge: when the interviewer says something that you think is wrong. You saw Daniel disagree with a hiring manager about long context windows. Know your main topics well enough to explain your view with a reason or an example, politely, and to accept a good counter-argument. See our advice on disagreeing.

Step 7: Prepare your questions

Write two or three questions for each interview stage, from your preparation table and from Read it honestly. Ask about the work, how they measure quality, on-call, and how decisions are made. Questions like these show the interviewer that you think like someone who will do the job. They also give you the information that you need to decide.

On the day

• Ask at the start what is allowed: notes, documentation, a whiteboard, an AI assistant in a coding round. Then follow the rules exactly.
• For a video interview, test your camera, microphone and screen sharing the day before. Close everything that you do not need.
• It is normal to say “Let me think for a moment” and then think in silence for 20 or 30 seconds. It is also normal to ask a question back when a question is not clear.
• Keep paper and a pen near you, and draw when it helps you to think.
• If English is not your first language, that is very normal in this field. Many interviewers speak English as a second language too. Your English does not need to be perfect: the interviewer listens for your thinking, not your grammar (our advice).
• Treat the interviewer as a future colleague. You are also finding out if you want to work with them.

After the interview

Write down every question that was hard, the same day, while you still remember it. Then practise those questions. If you were not chosen, ask politely for feedback. Not every company gives it, but some do, and one honest sentence from an interviewer can be worth weeks of reading.

Remember that some of the result is outside your control (our advice). Another candidate had exactly the right domain experience, or the team changed its plans. Keep going, keep building, and keep the plan focused on the roles that you want.

A three-week plan

The plan below summarises the steps. It assumes about one hour on most days, next to a job or other studies.

Week	Main work	Out loud
1	Read the posting and make the preparation table. Write drill-down notes for your main project. Measure the project if you cannot answer level 4.	Record the two-minute walkthrough twice.
2	Close one gap from the table, or prepare an honest answer for it. Prepare your three edge topics and your questions.	Answer the company’s problem twice, with a timer.
3	Read your notes again. Fix what the practice showed you.	One mock interview with a person, then one more after you fix what they said.

Then apply, and keep the notes. The next posting will need only a few changes.