Interview loops: what they actually run

AI Delivery / Transformation: recruiter, hiring manager, case (the chatbot-by-Friday), panel with a business partner, sometimes a take-home charter. FDE: recruiter, technical (Python + LLM concepts), customer scenario, maybe a small RAG take-home, values. Solutions: discovery roleplay, whiteboard architecture, a panel with sales. AI PM: product sense with evals, a spec, a stakeholder round. Memorize your primary's shape. Skim the others so a noisy title does not surprise you.

Recruiter screens are not small. They are a fit filter against the posting and a personality filter against "will this person embarrass us." Give them the 90-second intro, the seat, and one number. Do not give them a tour of five seats. Do not correct their title inflation in a lecture; map it: "Your posting says AI Architect; the bullets are operating cadence and evals — that is the work I do." Then ask the 90-day question from day 22: building, steering, or selling? If they cannot answer, note it. You may still proceed. You will not prep the wrong loop on a guess.

Hiring-manager rounds are a judgment filter. They will pick a case or a "tell me about a time." Have the messy-program story ready so you do not invent one while anxious. Have the demo story and the pack ready so you can offer: "I can walk a slice or a charter." Let them choose. Managers are scoring whether they can put you in front of their worst stakeholder next month. Buzzwords lower that score. A specific no raises it.

Panel rounds are a consistency filter. The engineer, the business partner, and the manager will compare notes. If you told the recruiter you were FDE and told the manager you were transformation, you will fail without anyone saying why. Same pair, same artifacts, same honesty sentence. Adjust altitude, not identity. You already know how to brief a CFO and an ops director differently without becoming two people. Do that.

Values / culture rounds are not a free pass. They will ask about a fight, a kill, a time you were wrong. Use a real program. Do not use a story where you were the hero and the stakeholder was a cartoon. The adult version is: here is what I wanted, here is what they wanted, here is the call I made, here is what I would do with an eval bar now. Connecting an old story to an AI muscle is allowed if it is one paragraph at the end, not a retrofit of the whole past.

Every loop has a "can we put them in front of a customer / exec" round. That is your home game. Clarity, judgment, no bluff. Not buzzwords. Prepare it as seriously as the technical. Delivery managers sometimes under-prep this round because it feels like their job. Then they ramble, because they did not time it. Time it. Ninety seconds. Five minutes. Stop. Leaving air in the room is a skill. Filling it is a tell that you are nervous and junior.

Who you are, the scale of mess you have run, the AI muscle, the seat you want, a hook for them to pick ("I can walk a wiki copilot design or a charter — which is useful here?"). Stop. Let them steer. Do not spend four minutes on your first job. Do not list tools. Do not apologize. Time it. If you are over 90 seconds, you are touring. If you are under 40, you skipped the number or the hook.

Stealable skeleton: "I am a delivery lead. Last three years I ran [type] programs — [number: vendors / sites / months] — messy data, steering every month. The hole I kept hitting was [knowledge / exceptions / reporting] living in people's heads. I now design thin slices: retrieval, evals, HITL, cost at 10×. Independent work, not a production claim. I am targeting [primary role] seats. I can walk a wiki-copilot design or a one-table operating pack. Which is useful here?" Rewrite with your nouns. Then speak it until you do not need the page.

The hook is doing two jobs. It offers them a choice, which makes you look like a professional who can read a room. It also stops you from dumping both stories. If they say "start wherever," pick from their title: engineer → demo, director → pack. If they are a recruiter, they want the seat and the availability, not the six boxes. Give recruiters the intro without the hook, and add "happy to walk artifacts with the hiring manager."

Do not open with your origin story. "I started as an analyst in 2009" is how you spend the 90 seconds on a decade they did not ask for. One clause of origin is enough if it is load-bearing ("I came up in operations, not in IT, which is why I care about the roster for HITL"). Otherwise skip it. The last three years plus this month are the relevant tape. Older proof can live in the five-minute messy-program story if they ask.

Record it. Listen for filler ("sort of," "I think," "passionate"), for a missing number, and for a missing honesty clause. Listen for whether a stranger could name the seat after one play. If you cannot record, stand up and say it to a wall twice. Writing only is how intros become essays. This clip will also open day 29. Author it once.

If they interrupt at 30 seconds, let them. The intro is a menu, not a speech. An interrupt is a gift: they are steering. Answer the interrupt. Do not "just finish this thought." Delivery managers who cannot be interrupted in a screen will not be interruptible in steering either, and everyone notices.

