What Google FDEs Ship
Understand the key deliverables Google Forward Deployed Engineers provide for production handoff, including version-controlled code, automated tests, deployment configurations, and operational runbooks. Learn how to verify customer readiness and ownership while handling real-world constraints through practical examples and acceptance testing.
An inventory-query assistant works as demonstrated, but the engineer who built it is preparing to hand it over. What should the customer team receive and be able to verify during the delivery review?
The handoff should include:
Version-controlled application code and tested integrations.
Repeatable evaluation tests and version-controlled deployment configurations.
Operational runbooks with clearly assigned responsibilities for monitoring, incident response, and maintenance.
In this lesson, practise explaining these deliverables, the evidence that verifies them, and how they support customer ownership after deployment.
Recommendations, demo recordings, and architecture diagrams can support the handoff, but they do not replace tested code, deployment instructions, and operational documentation. The handoff is complete when the customer team has the access, documentation, and demonstrated ability to deploy, operate, and maintain the system.
What leaves with customers?
Google's GenAI FDE role emphasizes writing and debugging code, working with customer engineers, and deploying production systems within customer environments. This includes resolving integration issues, data-readiness problems, and state-management failures. The role also involves building production AI agent workflows and Model Context Protocol (MCP) servers, integrating with existing infrastructure, developing evaluation pipelines, implementing observability, and collaborating with customer engineers.
Together, these responsibilities result in a set of deliverables required for production handoff. These include application code and integrations, automated evaluations, reproducible deployment configurations, operational documentation, and the access required for ongoing maintenance.
During the delivery review, verify the following:
Application assets: Version-controlled source code, documented integration contracts, and supported workflows.
Evaluation assets: Representative test cases, expected outcomes, an executable evaluation runner, and recorded test results.
Deployment assets: Environment configurations, dependency versions, secret references, and a versioned release artifact.
Operational assets: Monitoring dashboards, operational runbooks, rollback procedures, documented limitations, and assigned support owners.
A source repository provides access to the implementation, but it does not establish production readiness. You still need to verify which release is deployed, which behaviors passed acceptance checks, and who handles changes to source data. A complete handoff links the deployed release to its validation results, operational procedures, and responsible owners.
Five concrete system outputs
The course blueprint identifies production AI agents, MCP servers, RAG pipelines, Text-to-SQL systems, and evaluation harnesses as potential FDE deliverables. It also covers customer handoff and ongoing operational reliability.
For each deliverable, understand its purpose and the components the customer must maintain after handoff:
Production agent: An application that orchestrates model interactions, tool calls, and workflow execution. Deliverables include orchestration code, authorized tool integrations, state management where required, and defined error-handling and recovery behavior.
MCP server: A server that exposes tools, resources, or prompts to MCP clients through the Model Context Protocol. Deliverables include tested integrations, documented input schemas, authentication and authorization controls where applicable, and actionable error responses.
Retrieval-augmented generation pipeline: A pipeline that retrieves relevant information from external sources and provides it as context for model-generated responses. Deliverables include ingestion and retrieval components, source-update procedures, and evaluations that check whether generated answers are supported by retrieved evidence.
Text-to-SQL system: A system that converts natural-language questions into SQL queries against permitted database schemas. Deliverables include query-generation logic, schema-aware validation, controlled database access, and tests for SQL correctness and result accuracy.
Evaluation harness: A test framework containing representative inputs, expected outputs or scoring criteria, an executable test runner, and recorded results. The harness helps detect behavioral regressions after changes to models, prompts, data, or application code.
These components can be used independently or combined, depending on the system requirements. A service that answers questions using structured database queries does not automatically need a document-retrieval pipeline. Similarly, introduce an MCP interface only when the integration requirements justify it.
Deployment configurations, operational documentation, and support procedures should reflect the system's architecture and operational requirements. For each design choice, establish how the customer will update, operate, and recover the system after handoff.
Scope three depots
Suppose depot planners at Alder Supply request an AI assistant to answer inventory questions. Alder operates three depots. The request does not specify which inventory data the assistant should use, what questions it must answer, or which actions it may perform.
Requirements discovery limits the initial release to answering two questions:
What is the current stock quantity for a given item at a specified depot?
Which items have stock quantities below their approved reorder thresholds?
Use the existing inventory report as the reference for validating answers. The data owner must confirm how the report defines current stock and reorder thresholds. Matching column names alone does not establish that the assistant uses the correct business definitions.
The initial release queries approved read-only inventory views and enforces each user's existing depot-level access permissions. It excludes purchase transactions, financial analysis, and modifications to inventory records. If a planner requests a purchase order, the assistant must explain that the action is unsupported and must not execute any purchasing operation.
Before implementation, the team defines the following acceptance criteria:
Answer correctness: Stock counts and below-threshold results must match the expected values calculated from the approved inventory definitions using the same data snapshot.
Access behavior: The assistant must enforce depot-level authorization so users cannot retrieve inventory data from depots they are not permitted to access.
Freshness: The data owner defines the expected refresh interval and the maximum acceptable data age.
Ownership: The customer engineering team owns application operations, while the data owner maintains inventory definitions and data-refresh requirements.
These acceptance criteria are specific to the proposed Alder Supply deployment. The acceptance criteria and interview exercises in this lesson are for practice. They do not represent Google's official hiring criteria.
Initial deliverables include a defined user workflow, a data and access-control diagram, acceptance test cases, and a decision record documenting the supported questions and excluded functionality. These artifacts establish a defined implementation scope with requirements that can be tested.
Discovery, scoping, implementation, rollout, measurement, and handoff are iterative. Failed acceptance tests or changes in customer constraints may require revisiting earlier design decisions.
The feedback paths matter because deployment findings change what the team knows. If planners use “stock” to mean something different from the approved report, improving the prompt against the old definition would preserve the misunderstanding.
Trace one stock request
A planner asks, "How many of this item are at my depot?" Trace how the proposed system processes the request and enforces access controls:
Identity: The service authenticates the user and determines which depots they are authorized to access.
Application: The application identifies the requested item using approved inventory records and requests clarification if multiple items match.
Query generation: The application generates a read-only query against approved inventory views using validated item and depot identifiers.
Database access: Application-level authorization and database permissions restrict the query to inventory data the user is allowed to access.
Result formatting: The application returns the stock quantity, depot identifier, and data timestamp or freshness status.
Logging: The service logs request identifiers, query status, and relevant execution metadata for troubleshooting, following the customer's logging and data-retention policies.
A model instruction such as "Only show authorized depots" does not enforce access control. The application and database must enforce authorization independently of model output, rejecting queries that attempt to access unauthorized data.
The production handoff package includes:
Implementation: Version-controlled application and database integration code, including mappings between inventory business definitions and approved database fields.
Data integration: Approved database view definitions and access-control configurations.
Verification: Automated tests, acceptance test cases, an executable evaluation runner, and test results associated with a specific release.
Release configuration: Environment configurations and references to securely managed secrets, with credentials excluded from source code and deployment artifacts.
Operations: Deployment instructions, monitoring dashboards, operational runbooks, and documented rollback procedures.
The customer data owner approves inventory business definitions and data-freshness requirements. The FDE works alongside customer engineers to implement the application and its integrations. This collaboration helps customer engineers understand design decisions, implementation details, and operational requirements before handoff.
Inspect the 40 cases
The team prepares an acceptance test suite containing 40 cases:
30 authorized queries: Stock counts and below-threshold inventory queries for depots the user is permitted to access.
Six unauthorized requests: Queries targeting depots the user cannot access, which the system must deny.
Four ambiguous requests: Item descriptions that match multiple records and require clarification before querying.
In the first test run, the system answers 27 of 30 authorized queries correctly, denies all six unauthorized requests, and requests clarification for all four ambiguous inputs. The overall acceptance test pass rate is (27 + 6 + 4) / 40 = 37/40, or 92.5%.
The delivery note states, "37 of 40 tests passed, so the release is ready." Before reading the diagnosis, assess whether the test results justify releasing the system.
Accuracy on authorized inventory queries is 27/30, or 90%. Correctly denying unauthorized requests and clarifying ambiguous inputs does not offset incorrect stock counts. Investigation shows that all three incorrect answers were generated using an outdated stock field. Because the incorrect field mapping is shared across queries, other inventory requests may also return incorrect results.
Document the diagnosis, correction, and regression test:
Diagnosis: Preserve the failed test results and inspect the generated SQL to identify references to the outdated field.
Correction: The data owner verifies the approved stock definition, and the FDE works with the customer engineer to update the field mapping.
Regression: Add a test fixture in which the outdated field contains 18 units and the approved current-stock field contains 12 units for the same item and depot. Verify that the system returns 12.
If both fields contained 12, the test could pass even when the query uses the incorrect field.
After the correction, all 40 original acceptance tests and the new regression test pass, giving 41 passing tests. The following artifacts provide a traceable record of the fix:
The original failed test records the incorrect stock count.
The query trace shows that the generated SQL referenced the outdated stock field.
The data owner's approved stock definition identifies the correct field.
The code revision updates the query mapping to reference the approved field.
The regression test fails if the query reverts to the outdated field for this fixture.
The release record identifies the corrected code version and its corresponding 41-test result.
Passing all 41 tests provides evidence that the release meets the tested acceptance criteria. It does not guarantee correct behavior for every possible input. The customer engineering team takes responsibility for maintaining the field mapping and regression test. The data owner remains responsible for communicating changes to inventory definitions.
Release to one depot
Passing the suite supports a limited rollout to one depot before expansion to the other two. That rollout tests real use, operating behavior, and whether the accepted scope matches planners’ work.
The rollout plan assigns signals and responses:
Task correctness samples: Customer engineering and the data owner review sampled answers against the approved report. A mismatch triggers investigation of query behavior and data semantics.
Stale-data events: The freshness responder checks the source refresh and ensures users receive appropriate messaging when current stock cannot be established.
Query failures: Customer engineering investigates through the dashboard and runbook, using the existing report as the fallback when necessary.
Response time: Customer engineering checks whether the service fits the planner workflow and investigates slow requests.
Access denials: Customer engineering checks for unexpected denials or suspicious patterns with the relevant access owner, without weakening controls to improve apparent success.
The business owner compares task completion with the existing report workflow. Request volume alone cannot establish usefulness: Repeated requests might reflect confusion or failed answers.
Keep the existing report available. Document how to disable the new service and how to restore the previous release. Expansion should depend on the agreed rollout evidence, rather than on the calendar alone.
At this stage, the team has a measurement plan, not observed savings, adoption, or latency improvements. If planner feedback reveals that a supported question was misunderstood, rollout findings return the team to discovery or implementation.
Rehearse customer recovery
A handoff meeting can explain the service. An operator rehearsal tests whether the customer can actually run it.
Arrange a rehearsal in which a customer engineer performs the following without the FDE doing the steps:
Deploy a tagged release using the supplied configuration.
Diagnose a simulated query failure using the dashboard and runbook.
Restore the previous release and verify service recovery.
Add an acceptance case and run the suite.
Retain the deployment record, incident notes, rollback verification, and evaluation result. If the operator needs an undocumented command, repair the instructions and repeat the relevant step. If they lack permission to roll back, the receiving team must arrange that authority before handoff is complete.
Customer ownership requires access, knowledge, authority, and demonstrated ability. In the interaction, remove one capability, predict what breaks, then reveal the consequences. Reset before each trial.
A capable operator with no deployment authority still cannot restore service. A complete runbook that nobody has used leaves its adequacy untested. These failures require different repairs: Permission changes for the first, an independent rehearsal for the second.
Record the continuing responsibilities explicitly:
Customer engineering: Application releases, mapping code and tests, first-line response, and recovery procedures.
Data owner: View semantics, refresh expectations, source changes, and data-freshness response.
Business owner: Usefulness, supported scope, and requests to expand it.
FDE: Remaining delivery work and further involvement under an agreed escalation arrangement.
List unfinished work and limitations alongside those responsibilities. Production ownership includes arranging and proving a transition; it does not require the original builder to operate the system indefinitely.
Maintain stock answers
Two later changes test whether the package remains useful:
Inventory schema change: The data owner communicates the proposed change. The application owner checks mappings and reruns regressions before releasing the adaptation. The contrasting-field case preserves the original defect’s lesson after the FDE leaves.
Delayed inventory refresh: Queries may succeed while returning old stock counts; a query-failure dashboard alone cannot detect this. The service needs a freshness signal, safe user messaging, and a named responder to investigate the refresh.
Long-tail reliability also includes changing permissions, dependencies, and user behavior. Assigned owners and regression checks make these changes actionable, rather than general warnings in a slide deck.
For practice, inspect the delivery memo below. It contains valid code and evaluation evidence, incomplete operational evidence, and an unsupported claim about customer capability.
Use it to:
Identify the unsupported conclusion and the evidence needed to repair it.
Write a short delivery review and a brief interview explanation.
Refine one entry in your own evidence inventory.
Retaining valid evidence matters: An incomplete handoff does not erase the corrected implementation or the 41-case result. The next work should resolve the remaining uncertainties through a freshness check, accepted response ownership, and customer-led recovery evidence.
In the interview
Use these three questions to practise explaining your engineering contributions, deployment decisions, and handoff responsibilities:
"What did you ship, and what was your contribution?"
Describe the supported workflow and identify the deliverables. Distinguish your implementation work from the customer engineering team's contributions and the data owner's decisions. For Alder Supply, identify the read-only inventory service, integration with approved database views, evaluation harness, deployment configuration, and operational documentation.
"What evidence supported the production release decision?"
Explain the acceptance criteria, test results by category, identified failures, corrective actions, and release decisions. Identifying the outdated field mapping and adding a regression test with different field values provides stronger evidence of engineering judgment than reporting the overall pass rate alone.
"How did you verify that the customer could operate the system after handoff?"
Explain the customer team's access permissions and operational responsibilities, any deployment and recovery procedures they completed independently, known limitations, and the escalation process. Distinguish recovery procedures the customer successfully tested from documentation provided without verification.
In your skills assessment, clearly identify outcomes you cannot verify. If you delivered code but did not observe the customer perform a rollback, document that limitation and identify how you would verify their recovery capability. This keeps your interview examples grounded in verified work rather than assumed outcomes.
Use these deliverables to compare responsibilities across customer-facing engineering roles. Identify who implements the production system, who supports the handoff, and how customer operational readiness is verified. The next lesson, "FDE vs. Customer, Solutions, and Consulting Engineers," compares these responsibilities across roles.