AI Engineer Interview Questions — Entry Level

The word doing the work is shipped. They are separating people who have deployed something and watched it behave from people who have a notebook.

Give the shape in ninety seconds: what it does, who uses it, roughly how much traffic, and what you own when it breaks at 2am. If the honest answer is an internal tool used by nine people, say that — an internal tool that is genuinely in use beats a side project with a landing page, and everybody in the room knows it.

The second half is the question. Anybody can list model names.

Give a reason that has a constraint in it — cost per request, latency at the ninety-fifth percentile, a context window you needed, a data-residency rule that ruled out an API, an open-weights model because the workload could not leave your own infrastructure. Any of those makes you sound like somebody who chose. "It was the best one" makes you sound like somebody who read a leaderboard.

Small talk, and the most consequential question in the screen: the answer decides which loop they put you in. Get it wrong and you spend four hours being assessed against a job you did not apply for.

The distinction people actually hire on, stripped of the argument: an ML engineer is accountable for a model, an AI engineer is accountable for a system that contains somebody else's model. One owns the training data, the objective and the retraining schedule. The other owns retrieval, context, evaluation, failure behaviour, latency and the bill — and reaches for fine-tuning last rather than first. Neither is the senior one, and apologising for never having trained anything from scratch is a strange move in a job whose premise is that somebody else already did.

There is a third job hiding under the title. When those seven thousand postings were sorted by what the work actually is, about seven in ten were building features on foundation models, about a quarter were platform work for other people's AI teams, and roughly one in twenty was traditional machine learning renamed. If the advert talks about enabling teams rather than shipping a feature, expect infrastructure questions.

Say which one you are in a sentence, then say which parts of the others you can hold. That second clause is what stops it sounding defensive.

A currency check wearing friendly clothes. Have one real reversal ready with the reason attached — an approach you dropped, a tool you stopped defending, a technique you over-used. "Nothing comes to mind" is a bad answer in a field that moves this fast.

Give a researched range whose floor is a number you would sign. Titles in this field are noise — the same three words cover a €55k support role and a €190k platform role — so anchor on the scope you were just describing, not on the title in the advert.

Asked everywhere now, scored as a competency at several of the companies above, and answered badly in both directions. The candidate who says they do not use them sounds incurious. The candidate who says the tools write most of their code sounds like somebody who has never had to debug what came back.

The answer that lands names the split. Where you hand work over — scaffolding, tests from a spec you wrote, a first pass at unfamiliar syntax, migrations. Where you do not — anything you will be paged about at 3am, anything touching money, and the design decision itself. Then one sentence on how you check what comes back, because that is the actual competency and everybody skips it.

If you have been burned, say so. A specific story about a plausible-looking function that was subtly wrong is worth more than any position on the subject.

Two sentences is the instruction and also the test. A candidate who talks for four minutes about queries, keys and values has told them they cannot compress.

Something close to: every token gets to look at every other token and decide how much each one matters to it, and the model learns what "matters" means. Then stop. If they want the matrix multiplication they will ask, and being asked is a better position than volunteering it.

The decision question of the role, and the strongest answer is the one that puts fine-tuning last.

Retrieval is for knowledge the model does not have — your documents, your prices, anything that changes. Fine-tuning is for behaviour the model will not hold: a format it keeps drifting from, a tone, a narrow classification where a small tuned model is cheaper and faster than a large prompted one. Prompting is for everything else, and it handles more than people admit.

Then the sentence they are waiting for: fine-tuning does not reliably add facts, it makes them harder to change, and it commits you to a retraining loop the day the data moves. Candidates who lead with fine-tuning are usually describing a problem retrieval solves.

If you never have, say so and say what you did instead — that is a completely acceptable answer and it is better than a vague one.

If you have: name the base model, the size of the dataset and where it came from, the method, and the thing that changed. Then be honest about whether it was worth it. "We fine-tuned a small model for classification and it was six times cheaper at the same accuracy" is a real reason. "It improved quality" is not a reason, and the follow-up will be measured how, which lands you back in the evaluation section.

Refuse the abstract version. Ask what the false positive does and what the false negative does, then answer for the actual system: a retrieval step usually wants recall because the reranker can clean up after it, and a moderation step usually wants precision because every mistake is a person.

Whether that column exists at prediction time. A feature that is only populated after the outcome it predicts is leakage, and it is the reason a model can score beautifully offline and be worthless the day it ships.

A graduate portfolio project works now. That is new, and it means the project stopped being the thing that gets graded.

What gets graded is whether you can account for it. Expect them to open a file and ask why a number is that number — why 512 and not 1000, why cosine, why three retries. There is nothing wrong with "the assistant suggested it and I kept it because it worked". There is a great deal wrong with not knowing that this is the answer.

So say what you wrote, what you generated, and what you copied. Then say what you changed after it did not work, because that is the part a tutorial cannot hand you.

Two words, and it is the question in this set worth preparing properly.

They are not asking for a bug. They are asking whether anything you built has ever met a person who was not you. A project only ever run by its author has never been wrong in a way that cost anybody anything, and the candidate cannot describe the moment it was.

