Learning agentic AI for an interview in a week

On August 4, my Google recruiter told me there would be one more round before team matching: a team-specific domain interview on agentic AI. The topic list was multi-agent orchestration with frameworks like LangGraph and CrewAI, LLM optimization, evaluation, safety with humans in the loop, dynamic context compression, ReAct and DAG execution patterns, and LoRA with supervised fine-tuning. The first estimate was that it would happen in about two days.

I had built an agentic system in production. I had designed its orchestration, its safety layer and its cost routing. I had never used LangGraph or CrewAI in production, and several items on the list were things I had done without ever learning their standard names.

The round ended up on August 12, eight days after that call. This post describes how I used those days: mapping what I had built onto the vocabulary the interviewer would use, rebuilding teaching sessions that did not stick, running a mock per topic, and fixing the clusters of “I don’t know” those mocks exposed. It is part 13 of the 35 companies, 8 offers series. As with every Google post here, I do not describe the questions from the real round.

For context, by this point the main loop was done: Strong Hire on the ML domain round and on Googleyness and Leadership, and Hire on both coding rounds. This round was part of finding a team.

The short version:

• Topics: 7 blocks, from orchestration frameworks to fine-tuning
• Preparation time: 8 days from the recruiter’s call to the round
• Mocks: one per block, plus a blind-spot analysis and a 20-question evaluation bank
• Outcome: advanced to team matching, hiring committee approval and the offer

Background: knowing the thing without knowing its name#

The gap was not that I did not understand agents. It was a vocabulary and framework gap, with a few genuine knowledge holes underneath.

I knew the patterns under different names. My previous system used a custom orchestrator that executed plans as a directed acyclic graph (DAG) of steps, deliberately not an open-ended reasoning loop, because every action had to be auditable. The interview would use framework terms: graphs of nodes with shared state, checkpointing, crews of role-based agents, reflection. I needed to map one vocabulary onto the other fluently.

The list was broad. Seven blocks, each a field of its own, in a week. Depth everywhere was impossible; I needed to know where a strong answer would be expected and where a clear, honest outline would do.

My first teaching sessions did not stick. On August 4 and 5 I worked through the blocks in long explanatory sessions. Within a day it was clear that two of them, context compression and LLM optimization, had not landed. I could follow the explanations; I could not reproduce them.

Fluency in a framework’s vocabulary is not the same as having built systems with it, and an interviewer can tell the difference within two follow-ups. My goal was to speak the vocabulary accurately while staying honest about where my production experience came from.

The preparation architecture#

The week ran as a loop over seven blocks, with each block going through the same stages.

graph LR
    A["Recruiter's<br/>topic list"] --> B["Seven blocks"]
    C["Resume revised<br/>to surface topics"] --> B
    B --> D["Teach-first<br/>session per block"]
    D --> E["Question bank<br/>per block"]
    E --> F["Mock per block"]
    F --> G["I-don't-know<br/>clusters"]
    G --> H["Targeted coaching<br/>and retest"]
    H --> E
    F --> I["Blind-spot analysis"]

    class A,C gray
    class B amber
    class D,E violet
    class F amber
    class G red
    class H,I green

Before any studying, I revised my resume to surface the recruiter’s topics, one section at a time with an approval gate between sections; that process is covered in the resume post. Six of seven sections changed. The revision mattered because a team-specific round is often built from the resume, and every topic on the list needed a line on the page that pointed to real work.

Mapping my system onto framework vocabulary#

The first block was the one I worried about most, and it turned out to be the most tractable, because the underlying ideas were ones I had already used.

Workflows versus agents. Anthropic’s guide to building effective agents draws the distinction I needed: workflows are systems where LLMs and tools follow predefined code paths, while agents are systems where the model dynamically directs its own process and tool use. My orchestrator was a workflow by that definition, and I had chosen it on purpose, because auditability mattered more than flexibility. Being able to say that, with the reason, was worth more than any framework detail.

ReAct as the contrast case. ReAct interleaves reasoning steps with actions such as tool calls, letting the model plan and adjust as it goes. I prepared to explain when I would choose a ReAct-style loop (open-ended tasks, cheap and reversible actions) and when a planned DAG (regulated or irreversible actions, where every step must be validated before it runs).

Frameworks as vocabulary, not as identity. The same guide recommends starting with LLM APIs directly and understanding what a framework does underneath before relying on it, because wrong assumptions about what is under the hood are a common source of errors. That gave me an honest position: I had built the primitives myself, I understood what LangGraph’s graphs, state and checkpointing would replace in my system, and I could say where I would and would not use a framework.

