Prepare for your own interview

You have now watched five people go through the same interview with Rafael. Their experience was very different: a bank, an agency, a university, a huge cloud company, health software. But the strong moments had the same causes. The candidate knew their own system in detail, including how it failed. They thought about every place where data could cross between customers. They said clearly what they did not know, and they proposed a way to test it.

None of this comes from reading. It comes from practice, like a fire drill. Nobody learns to leave a building safely by reading the plan on the wall. You walk the stairs a few times, and on the real day your feet know the way. This page is the 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 “backend 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. Find the problem behind it. Find the “pharmacy line”, the thing that the team fears most. Sort the lines into required, wish and missing, and make the preparation table.

Also check which kind of role it is. If the posting asks for prompt design and quality measurement, it is closer to an AI Engineer role, and our AI Engineer guide fits better. If it asks for the systems around the model, stay here.

Step 2: Write drill-down notes for one system you own

Choose the one backend system that you know best. For each level below, write short notes with real numbers where you have them. Approximate numbers are fine. “About 3,000 requests a minute at peak, I think” is honest and useful.

1. What and who: what does it do, who uses it, how many requests or jobs a day?
2. The data: what are the main tables, and why are they shaped that way? Which index matters most?
3. When it fails: what happens when a dependency is slow or down? Where are the timeouts and the retries?
4. When it runs twice: what happens if the same request or job arrives twice? How do you know?
5. How you release it: how do you deploy a change, and how do you know it works after the deploy?
6. The worst incident: what happened, how you found it, what you changed after it.
7. Whose data: if more than one customer uses it, where exactly is the customer checked?
8. The edge: what would change with 100 times more load, with an AI model call in the middle that takes 20 seconds and costs money, or with data that must never cross between customers?

Levels 4 and 7 are where many candidates in this role stop having answers. If you cannot answer them for your system, find out. Read the code, or ask a colleague. If the answer is “we don’t handle it”, that is fine to say in an interview, as long as you can explain what you would change.

Level 6 matters more than most people think. Interviewers trust a candidate who can describe a failure in detail, because only the person who was there remembers it that way.

Step 3: Learn how a model differs from a normal API

You do not need machine learning for this role. You do need to know how an LLM behaves as a dependency. If you have never called one, spend one weekend on a small project:

• A FastAPI endpoint that sends a question to a hosted LLM and streams the answer back with server-sent events.
• A timeout, and a clear message to the user when the model is slow or fails.
• A count of the tokens for each request, saved with the customer ID, so that you can add up the cost per customer.
• A unit test that uses a fake model instead of the real one, so the test gives the same result every time.
• One document that contains “Ignore previous instructions…”, and a note about what your design allows the model to do with it.

You will learn more from this weekend than from many articles. It also gives you a real story for the interview: “I wanted to understand streaming, so I built a small version. The first problem I found was…”. Our API course covers the FastAPI basics, and Automated endpoint tests shows how to test an endpoint without manual clicks.

Step 4: Practise the AI-allowed coding round

Many people prepare for coding rounds with algorithm puzzles. For this kind of round, that is the wrong practice. Practise on a small, real code base instead.

Take a small API, your own or an open-source one. Break two or three tests on purpose, or ask a friend to do it. Then fix them with your AI assistant, with a timer of 60 minutes, and talk out loud the whole time, as if an interviewer is watching. Record your screen and your voice. When you watch the recording, check three things:

• Did you read the code and the tests yourself before you asked the tool?
• Did you read every line that the tool wrote, and can you explain each one?
• Did you catch at least one thing that the tool got wrong or left out? In multi-tenant code, look first for queries and cache keys without the customer ID.

Then do the same exercise once without the tool. Some companies do not allow AI in coding rounds, and you must be able to work both ways. On How the interviews run you can read the full list of habits that interviewers look for.

Step 5: Practise the company’s problem

Most deep dives include a problem from the company’s own work. You can usually guess it from the posting. For a backend role in a multi-tenant AI product, it will very probably include some of these: a slow job that must move to the background, duplicates, one customer slowing down others, data that must not cross between customers, and a streaming answer.

Write the problem that you expect in two or three sentences, like Rafael’s. Then answer it out loud for 25 minutes, with a timer. Start with your questions. Then go through the request path from the user to the model and back. For each step, say what happens if it fails, if it runs twice, and how the tenant is checked.

A simple way to find every place where data could cross between customers: draw the path of one request on paper, and write the tenant ID next to every box. The database, the file store, the queue message, the worker, the cache key, the search filter, the logs, the text that goes to the model. If you cannot write it next to a box, that box is a risk. You saw Arash and Claire use this way of thinking in The big-tech engineer and The security-minded engineer.

Do this two or three times, on different days. Each time you will find a gap that you can read about before the next time.

Step 6: Get interviewed by a person

Practice alone cannot surprise you. Ask a friend or a former colleague, ideally a backend engineer, to interview you for 45 minutes. Give them your CV and the eight levels from step 2. Ask them to go deeper on whatever you say, and to ask “How would you test that?” at least three times. Afterwards, ask for one strength and two things to improve.

Then change places, and interview them. As the interviewer, you will quickly hear the difference between “we used a queue” and “we used a queue, and when a job failed three times we moved it to a separate list and looked at it every morning”.

You can also practise with an AI assistant: ask it to play a strict interviewer who follows up on every answer and never accepts a general one. That is good practice. It is very different from using AI in a round where it is not allowed, which we ask you never to do (our advice).

Step 7: 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 where you expect to reach your edge. For this role, common ones are fair scheduling between customers, testing output that changes from one run to the next, and prompt injection. For each topic, write what you do know and how you would find out the rest. Then practise saying it: “I haven’t built that. What I know is… If I had to decide today, I would start with… and I would test it by…”. You saw Samuel do this with testing, and Claire with fair queueing.

Also prepare for the other kind of edge: when the interviewer says something that you think is wrong. You saw Arash politely disagree with Rafael about row-level security. Know your main topics well enough to explain your view with a reason, and to accept a good counter-argument. See our advice on disagreeing.

Step 8: Prepare your questions

Write two or three questions for each stage, from your preparation table and from the questions on Read it honestly. For this role, ask about on-call, about who owns a failure between backend and AI engineers, about cost per customer, and about any migration that is planned. These questions show that you think like someone who will do the job. They also give you the information you need to decide. Arash asked what a normal week looks like, and the answer helped him decide that the job was not for him.

On the day

• Ask at the start of each round what is allowed: notes, documentation, a whiteboard, an AI assistant. Then follow the rules exactly.
• For the coding round, test your editor, your AI tool and the shared environment the day before. If you must use their environment, ask for access early.
• For a video interview, test your camera, microphone and screen sharing. Close everything that you do not need.
• It is normal to say “Let me think for a minute” and think in silence. You saw Minh do this. It is also normal to ask a question back when a question is not clear.
• Keep paper and a pen near you. Draw the request path when it helps.

After the interview

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

Remember that some of the result is outside your control (our advice). In this guide, Casewell had one vacancy and more than one strong candidate. Samuel did very well and still did not join, for reasons that had nothing to do with his interview. Keep going, and keep the plan focused on the roles that you want.

A three-week plan

The plan 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 the drill-down notes for your system, levels 1 to 8. Find the answers you are missing for levels 4 and 7.	Record a two-minute walkthrough of your system twice.
2	Build the small LLM streaming project from step 3, with a fake model in the tests. Prepare your three edge topics and your questions.	One AI-allowed coding practice, recorded. Answer the company problem once, with a timer.
3	Read your notes again. Fix what the practice showed you. One coding practice without AI.	Answer the company problem again. 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.