The Agentic System Design Round
Explore how to effectively design an AI-based incident assistant during the Google Forward Deployed Engineer interview. Understand clarifying requirements, tracing requests through boundaries, enforcing permissions, managing failures and timeouts, and balancing latency and cost. This lesson prepares you to create defensible designs under interview constraints and adapt to interruptions while demonstrating strong reasoning and prioritization.
We'll cover the following...
- What to expect
- What interviewers look for
- Budget the explanation
- Clarify the incident brief
- Keep four areas visible
- Trace request R-27
- Trace the timeout
- Calculate the critical path
- Account for every attempt
- Define release evidence
- Revise the slow dependency
- Reuse the skeleton on other prompts
- In the interview
- Rehearse from blank
The whiteboard is almost full: UI, agent, search, incident API. Yet a listener still cannot tell whose identity reaches the API or what the employee receives when it times out. Completing that explanation is the central task of an agentic system-design interview. A defensible answer connects requirements, authority, evidence, failure outcomes, and economics within the available time.
What to expect
The agentic design round asks you to design an AI system for a realistic customer or internal problem. Treat the details below as typical rather than guaranteed, and confirm your own format with recruiting.
Format: About 45 minutes on a whiteboard or diagramming tool, starting from a short, deliberately vague prompt.
Scope: LLM-based systems: retrieval, tool use, orchestration, guardrails, evaluation, and the cloud infrastructure around them.
Interaction: Expect interruptions, changed constraints, and "what if this fails?" questions. The interviewer often plays the customer.
What interviewers look for
Requirements first: You clarify users, actions, sources, and operating targets before drawing.
A traced request: You walk one request through every boundary instead of only listing components.
Authority and safety: You show where identity and permissions are enforced, and that the model never decides them.
Failure handling: You define what the user receives when a dependency times out or evidence is missing.
Quantified tradeoffs: You estimate latency and cost, name alternatives, and say what evidence would change your choice.
These strong-answer elements are practice guidance, not Google's official hiring criteria. The rest of this lesson works one prompt end to end: an internal incident assistant.
Budget the explanation
Apply the Chapter 4 design framework with a clock: Clarify briefly, establish scope, trace a request, then defend the decisions that matter.
Use this 40-minute rehearsal allocation:
Minutes 0–4: Clarification.
Minutes 4–8: Requirements and exclusions.
Minutes 8–18: Architecture and numbered request trace.
Minutes 18–26: Authority and failure behavior.
Minutes 26–34: Evaluation, latency, and economics.
Minutes 34–40: Follow-ups and synthesis.
These are adjustable practice allocations. Public descriptions include compressed variants and differing formats; confirm your actual session with recruiting.
At transitions, invite direction: “The read-only flow is established. Would you prefer to examine permission enforcement or dependency failures next?” Integrate interruptions into the diagram rather than insisting on your schedule.
Clarify the incident brief
The prompt is “Design an internal incident assistant.” Spend the first four minutes asking questions that change the architecture:
Users and decisions: Who uses the answer, and what will they decide from it?
Actions: Can the assistant change systems?
Authority: Which sources own current status and approved procedures?
...