Every loop will ask a version of "tell me about a messy program." Prepare one, not three. Stakeholders, a hard call, the outcome, and a final paragraph of what you would do with AI now if it is relevant — one paragraph, not a retrofit. If you cannot name the hard call, you do not have a story. You have a tour of a program that went fine. Fine programs do not score.

Structure: 60 seconds context (what, scale, who was mad), 90 seconds the tension (two goods in conflict, not a villain), 90 seconds the call you made and what you paid, 60 seconds the outcome including what stayed broken, 30 seconds optional AI coda. Example coda: "Today I would have put an eval bar on the vendor's knowledge bot instead of accepting the demo that became our reporting source. I did not have that muscle then. I do now." That coda is honest. "I would have used generative AI to transform the program" is not a coda. It is a slogan.

Pick a story where you were inside the decision, not adjacent. "I was on a program where the director decided" is a weak story. "I took the month-nine cut to drop a vendor workstream because UAT would have been theatre" is a strong story. If your title meant you were adjacent, pick a smaller decision you actually owned: a scope cut, a go-live delay, a RAID you forced into steering. Size is less important than ownership. Interviewers can tell.

Do not villainize the stakeholder. The ops director who refused the go-live was doing their job. The vendor who could not hit the date had a constraint. You can still say they were wrong. You cannot say they were stupid. The five seats all require you to sit next to people like that. A story that ends in contempt is a story that fails the customer/exec round even if the facts are true.

Practice the close. People ramble at minute four because they do not know how the story ends. The end is: the call, the price, the outcome, one sentence of what you would repeat. Then stop. If they want more, they will ask. A clean stop is a delivery skill. It is also how you leave time for their actual question, which might have been about conflict, not about AI. Answer the question they asked. The AI coda is optional and last.

Write it once, speak it twice, file it next to the intro. This story is not the demo story. Do not replace a real program with Atlas. Atlas is a design. The messy program is your proof that you have been in weather. The five seats are buying both. If you only have Atlas, you will sound like a course. If you only have the old program, you will sound like a DM who has not done this month. Both clips, both days.

A stealable close, then make it yours: "We cut the vendor workstream in month nine because UAT would have been theatre. It cost us a steering fight and a slipped date. The outcome was a smaller go-live that actually ran. What stayed broken was the relationship with that vendor for a year. I would repeat the cut. Today I would have put an eval bar on their knowledge demo instead of accepting it as the source of truth. I did not have that muscle then. I do now." Time it. If it exceeds five minutes, cut the tour of the org chart, not the call.

They want: can you read a JSON payload, explain RAG vs fine-tune, name an eval, talk cost, not panic. They do not want your LeetCode-from-YouTube. If you do not know, say what you would try and who you would pull in. Invented APIs are how you fail. A calm "I have not used that library; here is how I would read the docs and what I would measure" is a pass for a delivery-shaped FDE screen. A fluent wrong answer is a fail.

Expect a small cluster of questions. What is a token and why do we care? What lives in the context window? Why does the model invent? What is RAG for, and when is it the wrong object? What is an eval? What is HITL at assist vs confirm? What does a cost envelope at 10× look like? Why not an agent for v1? You have spent three weeks on these. Answer in short sentences with an example from Atlas or from a real program. Do not answer with a blog structure.

If they put a Python snippet on the screen, they are scoring whether you freeze. Read it out loud in English: "this loads files, this chunks, this calls an API, this prints. I would change this constant to point at a different folder." That is enough for many FDE first screens. If they ask you to write a function and you cannot, say: "I can read this and change constants. I would not write the auth layer. I would pair." Then stop. Do not start a tutorial from memory and get it wrong. Wrong code is worse than a named edge.

JSON is the data shape of this work. A message is a dict with role and content. A chunk is text, source, score. If they ask you to look at a payload, name the fields and what you would check (empty content, missing source, a score below your floor). This is the week-2 bar. If you skipped week 2 and your primary is FDE, do not apply this week. Close the gap. If your primary is delivery, still be able to read the payload. Someone will show you one to see if you bluff.

RAG vs fine-tune vs agent, one minute: retrieval when facts change and must be cited; fine-tune when the job is format or tone on a stable task and you have data and an owner for retraining; agent when you have tools, a bounded action space, and HITL on the expensive call — not as a default. You have a reason, not a preference. If they push "but agents are the future," do not fight the future. Fight v1: "v1 has no write tools. An agent would add blast radius we have not earned. v1.5 might add one read tool."

Write the eight-sentence technical stance today and keep it in notes. Include one "I don't know yet." Example set: I can design a RAG slice and an eval. I can read a 40-line Python script and change constants. I have not written production auth. I can cost a workload in a band. I will not freelance a consumer API. I do not train models. I would pull an engineer for the pipeline. I would own the golden set and the kill. That stance is hireable. "I can learn anything" is not a stance.