So find the moment. A friend phrased a question in a way you had not imagined. The demo failed in front of a supervisor. It answered confidently about a document that does not exist. Say how you found out, say what you changed, and say whether you would find it faster now.

They are not asking for a methodology. They are asking whether the thought has ever occurred to you.

The honest answer, when it is "I tried it", feels like an admission and gets dressed up. Do not dress it up. Say it, because they already know, and then say what you would build with another week in enough detail that it is obviously a plan rather than a wish.

A plan that lands: thirty questions in a file with the answer you expect beside each, deliberately including the awkward ones you know it gets wrong. Deterministic checks first, because they cost nothing — did it cite anything at all, did the output parse, did it refuse when there was nothing to answer from. Then read the failures instead of counting them.

If you have actually built that file, open with it rather than waiting to be asked for it.

The follow-up to the last one, and it is a trap whose right answer sounds like a confession.

If you wrote your test questions while looking at the documents you indexed, your test set is a copy of your system's homework and it will flatter it. Say so. The fix is cheap and saying it is the whole answer: have somebody else write the questions, or write them from what a user would want rather than from what the corpus happens to contain — and keep the ones it fails instead of quietly deleting them.

It sounds like a challenge and it is not. A team that wanted somebody who trains models would not be interviewing a graduate whose project calls an API. They are asking whether you know what you are and can say it without flinching.

Three beats. What the job actually is — assembling and evaluating a system around a model you did not train. What you have therefore practised: retrieval, context, failure behaviour, cost. And what you have not: a training run, a dataset you had to clean at scale, anything at the size where the infrastructure becomes the problem.

Then the sentence that turns it around. Name the part of the other job you would need help with first. A candidate who cannot name it is read as not knowing where their own edge is, which is a worse answer than having a narrow one.

The temptation is to answer "none", and that is the only answer that fails outright.

Name two, and pick things a graduate is genuinely allowed not to know — what the embedding model is doing internally, why a reranker helps when you cannot derive it from first principles, what the provider's rate limiter does under load. Then say which one you looked into and what you found.

The other failure is a false gap: naming something you obviously do understand in order to look humble. It gets caught immediately, because the follow-up question gets answered.

It is easy to build one of these and never once look at the bill. Any real number is a good answer — eleven dollars over a weekend is a real number. If you never looked, say you never looked and say what you would measure first, because "per request, split by route" is the entire answer and it takes four seconds to give.

Three questions that arrive as one: why retrieval and not fine-tuning, why that model, why that framework.

All three are asking whether you chose or whether you followed, so answer all three the same way — what the alternative was, why you did not take it, and what would make you switch now. "It was in the tutorial I started from" is a perfectly acceptable answer when the next sentence says what you would do differently.

One warning about the framework question. A candidate who criticises the framework they used without being able to say what it saved them is repeating a complaint they read, and the interviewer has probably read it too.

Not what should happen — what your code does today.

It is easy to answer this with a design for a system you have not built. The stronger move is to say plainly that nothing happens: there is no log, nobody would ever know, and the user would just leave. Then say the smallest thing that would change that, which is writing the question and the answer to a file with a timestamp on it.

A real entry-level exercise, and it sits exactly where the two halves of this job meet: an ordinary string-handling problem in which every decision is a retrieval decision.

Write the boring version and say that is what you are doing — split on a separator, respect a maximum length, overlap by a fixed amount. Handle the paragraph that is longer than the maximum, because that is the case they are watching for. Then say out loud what you would want instead if this were real, which is splitting on structure rather than on length.

Do not open by discussing semantic chunking. Write the loop.

Asked because the first six months of the job are exactly that. An open-source repository you genuinely opened counts, and being able to say what confused you in it counts for more than saying you liked it.

Not a security interview, and not a trick. It is a check on whether your idea of a user has ever included somebody who is not you — a project only its author has run has never been handed anything its author did not think of.

Answer in two directions. The clumsy one: an empty box, forty pages pasted in at once, a question in a language your documents are not written in. Say what your code does today, and "it throws and the page never comes back" is a real answer. The deliberate one: somebody who types instructions instead of a question and tries to talk past you to the model. Say what, if anything, keeps your own instructions and their text apart.

Then name the smallest fix as the small thing it is: a length cap, a refusal when retrieval comes back with nothing, and keeping user text out of the field your own instructions sit in. Naming one boundary you could draw beats saying the model handles it.

Asked kindly and meant seriously. If you came through a machine-learning degree you may want the research job and be applying for this one because it is the one that exists, and there is no shame in that.

If that is you, say so, and say why you would still be here in two years — wanting to watch something you built get used is a good reason and it survives the follow-up. If it is not you, do not perform enthusiasm for a paper-reading group. The answer that loses is not the ambitious one; it is the one that leaves the interviewer unsure which job you would take.

The closing question, and an invitation to be specific about supervision without sounding like somebody who needs managing.

Ask for the two things that are actually scarce: somebody to review your first pull requests against a real system, and access to whatever the team already uses to see what production is doing. Wanting a mentor is a fine answer. "Opportunities to learn and grow" is not an answer, and it is the one they hear.