In the mocks this block still had gaps: a clear taxonomy of agent failure modes and how to observe them, how to choose a framework, how to ground a reflection step so the model does not merely agree with itself, how to version tool schemas, how to re-plan in the middle of execution, and how to retrieve from agent memory. Most of them were things I had handled ad hoc in production without a name for the pattern.

Rebuilding what did not stick#

The two blocks that had not landed were rebuilt in a stricter format: one question at a time, with the theory, the context and a strong-hire answer line given before I was tested, and the pace set by me saying “next” rather than by the coach. It was slower per question and much faster per retained idea.

Context compression was rebuilt as a ladder of techniques, from cheapest to most invasive: trimming old turns, masking bulky tool outputs, summarizing with an LLM, and at the level of the model’s memory, evicting entries from the key-value cache. The paper on attention sinks explained one counterintuitive piece: the first few tokens attract strong attention even when they carry little meaning, so a cache that keeps them alongside a window of recent tokens can process far longer streams. The rebuilt block also covered what triggers compression, how to split a context budget between instructions, memory and tool output, how compression interacts with the cache, how it fails, and how to evaluate it.

LLM optimization was rebuilt around the questions an engineer actually faces: what to quantize and when, the difference between quantizing after training and training with quantization in mind, why generating tokens is limited by memory bandwidth rather than compute, how grouped-query and multi-query attention shrink the cache, and where fine-tuning fits. For fine-tuning, the QLoRA paper was the anchor: small low-rank adapters trained on top of a 4-bit quantized base model, which makes fine-tuning large models feasible on modest hardware. I had used QLoRA in production, so this was where precision about exactly what I had done mattered most.

What the mocks exposed#

From August 9 to 11 I ran a mock for each block, in the clean-room mode described in the post on running prep on Claude. The table below summarizes the clusters of “I don’t know” answers each one surfaced.

The safety block was the biggest surprise. I had built a system whose whole selling point was safety, and still could not answer half the questions, because my safety came from validating actions before execution, while the questions were about what happens after: retrying an action without doing it twice, undoing a multi-step operation that fails halfway, and proving afterwards who did what. That is a different half of the problem, and I had not needed it in production.

Alongside the mocks I built a 20-question evaluation bank from fresh web research, and ran a blind-spot analysis across all seven blocks that surfaced four more topics to coach.

The mocks also changed my delivery. My answers were too long. I kept bridging every answer back to my previous system, even when the question was general. And I described system behavior in the first person when a neutral description was clearer. By the last mocks, answers were shorter, the bridge appeared only when it added evidence, and I described designs in the third person and my own decisions in the first.

Results#

I advanced. Without describing the questions, the round was strongest where it touched system design for things I had built, and weakest on the internals of serving large models across hardware. The most damaging moment was an answer about my own past fine-tuning work that, under follow-up, contradicted something I had said earlier about who did what. My coach’s read afterwards was a lean hire, borderline. The next day I wrote out ideal answers for every question I had fumbled.

The process moved forward anyway: a team fitment call with the hiring manager on August 17, hiring committee approval, and the offer, which I signed on August 31.

What I’d do differently#

Learn the standard vocabulary for what you have built. I had done most of what was on the list. I had not learned its names, which made real experience sound vague. A glossary of standard terms for every system on my resume should have existed long before this round.

Keep claims about your own work exactly consistent. The worst moment of the round was not a knowledge gap. It was an inconsistency about my own contribution. A one-page statement of what I personally built, trained and decided, versus what the team did, would have prevented it.

Learn the infrastructure under the models. My preparation was strong on orchestration and weak on hardware: how models are split across GPUs, and why the two phases of inference (processing the prompt and generating tokens) behave and cost differently. For a team close to ML infrastructure, those are fundamentals, not trivia.

Start every unfamiliar topic teach-first. I lost two days to explanatory sessions that did not stick. The one-question-at-a-time format should have been the default from the first hour.

Conclusion#

A week is enough to learn a field’s vocabulary and map your experience onto it. It is not enough to fake experience you do not have, and the round will find the difference. What worked was honesty about where my knowledge came from, precise vocabulary for things I had built, a teaching format that forced me to produce answers rather than read them, and a mock per topic to show me exactly where the gaps were.

Know what you built, know what it is called, and know exactly which parts were yours.

Part 13 of the 35 companies, 8 offers series. I join Google as a Software Engineer III, AI/ML, in October 2026.