Cap at 4–6 hours. Deliver a design + a small eval table, not a weekend product. A take-home that asks for a full app unpaid is data about the company. You may decline politely and offer a live walkthrough of your existing artifacts. You may also do a thinner version and state the cap in the README: "Six hours. Here is the slice, the eval of 15 questions, and the list of what I would do next with more time." That README is itself a delivery artifact.

What you will send, pre-decided: a one-page design (the six boxes with their nouns), a CSV or table of eval questions and scores if you ran anything, a short note on HITL and cost, a list of open questions. What you will not send: a deployed app on a personal cloud billed to you, a fine-tune, a slide manifesto, work past the cap because you got proud. Pride is how take-homes steal a weekend from day 29 prep. The loop is not your only loop.

FDE take-homes often look like "build a small RAG on these PDFs." Do the retrieve-and-eval. Make the refuse path visible. Do not polish a UI for four of the six hours. Solutions take-homes often look like "write the POC plan." Write clock, users, corpus, non-goals, eval bar, death date. Delivery take-homes often look like a charter. You have one. Adapt it; do not start from a blank page. Transformation take-homes often look like a memo diagnosing 12 POCs. Use day 27's spine and day 24's platform pushback.

When you decline: "I maintain a six-hour cap on unpaid take-homes so I can keep quality. I can send a design and a small eval table in that window, or I can walk my existing wiki-copilot pack live for 30 minutes. Which is more useful?" Some firms will pass. Those firms wanted a weekend of free labor. Some firms will take the walkthrough. Those firms are serious. You cannot know which until you offer. Offering is not arrogance. It is WIP discipline. You will write WIP limits into the job OS on day 30. Start now.

If you accept, start with the eval table, not the architecture. Fifteen questions, expected source, pass/fail. Then the six boxes. Then whatever time remains. That order means that if you run out of time, you still sent judgment. The reverse order means you sent a diagram and no bar. You already know which one a hiring manager can use.

Write the policy in four lines tonight, in the first person, and do not renegotiate it per-company unless the company has paid a trial or the take-home is the job (rare, and then it should be paid). Line 1: cap. Line 2: deliverable. Line 3: decline path. Line 4: start-with-eval rule. Put it next to the intro. Friday-night you is not a decision-maker. Friday-night you is a person who wants to be liked. Policy exists for that person.

You will be asked "do you have any questions?" Have three, not ten. The three should score the job the way you scored posts on day 22: the room, the first 90 days, the fail-gaps they still have. If you ask about benefits first, you look like everyone. If you ask about their model vendor first, you look like a hobbyist. If you ask about evals, death dates, and who owns the golden set, you look like the hire.

Stealable three. (1) "What does week one look like — am I in a customer tenant, a steering pack, or a discovery call?" (2) "When a use case misses its eval bar, who is allowed to kill it, and when did you last kill one?" (3) "Who owns the golden set today — and if the answer is nobody, is fixing that in the first 90 days?" Adjust nouns to the seat. Solutions might swap (1) for "how do you qualify a use case out of the pipeline." FDE might swap (3) for "what does the first slice usually look like on an account."

Listen to the answers as RAID. If they have never killed a use case, you are walking into a museum of POCs. If week one is "ramp on the platform" with no named user, you are walking into a platform-without-a-slice. If they cannot name a data class, you are walking into a legal freeze with a pretty title. You may still want the job. You should want it with open eyes. Write what you heard after the call. That note is how you pick among offers and how you write the 90-day plan on day 30.

Do not interview them with a TED question ("how are you thinking about the future of agents"). They will give a TED answer. You will learn nothing. Ask about a last decision. Last kill, last go-live, last time legal said no, last time a demo became production by accident. Decision questions produce specifics. Vision questions produce adjectives. You have spent a career in rooms that confused the two. Do not recreate the confusion from the candidate side of the table.

If they brag about speed ("we shipped 40 copilots this quarter"), ask how they know they work. If they brag about caution ("nothing goes out without a six-month review"), ask what the lightest approved path is. Both brags can hide a mess. Your job in the question round is to find the mess while still sounding like someone who can live in it. Contempt is not a question. Curiosity with a bar is.

Write your three questions at the bottom of the intro card. If you do not write them, you will ask a dummy question when you are tired. Dummy questions waste the last five minutes of a loop that was going well. You already know this from steering. The last five minutes are the ask. Tomorrow you will drill the case. Tonight you finish the clips and the policy. That is enough for one day.