What an AI interview loop actually contains.

The first conversation is usually with a recruiter or sourcer rather than an engineer, and it runs twenty to thirty minutes. On the surface it is logistics: what you have worked on, what you are looking for, whether the location and start date line up. Underneath it is a routing decision. The recruiter is working out which team and which level to put you in front of, and whether the loop is worth the four to six engineer-hours it will cost.

For AI roles this call carries more weight than it used to, because the titles have stopped meaning anything consistent. "AI Engineer" at one company is a product engineer wiring up a model gateway; at another it is someone writing training code. The recruiter's job is partly to resolve that ambiguity before an interviewer wastes a slot on it. If you describe your work in terms that map cleanly onto a specific opening, the routing gets easier and you tend to land in the loop you actually wanted.

Nothing here is technical in the sense of being graded on correctness, but it is technical in the sense that vague answers cost you. A recruiter who cannot summarise what you build in two sentences will write two vague sentences in the notes, and the hiring manager reads those notes before deciding whether to approve the loop.

The first engineer-run stage is a filter, and it is scored more coarsely than the later rounds. Typically it is forty-five to sixty minutes in a shared editor with one interviewer, and it takes one of three shapes: a general coding problem, a practical ML or data exercise, or a short debugging task on code you are handed. For AI roles the second and third shapes have become more common than the first, because a company hiring someone to run a retrieval pipeline learns more from watching them fix a broken evaluation loop than from watching them invert a tree.

The practical variants look less like competitive programming and more like a small piece of real work: implement top-k retrieval over some embeddings and explain your similarity choice; write the batching logic for an inference loop; take a scoring function that is silently wrong and find out why. The code is small. The reasoning around it is the point.

The general coding variant has not disappeared, particularly at the larger employers, and it is usually easier than the reputation suggests — one or two medium problems rather than anything exotic. What has changed is the interviewer's tolerance for silence. In a screen this short, an interviewer who cannot follow your reasoning has nothing to write down, and a correct solution arrived at silently scores worse than a mostly-correct one narrated well.

Sixty minutes, an open prompt, and a whiteboard or a shared drawing surface. "Design a support assistant over our documentation." "Design an agent that files expense reports." "Design the evaluation system for a feature you already shipped." The problem is deliberately underspecified, and the first ten minutes of the round are about making it specific.

This round is where seniority is decided. The same prompt is given to mid-level and staff candidates, and the difference in the transcript is not vocabulary — it is which questions the candidate asks before drawing, and whether the design is defended in terms of cost, latency, and failure or in terms of components. A mid-level answer names the pieces: an embedding model, a vector store, a reranker, a generation call. A senior answer prices them, budgets the latency across them, and says what happens when the third one is down. A staff answer does that and then explains which parts other teams should be able to reuse without asking permission.

AI system design differs from classic distributed-systems design in one specific way: the core component is non-deterministic, so correctness is a rate rather than a property. Every design decision eventually meets the question "how would you know if this got worse?", and a design with no answer to that has not really been designed. The evaluation and observability half of the answer is not a coda to be reached if time allows; at most companies it is a scored section of the rubric.

Somewhere in most AI loops there is a round where you build something rather than describe it. It comes in two forms. The take-home is a scoped problem — four to eight hours if the company is being honest about it — done on your own time and submitted as a repository. The pair-programming session is the same idea compressed into ninety minutes with an engineer in the room, usually against a codebase they hand you.

In both cases the artefact is not really the deliverable. The follow-up conversation is. A take-home that is never discussed is a weak signal and most companies know it, so the submission is normally followed by a review round where two engineers ask why you chunked that way, what your evaluation set actually measures, and what you would do with another week. Candidates who build a large, undocumented submission and cannot defend its decisions score worse than candidates who build something small and can.

The pair session tests something adjacent: whether you are pleasant and productive to work next to. You will be given an unfamiliar repository, a failing test or a feature request, and an engineer who will answer questions if asked. Asking is not penalised. Silently guessing at a convention you could have asked about in ten seconds usually is.

Take-homes are contentious for good reason — they tax people with less free time — and a growing number of companies pay for them or replace them with the paired version. It is reasonable to ask which one is offered, and reasonable to ask for the paired format if the unpaid hours are a genuine problem.

Usually forty-five to sixty minutes, often with the hiring manager and sometimes with a trained interviewer from outside the team. The format is structured: a question about something you have actually done, followed by follow-ups designed to find out whether you did it. "Tell me about a time you disagreed with a technical decision." "Describe a project that failed." "Walk me through something you shipped that you would build differently now."

Engineers routinely under-prepare this round because it feels soft. It is not scored softly. Most companies use a rubric with named dimensions and a written score per dimension, and a weak behavioural round sinks candidates who cleared every technical stage. The reason is straightforward: technical rounds establish that you can do the work, and this round establishes whether the team wants to do it with you for the next three years.

For AI roles there is now a second layer. Interviewers ask about judgement calls with consequences — shipping a feature you knew had a failure mode, handling data whose provenance was unclear, what you did when a model behaved badly in production, how you decided something was ready. These are not gotchas. They are the questions a company with real deployment risk has learned to ask, and a candidate who has never thought about them is a candidate who will need supervision.

The other half of the round is yours. What you ask reveals what you will care about once hired, and hiring managers read it that way.

Once the loop is scored there are two remaining questions: which team, and on what terms. At larger companies these are separate steps, and team matching can take weeks — you are introduced to managers with open headcount, you talk to each, and both sides express a preference. At smaller companies you interviewed for one team and this collapses into a single conversation.

Team matching is genuinely important and routinely rushed. Within one company the difference between two teams is larger than the difference between two companies: what you will actually work on, whether the work is funded past this quarter, who you will learn from, and how visible the output is. Candidates who accepted the first available team and regretted it usually regret the team, not the employer.

Then the offer. Compensation for AI roles has been volatile, structures vary widely, and the headline number is often the least informative part. Equity terms, refresh policy, vesting schedule, bonus structure, and level all matter more over four years than the base salary does. Level is the one people forget to negotiate and the one that compounds — it sets the band, the expectations, and the starting point for every subsequent conversation.

Negotiation at this point is normal and expected. The company has spent significant time on you and does not want to restart. A single, well-reasoned, polite ask is standard practice and rarely costs anything; the risk lies in aggressive tactics, invented competing offers, and reopening terms that were already settled.