Start Here — Mission Briefing

The Role in One Paragraph

You are interviewing for Manager, GenAI Forward Deployed Engineering (FDE) — an L7/NF7 senior engineering-manager role in Google Cloud’s newest, highest-visibility org, based in Mumbai, covering manufacturing and conglomerate customers. Your team of AI/ML engineers doesn’t consult — it codes, debugs, and jointly deploys bespoke agentic solutions inside customer environments. You review architecture, unblock engineers, absorb customer pressure, and align with Product, Engineering, and Regional Sales leadership. The org is being built for the first time globally: they are hiring builders of teams, not caretakers.

Interview Logistics

The Ten Rules (from your recruiter + the official prep doc)

1. Concise beats long. A precise 2-minute structured answer beats 5 minutes of rambling. Answer, then stop — depth comes through follow-ups.
2. Depth beats altitude. “We want to see the depth of your model.” Name specific tools, numbers, trade-offs, costs, timelines, risks — in business terms. Staying at 30,000 feet is the #1 documented failure mode.
3. Be ready for live back-of-envelope math. Token costs, GPU throughput, latency budgets, team capacity. Practice doing it out loud.
4. Give the verbatim words. “I’d have a conversation” is not enough — what are the first three questions you ask? What exactly do you say to the CFO?
5. Own the decision. Make a call and defend it. Changing your mind on new information is a strength; having no position is a weakness. “It depends” is fine only if you then walk the decision tree.
6. Translate without patronizing. You’ll sit with CTOs and CEOs. Explain deep technical concepts to non-technical executives without dumbing them down.
7. Push back with confidence, not arrogance. They will test whether you can challenge a customer’s conclusion when evidence says otherwise — without burning the bridge.
8. Be intellectually honest about the market. If you can’t name where Google genuinely lags, they’ll question your credibility with customers. Candor over cheerleading.
9. Show FDE-specific management instincts. Scope creep imposed directly on your engineers by customers, isolation, “going native,” burnout of solo engineers at customer sites, engineers who are physically and psychologically closer to the customer than to you.
10. Distinguish what YOU do from what you delegate — and show you can do both. Describing only what “the team” would do is a documented weak signal.

What Strong vs Weak Looks Like (verbatim from Google’s prep doc)

Strong: names specific tools/frameworks/numbers unprompted · makes a decision, defends it, adjusts cleanly on new constraints · distinguishes do-vs-delegate · manages people with empathy and stakeholders with clarity without conflating the two · honest about trade-offs, including Google’s, without losing confidence.

Weak: stays at 30,000 feet when asked for ground-level detail · defaults to “it depends” without resolving the dependency · describes what the team would do instead of what you would do · treats Google’s weaknesses as unspeakable or competitors’ strengths as irrelevant.

How Scoring Actually Works

Every interviewer scores four attributes — General Cognitive Ability (GCA), Role-Related Knowledge (RRK), Leadership, Googleyness — on a 4-point scale with written justification. A hiring committee of 3–5 senior Googlers who never met you decides from the written packets. Three implications:

• Consistency beats spikes. Five “Leaning Hires” is likely a No Hire; consistent Hires beat one Strong Hire plus a Leaning No-Hire.
• The committee can flex on RRK/Leadership/Googleyness — never on GCA. Never sacrifice structured thinking to show off knowledge. Visible structure is the through-line of every answer.
• Vagueness = “insufficient signal” = rejection, as deadly as a red flag. Being too humble kills L7 candidacies. Give crisp evidence with explicit stakes and numbers the interviewer can quote in committee.

The L7 Bar — the Single Most Important Calibration

An L7 candidate who answers every question with one great single-team execution story “reads a level below where they are aiming.” A hiring-committee member’s framing: “One story shows me one situation. I am trying to understand ten.”

At L7 they evaluate how you think about classes of problems: recurring decisions, principles, organizational mechanisms. Every strong answer should end one level up — the repeatable mechanism, standard, or team you built so the problem class stopped recurring. Show breadth (many situations, teams, years), organizational judgment (driving change across teams that don’t report to you), managing through leads/managers, and business-level framing (revenue, retention, customer outcomes).

Your Personal Positioning (use this spine everywhere)

“I’ve spent 19 years shipping software, the last decade leading engineering teams that deploy directly into demanding environments — Walmart’s offices worldwide and enterprise retail customers at Impact Analytics. I’ve done the FDE job before it had the name: my teams built and deployed bespoke solutions inside customer/business environments, I rescued a failing vendor-built data platform by re-architecting it live, I’ve personally spiked hard problems when my team was stuck, and I’ve run the discovery-to-production loop with executives on one side and engineers on the other. Now I’m building an AI-native SaaS for MSMEs and training teams on GenAI — I code with these models weekly. This role is the intersection of everything I’ve done: hands-on architecture, customer-embedded delivery, and building teams under pressure.”

Three proof pillars to keep returning to:

1. Hands-on technical depth — the R-ensemble-on-AWS-Lambda spike (4–5 hours → ~6 minutes), the Databricks→BigQuery migration you architected, the serverless-Spark-on-Dataproc re-architecture, current GenAI building (RAG/agents) in your venture.
2. Customer-embedded delivery under pressure — Walmart India Associate app during COVID (life-safety stakes, compressed timelines), visitor kiosk + space booking deployed across hundreds of offices, rescuing the corporate real-estate platform from a failing Infosys engagement while keeping the stakeholder relationship intact.
3. Team building & people leadership — grew Impact Analytics engineering to 50+, ran a 23-person multi-discipline team at Walmart for ~6 years, manage by trust as a buffer between engineers and customer/product pressure, with a track record of unblocking stuck engineers by deep-diving data flows personally.

Your Story Bank — 12 Stories, Pre-Computed

Build each to ~2 minutes in STAR-L (Situation 15s with explicit stakes → Task 10s, what YOU owned → Action 60–70s, “I” not “we”, 3–4 decisions with reasoning → Result 20s, quantified → Learning 15s, generalized into your operating model). Never reuse a story within one interview. Each story below is tagged with the questions it answers.

Story 1 — The Infosys Rescue (your crown jewel — use in RRK or GnL, not both)

Covers: turning around a failing engagement · customer had bad experience with a team · technical judgment · re-architecture · stakeholder repair · pushing back with evidence.

• S: Walmart’s corporate real-estate data platform, built by Infosys contractors, was failing — unreliable pipelines, missed SLAs, business stakeholders losing trust. Stakes: platform underpinned real-estate decisions across hundreds of offices; escalations reaching senior leadership.
• T: I was asked to take ownership and decide: remediate, rebuild, or replace.
• A: I personally audited the architecture before deciding — traced the data flows and failure points rather than accepting either the vendor’s or the business’s narrative. Found the root cause was architectural (a brittle, over-provisioned always-on design), not just execution. I made the call to re-architect onto serverless Spark on Dataproc, sequenced the migration so the business never lost reporting continuity, set explicit quality gates for onboarding each source, and managed the vendor relationship without public blame — reset expectations with their leadership privately, kept their engineers engaged on the parts they could deliver.
• R: Onboarded 50+ data sources onto the re-architected platform; reliability restored; stakeholder trust rebuilt (they expanded scope rather than pulling the engagement).
• L: “Diagnose before you mediate or replace. When an engagement is failing, the presenting symptom is rarely the root cause — I now always trace the actual data/system flows myself before making a strategic call. And you can hold a vendor accountable without humiliating them; you’ll need the relationship later.”

Story 2 — R Ensemble on Lambda (your technical-depth spike)

Covers: “how are you still technical?” · unblocking a stuck team · make-vs-buy judgment · back-of-envelope thinking · do-vs-delegate.

• S: At Impact Analytics, ensemble forecasting models in R took 4–5 hours per run — too slow for the customer’s decision cadence; the team was stuck optimizing within the existing design.
• T: As Director, I chose to spike it personally rather than let the team burn weeks — this was an architecture question, not an implementation one.
• A: I profiled the workload, saw it was embarrassingly parallel across model×segment combinations, and prototyped fanning it out across AWS Lambda — hundreds of concurrent executions, paying only for compute-seconds. Handled the practical constraints: R runtime packaging, per-invocation memory limits, result aggregation, cold starts.
• R: Runtime dropped from 4–5 hours to ~6 minutes (~40–50x). The pattern became the team’s standard for batch scoring.
• L: “I don’t do routine code reviews as a manager — but I reserve the right to spike. My rule: when the team is stuck at the architecture level, my highest-leverage act is a working prototype that reframes the problem, then hand it back and get out of the way.”

Story 3 — COVID Associate App (ambiguity + user-first + speed)

Covers: ambiguity · high-pressure delivery · user-first decisions · working with imperfect requirements · empathy for users.

• S: COVID reopening — Walmart India needed an Associate app for seat booking and social distancing compliance. No playbook existed; guidelines changed weekly; getting it wrong risked employee health and regulatory exposure.
• T: I owned delivery end-to-end with my India team.
• A: Decomposed the unknown into decisions we could make now vs. ones we deliberately deferred behind feature flags; shipped a v0 fast to generate real usage information; set a weekly re-planning cadence against changing government/corporate guidance; kept the design centered on the associate’s 30-second booking flow, resisting scope pressure for admin-side features first.
• R: Deployed and adopted for India’s return-to-office; became the template referenced for office-return workflows.
• L: “In ambiguity, the team doesn’t need certainty from me — it needs a decision cadence: what we decide today, what we revisit Friday, and what signal will change our mind. I’ve reused that mechanism in every ambiguous project since.”

Story 4 — Databricks → GCP/BigQuery Migration (strategic technical call + delivery)

Covers: architecture trade-off with cost numbers · leading a migration · vendor/platform decisions · communicating up.

• S: Walmart EBS pillar ran its data engineering on Databricks; a strategic decision was made to consolidate onto GCP. Risk: full platform migration with zero tolerance for reporting downtime.
• T: I led the full migration to GCP/BigQuery for my pillar.
• A: Inventoried workloads and classified them by migration risk; ran dual-write/dual-read validation for critical pipelines; renegotiated SLAs with downstream consumers around cutover windows; presented the trade-off analysis (cost model, performance benchmarks, team retraining cost) to the larger architecture group and defended the sequencing.
• R: Completed migration with no material business disruption; simplified the estate and reduced platform cost (have your real % or ₹ figure ready).
• L: “Migrations fail at the edges — the undocumented consumers. I now start every migration with a consumer census, not a workload inventory.”

Story 5 — Space Booking + Visitor Kiosk at Global Scale (production ownership)

Covers: operating production systems for hundreds of sites · reliability thinking · edge deployment realities · multi-stakeholder product ownership.

• S: Owned Walmart’s navigation/space-booking app and visitor kiosk deployed across hundreds of offices globally — different networks, hardware, local IT, time zones.
• A: Fleet health monitoring, staged rollouts (canary offices before global), designed for offline degradation, remote diagnostics to avoid site visits, and a support/escalation model local IT could actually run.
• R: Sustained global operation with a small team (~have your uptime/ticket numbers ready).
• L: “Kiosks taught me edge deployment humility: the failure modes are power cables and building Wi-Fi, not code. Design for the messiest site, not the demo site.” (Direct bridge to factory-floor AI.)

Story 6 — Growing Impact Analytics to 50+ (team building + hiring bar)

Covers: hiring · scaling a team · introducing new tech (GCP/BigQuery) · working directly with Google reps and customers.

• A: Built the hiring engine (structured interviews, calibrated rubric, senior:junior ratios), introduced GCP and BigQuery to the company, sat with customers directly alongside Google’s own reps. Mention a hire you didn’t make under pressure to fill a seat — the hiring-bar question is an L7 staple.
• L: “Hiring bar is a system: rubric, calibration, and the willingness to leave a seat empty. Every bad hire I’ve made came from relaxing one of the three.”

Story 7 — Two Strong Engineers in Conflict (prepare a REAL instance)

Covers: the near-certain “two high performers on the same project” question.

Template to fill with your real case: Diagnose separately first (1:1s — the stated technical dispute is usually about scope, recognition, or ownership) → make criteria objective (eval data, benchmark, design review with written trade-offs) so neither loses to the other person, they lose to the data → clarify decision rights going forward (who owns what) → both retained and growing afterward → systemic fix (role charters / tech-lead rotation) so the conflict class recurs less.

Story 8 — Managing an Underperformer to a Real Ending

Covers: underperformance · empathy with standards · documented process.

Template: early specific feedback → diagnose skill vs will vs fit vs context (shadow them, gather behavioral specifics) → 30–60 day plan with observable criteria → real ending: genuine turnaround with evidence, or a respectful managed exit you own. At L7, never having exited anyone is implausible — own one. Add the L7 layer: how you now coach your leads to catch it earlier.

Story 9 — Promotion-Hungry Engineer Who Wasn’t Ready

Template: transparent gap analysis against the ladder → development plan with observable milestones and stretch scope → honesty that promotion needs business-sized scope, not tenure → how you delivered the “no” so motivation survived → ideally promoted 1–2 cycles later.

Story 10 — Delivering Bad News to Executives

Covers: missed dates / can’t-build-what-was-promised · communication sequencing.

Use a real Walmart/IA case: disclosed early (bad news doesn’t age well) → came with three options with trade-offs, not just the problem → stated what you’d already mitigated → sequenced communication deliberately (team first? sponsor first? — be ready to defend the order) → relationship survived and strengthened.

Story 11 — Hardest Feedback You Ever Received

Pick something real about your leadership style (e.g., “as a buffer you absorbed too much — your team didn’t see the customer pressure and got blindsided by a priority shift,” if true). Structure: initial honest reaction → specific behavior change → evidence it stuck → how it changed how you coach others now. Avoid humble-brags.

Story 12 — Outside the Comfort Zone: The GenAI Reinvention

Covers: comfort zone · learning velocity · why this role.

• S/A: After Walmart, deliberately rebuilt yourself as an AI-native builder: hands-on with LLMs, RAG pipelines and agentic patterns in your MSME SaaS venture; teaching GenAI (nothing exposes gaps like teaching); shipping with modern model APIs weekly.
• L: “I refuse to manage what I can’t build. The field turns over quarterly, so I hold myself to the same learning bar I set for engineers — and that’s the bar I’d set for this FDE team.”

Coverage Matrix

Round 1 — Role Related Knowledge (RRK)

What This Round Is

60 minutes, 4–5 questions mixing hypothetical and behavioral, drawn from the team’s actual daily work: “this is what we do daily and the challenges we face — how would you go about it?” A real Blind report from this exact GenAI FDE loop (June 2026) confirms the RRK round is effectively agentic system design fused with customer scoping. Official topic list from the prep doc: AI stack & architecture · inference & tuning optimization · executive consulting & lock-in risk · project delivery & team leadership · market and domain acumen · plus GenAI concepts, app development, consulting, cloud technology, and troubleshooting.

The FDE answer skeleton — use it for every scenario question:

1. Clarify and scope (who is the user, what’s the workflow, cost of a wrong answer)
2. Map stakeholders and competing priorities
3. Identify data sources, integration points, environment constraints
4. Propose an approach with explicit trade-offs (name tools, numbers, costs)
5. Surface failure modes before being asked
6. End one level up (L7): the mechanism you’d build so the team repeats this without you

Category A — AI Stack & Architecture

Q1. “A large manufacturer says: ‘We want AI to improve plant productivity.’ What do you do?”

Framing: This is a discovery test. Naming technology first is the documented fatal mistake.

Model answer (~2 min): “Before proposing anything, I need four things. First, who is the user and what decision are they making — a maintenance engineer diagnosing a fault, a quality head reviewing defects, a planner scheduling lines? ‘Productivity’ means a different system for each. Second, where the data lives and what shape it’s in — SAP PM, a historian like OSIsoft PI, MES, or paper logbooks; data readiness kills more manufacturing AI projects than model quality. Third, the cost of a wrong answer — a wrong SOP retrieval in a safety context is very different from a wrong demand forecast, and it determines whether we design human-in-the-loop or autonomous. Fourth, one measurable KPI with a named owner — unplanned downtime hours, first-pass yield, mean time to repair.

Then I’d propose a thin first slice: one plant, one KPI, 4–6 weeks, with the production path designed in from day one — same security model, same integration pattern the production system will need. MIT’s NANDA study found ~95% of GenAI pilots show no P&L impact, and the failure is almost never the model — it’s workflow integration and data readiness. So I scope against those two risks first. As the manager, I’d also make this discovery checklist the team’s standard qualification gate, so we stop signing engagements the data can’t support.”

Q2. “Managed API vs RAG vs open-weight self-hosting vs fine-tuning — walk me through your decision tree.”

Model answer: “My escalation ladder: prompting first — solves ~80% of formatting and behavior issues in an afternoon, zero infra. RAG when the problem is knowledge — proprietary, changing data: SOPs, part catalogs, contracts. Fine-tuning does not fix knowledge gaps; RAG does, and it stays fresh. Fine-tune last, and for a different reason than most customers think — the killer use case is cost compression: distill a frontier model’s behavior on a narrow, stable, high-volume task into a Flash- or Gemma-class model at 10–20x lower inference cost. Classic manufacturing fits: defect-label classification, log triage.

Self-hosting open weights is a break-even calculation, not an ideology: fixed GPU cost regardless of usage means break-even vs cheap APIs sits around 100–500M+ tokens/month sustained, and true costs run 3–5x the spreadsheet once you add engineering time, utilization risk (an H100 at 10% load costs ~10x per token what it does at 80%), and quarterly model churn. Where self-hosting genuinely wins: data that cannot leave the plant, or edge latency — and there I’d reach for Gemma-class small models on-prem rather than a 70B vanity deployment.

And I always ask the un-glamorous question first: does this need GenAI at all? Demand forecasting, anomaly detection on sensor data — gradient-boosted trees are cheaper, faster, more explainable. Using an LLM there is malpractice.”

Q3. “Single agent vs multi-agent — when, and how do you orchestrate?”

Model answer: “Start single-agent, always. I move to multi-agent only on evidence: one agent consistently failing on scope — context overflow, conflicting instructions, tool-selection accuracy degrading past ~10–15 tools, or latency from one agent doing everything serially. Multi-agent is not free: it can burn ~15x the tokens of a single-agent chat and every hop adds failure surface.

When I do split: planner–executor for auditable, predictable workflows (plan up front, cheaper, easier to debug — my default for enterprise); ReAct loops where the path genuinely can’t be planned (exploratory diagnosis); reflection/critic as a second model reviewing before customer-visible output; hierarchical supervisor with specialist agents when domains are cleanly separable — order status, warranty, troubleshooting. Context engineering matters more than topology: isolated context per agent, scoped scratchpads, summarization between hops, external memory.

On Google’s stack that maps to ADK for building — including its deterministic workflow agents (Sequential/Parallel/Loop) wrapped around LLM agents — Agent Engine for the managed runtime with sessions and memory, MCP for agent-to-tool, A2A for agent-to-agent. One-liner I use with customers: MCP standardizes agent-to-tool; A2A standardizes agent-to-agent.”

Q4. “How do you manage state and memory in a long-running enterprise agent?”

Model answer: “Three layers, managed differently. Ephemeral task state — the working scratchpad for the current plan; lives in the session, dies with it. Session state — multi-step workflow progress; this is where reliability engineering lives: durable execution with checkpointing so a crashed workflow resumes rather than restarts, and idempotency keys on every write action so a retry never creates a duplicate SAP work order. Long-term memory — user preferences, learned facts; vector store first, graph memory only when relationship queries become the bottleneck.

The trap I flag from experience: memory failures are invisible. An agent retrieving a stale memory produces a plausible wrong answer, not an error. So I evaluate memory as its own component — retrieval hit-rate against a golden set, staleness tracking — not just end-to-end. This is exactly the ‘state-management challenges’ the JD names as what blocks enterprise-grade maturity.”

Q5. “Explain MCP and its security risks in a customer environment.”

Model answer: “MCP turns the M×N integration problem into M+N: instead of custom glue between every agent and every tool, tools expose a standard server interface, agents consume it. In a customer environment I’d put MCP servers in front of SAP, Salesforce, the ticketing system — one governed interface each.

Security is where enterprises rightly push: tool poisoning (malicious instructions embedded in tool descriptions), rug pulls (a tool changing behavior after approval), tool hijacking — all documented by Wiz Research. My controls: an allowlisted tool registry behind an MCP gateway, per-agent identity with least-privilege credentials — the order-status agent physically cannot call the refund tool — audit logging of every invocation, and human approval gates above a risk threshold. My auditability test for any agentic deployment: for any run in the last 90 days, can you tell me what data it read, what tools it invoked, and what it produced? If not, it’s not enterprise-ready.”

Category B — Inference & Tuning Optimization

Q6. “A customer’s agent is too slow / their token bill is exploding. Walk me through it.”

Model answer: “Separate the two symptoms because the levers differ. Latency: decompose the budget — for a 3s p95 chat experience: ~50ms auth/ACL, ~50ms query embedding, 50–100ms vector search, ~150ms rerank, then the LLM dominates: ~500ms TTFT plus generation. So: stream tokens (perceived latency is TTFT, not total), cut context bloat (the #1 cause — every 1k unnecessary tokens adds prefill time and cost), route to a faster model class where reasoning isn’t needed, and cache aggressively.

Cost: back-of-envelope first — tokens/query × queries/day × price. Then the 80/20: usually context bloat and unnecessary agent hops. Levers in order of effort: context/prompt compression; context caching (~90% discount on repeated system prompts and static context); model routing — Flash-Lite-class for classification and extraction at $0.10/$0.40 per 1M, Flash for the main workload at $0.30/$2.50, Pro only for escalated reasoning — routing alone typically cuts 60–80%; batch mode (50% off) for anything non-interactive; semantic caching of frequent queries; and for narrow high-volume tasks, distillation to a small model. Then I tie it to a unit economic the CFO cares about: cost per resolved ticket versus the human-handled cost.”

Q7. “Your team hits OOM errors fine-tuning a model with QLoRA. What do you tell them to check?”

Model answer: “QLoRA already quantizes the base model to 4-bit, so if we’re still OOM the usual suspects in order: sequence length — memory scales with it, so check whether the training data actually needs the configured max length, truncate or pack; batch size — drop per-device batch to 1 and use gradient accumulation to keep the effective batch; gradient checkpointing on — trades ~20–30% compute for large activation-memory savings; paged optimizers (paged AdamW) to spill optimizer state; check the LoRA config — rank and target modules multiply adapter memory; and verify nothing is silently loading in fp16 (the point of QLoRA is nf4 + double quantization). If it still doesn’t fit: smaller base model or shard with FSDP/DeepSpeed. Then the manager question: is fine-tuning even the right call here, or did we skip the RAG/prompting rungs of the ladder?”

Q8. “How does vLLM get its throughput? Why does naive serving waste GPUs?”

Model answer: “Two mechanisms. Continuous batching — naive serving batches per-request and waits for the longest generation to finish; continuous batching admits new requests at every decode step as others complete, typically 3–4x throughput. PagedAttention — KV cache is the real memory constraint, not weights: per-token KV for a 70B-class model is ~330KB, so a single 4k-context request holds ~1.3GB of KV. Naive contiguous allocation fragments memory; paging it like virtual memory lets you pack far more concurrent sequences.

The number that explains everything: a 70B model at batch size 1 is memory-bandwidth-bound at roughly 14 tokens/sec — weights over bandwidth — while the same GPU with continuous batching at high concurrency does 2,000–3,000+ tokens/sec aggregate. That gap is the economics of inference. Then the ladder: FP8/INT8 quantization (~2x throughput, minimal quality loss), speculative decoding (2–3x decode speedup when the draft-model acceptance rate is high), prefix caching, chunked prefill. On GKE, the Inference Gateway does KV-cache-aware routing — round-robin across replicas is actively harmful because replicas hold different caches — and autoscaling should key on KV-cache utilization, not CPU.”

Category C — Executive Consulting & Lock-in Risk

Q9. “The CFO asks: ‘Why did the AI give two different answers to the same question?’ Explain without jargon and without being patronizing.”

Model answer (give the verbatim words): “‘That’s the right question to ask, and it’s a property we manage, not a bug we apologize for. These models work like an expert who phrases an answer differently on different days — the substance should hold, the wording varies. Where variation is unacceptable — a compliance figure, a safety threshold — we don’t rely on the model’s judgment: we ground it in your documents, force citations, pin the deterministic settings, and for regulated outputs the AI drafts and a rule or a human decides. And we measure it: we run an evaluation suite that checks consistency on the questions that matter to you, every time we change anything.’ The move is to convert ‘non-determinism’ from a trust problem into a controls conversation — CFOs understand controls.”

Q10. “The customer’s CTO insists on fine-tuning (‘we want our own model’). Your evidence says RAG. Push back.”

Model answer: “First I take the desire seriously — ‘our own model’ is usually a proxy for control, differentiation, or data protection, so I ask which one. Then: ‘Here’s my concern with fine-tuning as step one: your knowledge changes weekly — fine-tuning freezes it, RAG keeps it live. Fine-tuning costs you every quarter when better base models ship; a RAG pipeline inherits the improvement for free. Let me propose a test instead of an argument: we define 50 questions that matter to your business, we run RAG versus a fine-tuned pilot against them, and the eval data makes the decision.’ If they still insist and it’s not harmful — sequence it: RAG now for time-to-value, fine-tune later where the eval shows a genuine gap. I push back with evidence and an experiment, never with a flat no — and I own it: if the bake-off proves me wrong, I say so loudly, which buys credibility for the next disagreement.”

Q11. “A customer fears vendor lock-in with Google. What do you tell them?”

Model answer: “I validate it — lock-in risk is real and pretending otherwise costs credibility. Then I separate the layers: model lock-in is low — prompts and evals port across models, and I’d architect an abstraction layer plus a model-agnostic eval harness so switching costs stay measured and low; Vertex Model Garden itself hosts Claude and open models, so multi-model on one platform is native. Data-platform gravity is the real commitment — BigQuery — and that deserves an honest conversation about exit costs versus the integration value. Agent-layer lock-in is where I’d point them at open standards: A2A is now a Linux Foundation project adopted by Microsoft and AWS, MCP is cross-vendor. My design rule for FDE engagements: the customer should always own their evals, their data, and their prompts — that’s their insurance policy, and saying it out loud is how you win the room.”

Q12. “‘Vibe checks’ vs automated evals — a customer says the demo looks great and wants to ship. What do you do?”

Model answer: “‘Looks great’ is n=5 with a friendly audience. Before shipping I need three things, and they’re cheap: a golden set — 200–500 real question–answer pairs curated with their SMEs; automated scoring — groundedness, retrieval hit-rate, and an LLM-as-judge rubric for answer quality, wired into CI so every prompt/model/chunking change gets regression-tested; and an online feedback loop — thumbs, escalation rate, adoption. I frame it for the exec in one line: ‘You wouldn’t ship code without tests; the eval suite is the test suite for behavior, and it’s what lets us change models safely for the next three years.’ Then I make it a gate, not a suggestion — as the manager, no team of mine ships a GenAI system without an eval harness; that’s a code-standard I set org-wide.”

Category D — Project Delivery & FDE Team Leadership

Q13. “Adoption of a deployed solution is 12% after 90 days. The exec sponsor is unhappy. What do you do?”

Model answer: “Diagnose before defending. I sit with actual users — not the sponsor — within the week, and I’m testing four hypotheses: trust (early wrong answers poisoned it — did we launch without a confidence threshold?), workflow fit (is it a separate tool they must open, instead of living inside their MES/CRM/WhatsApp?), latency/quality (is it actually good but slow?), and incentive (do workers fear it — acute in manufacturing with union dynamics — or does using it create work for them?). Each has a different fix: trust needs visible accuracy improvement plus champions rebuilding word-of-mouth; workflow fit needs embedding where they already work; incentive needs the sponsor to reframe it as augmentation, with metrics that reward usage.

Then I go back to the sponsor with the diagnosis, a re-baselined adoption target with dates, and a weekly cadence. And the L7 layer: I’d change our definition of done org-wide — an FDE engagement isn’t done at deployment, it’s done at adoption, so success criteria include an adoption number from the SOW onward.”

Q14. “A customer keeps adding scope directly through your embedded engineers. Timeline is slipping. Handle it.”

Framing: This is THE FDE-specific management question — your reports are physically and psychologically closer to the customer than to you.

Model answer: “Three threads, managed separately — the person, the project, the stakeholder. The engineer first: this is not their failure — being unable to say no to a customer you sit beside daily is the default FDE failure mode. I give them a protocol: ‘yes-and-route’ — ‘great idea, let me get it sized and into the plan’ — so they never say no to the customer’s face and never silently absorb work. The project: re-baseline visibly; every request gets sized and traded against the committed scope in a weekly change log the customer sees. The stakeholder: I take the conversation to the economic buyer myself — ‘here are the six additions since kickoff, here’s the impact; which two matter most?’ — making scope a their-priorities decision instead of a my-capacity complaint.

Prevention is the real answer at L7: engagement charters with named decision-makers, a change-control norm set at kickoff, my weekly 1:1s with embedded engineers structured to surface exactly this (‘what did you agree to this week?’), and rotation so no engineer is alone at a customer site long enough to go native.”

Q15. “How do you detect that a forward-deployed engineer is struggling before it becomes a crisis?”

Model answer: “You can’t manage FDEs by line-of-sight, so I manage by signals and structure. Signals: commit patterns changing (volume, hours — late-night commits creeping in), communication changes (shorter standups, stops asking questions, stops pushing back), process drops (skipped demos, missed retro), customer tone shifts. Any two of those trigger a conversation — not about performance, about load. Structure: weekly 1:1s that ask customer-pressure questions explicitly; a buddy/pod system so nobody is a solo deployment; rotation policies with maximum embed durations; and explicit permission norms — ‘you cannot commit scope; you can always blame me to the customer.’ The failure modes unique to this job — isolation, going native, burnout from being the only Googler in the building — are predictable, so I build the mechanism before the crisis, not after. This is exactly how I ran distributed teams at Walmart: trust plus instrumentation, not surveillance.”

Q16. “Your engineer and the customer’s architect disagree on a technical approach, and it’s escalated to you. Walk me through it.”

Model answer: “First I get the technical ground truth myself — I read the design docs and trace the constraint before any meeting; I’ve learned never to mediate from the org chart. Then: if my engineer is right, I back them in the room — publicly, with the evidence, framed as ‘here’s what the data shows’ rather than ‘my engineer is right’ — because an FDE team whose manager won’t defend them stops pushing back on customers, and then you’re a body shop. If the customer’s architect is right, my engineer hears it from me privately first, with coaching, and we course-correct without theater. If it’s genuinely ambiguous, I timebox a bake-off with an eval set — data beats debate. In all three cases, what the customer sees is one aligned Google position; the sorting-out happens on our side of the wall.”

Category E — Troubleshooting (structured problem-solving)

Q17. Official sample: “Your marketing manager complains the new company website is slow. What do you do?”

Framing: They’re testing structured decomposition, not web trivia. Narrate the tree.

Model answer: “First, define ‘slow’ — I ask what page, what action, since when, from where, and is it everyone or just them. Reproduce and measure before touching anything: real-user metrics if we have them (p50/p95 by geography and page), otherwise a quick trace. Then I decompose the request path and bisect: client (payload size, render-blocking assets, third-party tags — marketing sites die by tag manager), network (DNS, TLS, CDN hit rate, geography), server (app latency, slow queries, connection-pool saturation, a bad deploy — check the change log first: ‘what changed?’ finds most incidents), dependencies (APIs, database). I fix the biggest measured contributor, not the most interesting one, verify with the same metric, and close the loop with the person who complained. And because this was found by a complaint rather than a dashboard: I’d add an SLO and alerting so the next regression pages us before it pages the marketing manager.”

Q18. “An agent works in the demo but misbehaves in the customer’s production environment. Debug it.”

Model answer: “Parallel hypotheses, not serial guessing. The usual suspects: data distribution — prod queries and documents look nothing like the demo corpus; permissions — ACL filtering silently truncating retrieval so the model answers from thin context; version drift — prompt template, model version, or temperature differing between environments; integration behavior — tools timing out or returning different schemas in prod. I instrument before I theorize: full tracing of every step — input → retrieved context → tool calls → output — then replay the failing cases through a harness and diff demo-vs-prod configs mechanically.

And I own the communication in parallel: the customer hears ‘here’s my diagnosis plan, update by end of day’ — never ‘your data is the problem.’ The L7 layer: config parity checks and trace-by-default become team standards, because this class of bug is 100% preventable.”

Category F — Behavioral Overlays in RRK

These will be woven in — have Story Bank answers ready:

• “Tell me about the most complex system you’ve architected” → Story 4 or 1, told with numbers and trade-offs.
• “Tell me about a time you were hands-on when your team was stuck” → Story 2 (Lambda spike).
• “Tell me about a technical decision you got wrong” → have one, with what changed in your decision process.
• “How do you keep your team’s skills current in a field that turns over quarterly?” → learning as a system: rotation through frontier engagements, internal demo days, eval-harness culture (“quality is measured, not vibed”), 10–20% tooling time, hiring for learning velocity — plus your own Story 12 as proof you hold yourself to the bar.
• “How do you evaluate work you can’t personally verify anymore?” → “I manage through the eval suite and the customer’s KPI, not by reading every prompt — outcome metrics, design reviews, calibrated peer review.”

Round 2 — System Design

What This Round Is

60 minutes, led by an EM or senior engineer. One question, starting broad: they watch how you navigate ambiguity, gather requirements, and evolve a design while narrating trade-offs. Expect GenAI/agentic focus with reliability, fault tolerance, and inference optimization threaded through. There may also be a short code evaluation element — reading code, spotting a bug, suggesting the optimal fix — so warm up your code-reading.

Context your interviewer almost certainly has in mind: Google Cloud + Tata Steel (April 2026): 300+ AI agents deployed in 9 months — built on ADK, BigQuery, Gemini/PaliGemma — including Safety EyeQ (video SOP-compliance), Asset Sphere (predictive maintenance), complaint-handling agents cutting turnaround 50%, and a low-code internal agent platform. Your patch is manufacturing/conglomerates from Mumbai; expect the question to rhyme with this.

The 45-Minute Operating Rhythm

Golden behaviors: check in with the interviewer at each phase boundary (“want me to go deeper on retrieval or move to serving?”) · evolve a baseline (retrieval-only → RAG → agentic) rather than monologuing one fixed design · say numbers out loud · notice when the scale is small (“25k queries/day doesn’t need 100 GPUs” scores points).

Likely Prompts (ranked for this role)

1. Enterprise knowledge assistant for a manufacturer — 30 years of SOPs, manuals, drawings across 50 plants, Hindi+English, shop-floor users. (Highest probability — the Tata Steel shape.)
2. Multi-agent customer/dealer support — route, retrieve, act in SAP, escalate to humans.
3. Document processing pipeline — invoices/quality certs/POs, 1M docs/month, human-in-the-loop.
4. Agentic maintenance copilot — telemetry + history + manuals → diagnose, draft work order, order parts (write actions!).
5. Supply-chain what-if agent — NL over BigQuery/SAP, NL2SQL, multi-step reasoning.
6. Enterprise LLM inference platform/gateway — 40 business units, routing, quotas, self-hosted OSS vs API, showback.
7. Visual inspection / SOP-compliance agent — video → multimodal model, edge vs cloud, false-positive management.
8. RAG with strict security — per-doc ACLs, multi-tenant, India residency, 5-min freshness SLA.
9. Eval & rollout platform for many GenAI teams — golden sets, LLM-as-judge, canary, drift.
10. POC → production migration for a regulated customer — sovereignty, SSO, change windows, 99.9% SLA, cost 10x over budget.

Worked Design 1 — Shop-Floor Knowledge Assistant (RAG at enterprise scale)

Requirements to establish (ask, don’t assume)

Users: shop-floor operators on tablets + maintenance engineers. Corpus: ~50 plants × ~100k docs = 5M documents, scanned PDFs with tables and drawings, Hindi/Marathi + English. Wrong answers in safety contexts are unacceptable → must cite sources, must abstain when unsure. Freshness: updated SOP searchable within minutes. Residency: data stays in India (asia-south1 Mumbai / asia-south2 Delhi). Non-functionals: p95 < 3s conversational, 99.9% availability, per-plant/per-role ACLs.

Scale math (say it out loud)

• 5M docs ≈ 10GB text → ~15M chunks at ~512 tokens.
• Embeddings: gemini-embedding-001, 3072-dim default but Matryoshka-truncate to 768 → 4x less storage/latency for ~2–5 pt retrieval loss. 15M × 768 × 4 bytes ≈ 46GB raw, ~60GB with HNSW (+20–40% index overhead).
• Embedding cost: ~2.5B tokens × $0.15/1M ≈ $375 one-time (half in batch). Say “trivially cheap” — noticing that scores points.
• Load: 50k employees, 10% DAU, ~5 queries/day → 25k queries/day ≈ peak 10–30 QPS (bursty at shift changes). This is NOT a big system — right-sizing is the signal.

Architecture — two planes

Ingestion (async): GCS landing → Document AI Layout Parser (OCR for 30-year-old scans, table extraction, reading order) → layout-aware chunking (~500–1000 tokens, keep headers and table integrity; parent-child chunks for manuals) → gemini-embedding-001 → Vertex AI Vector Search + BigQuery metadata. Freshness SLA via Pub/Sub-triggered incremental pipeline with streaming upserts — not batch index rebuilds. Idempotent ingestion with a dead-letter queue.

Serving: query → auth + ACL metadata pre-filter (never post-filter — a security bug, not a tuning choice) → query rewrite (multi-turn condensation) → hybrid retrieval (dense ANN + BM25, RRF fusion) top-50 → reranker (Vertex Ranking API) top-5–8 → Gemini Flash with grounded prompt + mandatory citations → groundedness check gate → stream.

Build-vs-buy ladder (the FDE signature move): “I’d present the customer three rungs: Vertex AI Search (fully managed, built-in ACLs and connectors, best out-of-box quality — the 80% case), RAG Engine (managed orchestration, custom chunking/embeddings), DIY (Vector Search + Document AI + Ranking API) only for corpora where managed chunking fails — drawings, complex tables. Start managed, drop down only where evals prove we must.”

Deep dives to be ready for

• Why hybrid retrieval: part numbers and error codes (“E-4012”) are exact-match — dense-only fails on them; BM25 catches them. Reranking buys ~10–20 points of precision@5 for +100–200ms.
• Tables/drawings: extract tables as structured data plus a summary chunk; diagrams → multimodal embeddings or Gemini-generated captions.
• Hallucination control: answer only from context, mandatory citations, groundedness score gate, abstain + escalate below threshold; for safety-critical answers show the source page image itself.
• Evaluation: golden set of 200–500 Q/A pairs curated with plant SMEs; retrieval metrics (recall@k, MRR) separate from generation metrics (groundedness, relevance via LLM-as-judge); eval gate in CI before any prompt/model/chunking change; online thumbs + escalation rate.
• Multilingual: query and corpus language can differ — embed in a multilingual space, generate in the user’s language, eval per-language.

Reliability & fault tolerance

Model fallback chain (Gemini 3 Flash → 2.5 Flash → extractive/cached answer). Graceful degradation: reranker down → serve fused top-k; LLM down → “search mode” returning retrieval snippets — the plant never loses access to its SOPs. Provisioned throughput for guaranteed QPS on the critical path. Multi-region failover Mumbai↔︎Delhi keeps residency intact. Circuit breakers on tool/DB calls.

Security & cost

Say all five: VPC Service Controls perimeter around Vertex+GCS+BigQuery (the actual exfiltration control) · CMEK · region pinning (asia-south1/south2) · Access Transparency · contractual no-training-on-customer-data. Impressive detail: preview models don’t support these controls — GA models only in prod.

Unit economics: ~4k input + 300 output tokens on 2.5 Flash ≈ 4k×$0.30/1M + 300×$2.50/1M ≈ ~$0.002/query → 25k/day ≈ $50/day ≈ $1.5k/month LLM spend. Add context caching (~90% off static prefix). The whole system is cheap — say so, and note the real cost is Document AI OCR at ingestion and the people.

Worked Design 2 — Multi-Agent Support/Action System (if the prompt is agentic)

Extra requirements to ask: which actions are write-actions (ticket creation, RMA, refunds)? Containment target (60–70% typical)? Channels (WhatsApp matters in India)? Escalation policy?

Architecture: Router/orchestrator (planner–executor over ReAct — plan-up-front is cheaper and auditable; say why) → specialist agents: order-status (SAP/OMS via MCP tool server), warranty/RMA (policy RAG + write tools), troubleshooting (manuals RAG), human-handoff. Built on ADK, deployed on Agent Engine (managed sessions, memory bank, VPC-SC). MCP for agent→tool, A2A for agent→agent interop.

The part that separates seniors — reliability of actions: - LLMs are non-deterministic; wrap every write in a deterministic transaction layer: agent proposes, validated executor performs. - Idempotency keys on all writes; retries must never create two work orders. - Saga/compensating transactions for multi-step workflows; checkpointed state so crashes resume, not restart. - Human approval gates above a risk threshold (refund > ₹X); per-agent least-privilege service accounts; action allowlists. - Loop control: max iterations, token budget per session, timeout → escalate. - Guardrails: input (prompt-injection classifier, DLP PII redaction), output (Model Armor, tone), and the most important metric: false-action rate, ahead of containment. - Observability: OpenTelemetry spans per agent step, token/cost per conversation, tool-error dashboards; trajectory evals (right tools, right order — ADK eval sets) and a replay harness before every agent change.

Cost math: 100k conversations/day × ~8 LLM calls × ~2k tokens ≈ 1.6B tokens/day → route Flash-Lite for routing/classification, Flash for specialists, Pro only on escalation → model routing cuts 60–80%.

Worked Design 3 — Inference Platform / Self-Hosting (know cold even if less likely)

When to self-host: data can’t leave the perimeter (though Gemini+VPC-SC usually answers this), a fine-tuned OSS model, or sustained volume where GPU rental beats per-token API — break-even roughly >1–2B tokens/month sustained. Do the math out loud.

Stack: GKE + vLLM (or TPU + JetStream) → GKE Inference Gateway (KV-cache-aware routing; round-robin is harmful) → HPA on KV-cache utilization/queue depth, not CPU → disaggregated prefill/decode (llm-d, ~60% throughput gain, tunes TTFT and TPOT independently). Cloud Run GPU for spiky scale-to-zero; GKE for sustained 24/7; Vertex endpoints as the fastest path, migrate to GKE at volume.

Sizing example to rehearse: Target 10k tok/s aggregate on a 70B-class model → H100+vLLM+FP8 does ~2,200–3,300 tok/s per GPU at high concurrency → 4× H100 (one HGX node) with headroom. A100 ≈ 1,150 tok/s; H100 ≈ 2–2.8× A100 at ~1.7× price → H100 wins on $/token. Batch-1 roofline: 140GB weights ÷ 2TB/s bandwidth ≈ 14 tok/s — “that’s why batching exists.”

Numbers Reference Card (memorize)

Gemini pricing (per 1M tokens): 3 Pro $2 in (≤200k; doubles above) / $12 out · 2.5 Pro $1.25/$10 · 2.5 Flash $0.30/$2.50 · Flash-Lite $0.10/$0.40 · embedding-001 $0.15 (batch half). Batch mode −50%; context caching −90% on cached input. 1M-token context on Pro models.

Latency: Flash TTFT ≈ 0.5s, ~200 tok/s output. Budget for p95 3s: retrieval is ~10% — the LLM dominates, so stream.

Self-hosted: H100+vLLM 70B FP8 ≈ 2,200–3,300 tok/s; A100 ≈ 1,150; 8B on H100 ≈ 10k+ tok/s; batch-1 70B ≈ 14 tok/s. KV per token ≈ 2 × layers × kv_heads × head_dim × 2 bytes ≈ ~330KB (70B) → 4k context ≈ 1.3GB.

Storage: 768-dim float32 = 3KB/vector → 1M vectors ≈ 3–4GB indexed; 15M ≈ 60GB. Doc ≈ 2–5 chunks of 512 tokens.

Security five: VPC-SC · CMEK · region pinning (asia-south1/2) · Access Transparency · no-training commitment.

Ten Mistakes That Fail This Round

1. Architecture before framing (no user, no cost-of-wrong-answer, no human-in-loop question).
2. Treating the LLM as deterministic — no eval strategy, no canary/rollback.
3. No numbers — or fantasy scale (a 25k-q/day assistant on 100 GPUs).
4. Fine-tuning as default instead of the prompt→RAG→fine-tune ladder.
5. Hand-rolling what Vertex AI Search solves in a week — always show the managed→custom ladder.
6. Skipping sovereignty/security — for Indian conglomerates it’s often the deciding constraint.
7. Agents without failure handling — no idempotency, loop caps, compensating transactions, injection defense.
8. Monologuing one fixed design; silence reads as stuck — narrate and check in.
9. Cost blindness — not knowing Flash vs Pro is 10–40x, no routing/caching/batch story.
10. Forgetting the boring 20% that is the actual FDE job: OCR quality on old scans, Hindi/vernacular, tables in PDFs, SAP auth, change management with plant workers.

Round 3 — Leadership & People Management (Googleyness & Leadership)

What This Round Is

60 minutes, 4–6 behavioral questions. Officially “Leadership & People Management.” Assesses Google’s Googleyness dimensions — thrives in ambiguity · values feedback · challenges the status quo · puts the user first · does the right thing · cares about the team — plus emergent leadership: stepping up when it’s not your job, and stepping back at the right moment. You can fail the whole loop on this round alone.

Two question types — answer them differently (most candidates miss this):

• “Tell me about a time…” → one specific, non-generic story from the Story Bank, in STAR-L, ~2 minutes, then stop.
• “How would you / how do you…” (hypothetical/process) → NOT one story. Give your framework for the class of problem, then 1–2 quick illustrations. Your recruiter said it explicitly: for hypotheticals they judge the approach and thought process, since no one knows the outcome.

CFAS for hypotheticals: Clarify (2–3 sharp questions) → Framework (“I think about this in three threads: person, project, stakeholder”) → Assumptions (state them, niche down to a tractable scenario) → Solution (walk the framework; name trade-offs, who you’d involve, and what would change your mind).

STAR-L calibration: Situation 15s with explicit stakes ($, headcount, exec visibility) → Task 10s (your role) → Action 60–70s (“I,” not “we” — 3–4 concrete decisions with reasoning; name who disagreed) → Result 20s (quantified, committee-quotable) → Learning 15s (generalized: “I now do X for every engagement”). Omitting the Learning is a flagged weakness — it’s where intellectual humility is scored.

L7 overlay on every answer: end one level up — the mechanism, standard, or leader you built so the problem class stopped recurring. “One story shows me one situation; I’m trying to understand ten.”

The Questions — With Framing and Answer Guidance

Theme 1: Ambiguity

Q1. “Tell me about a time you led when the goal or path was completely unclear.” → Story 3 (COVID app). Strong signal: you imposed structure — decomposed unknowns into decide-now vs defer-behind-flags, shipped a v0 to generate information, set a re-planning cadence. L7 close: “the decision-cadence mechanism became how my team handles every ambiguous project.” Pitfalls: waiting for clarity from above; a story where ambiguity resolved itself.

Q2. “Tell me about navigating a reorg or organizational transition.” Strong: stabilized people first (retention, honest comms about what you did and didn’t know), re-derived priorities from the new strategy, influenced the transition plan itself. Pitfall: passive victim framing, or complaining about leadership.

Q3 (hypothetical). “You’re dropped into a new GenAI engagement — customer doesn’t know what they want, tech changes monthly, 8 weeks. What do you do?” CFAS it. Clarify: who’s the sponsor, what triggered the engagement, what does success look like to them? Framework: outcome first (one KPI, one owner) → timeboxed discovery (1 week) → thin slice with production path → weekly demo cadence as the trust engine. Handle tech churn with abstraction layers and an eval harness so model swaps are cheap. Name what you’d de-scope or escalate.

Q4. “How do you decide with incomplete information vs waiting for more data?” Framework: reversible vs irreversible (one-way doors get more data; two-way doors get decided today), cost of delay, who bears the risk. Give one example of each — a fast call and a deliberately delayed one.

Theme 2: Feedback

Q5. “Hardest feedback you’ve ever received?” → Story 11. Must be genuinely uncomfortable (leadership style, not a typo), with an honest initial reaction, a specific behavior change, evidence it stuck, and — L7 gold — how it changed how you now coach others. Pitfall: humble-brags (“I care too much”).

Q6. “Tell me about giving difficult feedback to a senior person.” Strong: direct, specific (observed behavior + impact), private, followed through, relationship intact or stronger. L7 variant worth having: coaching one of your leads on how they give feedback.

Q7. “Tell me about a time you were wrong and changed your mind.” Strong: updated publicly, credited the person (bonus if junior), institutionalized the better idea. Never claim you were “simply right” anywhere in this loop.

Theme 3: Empathy / User-First

Q8. “Tell me about advocating for the user when it was inconvenient for your team or metrics.” Must involve a real trade-off — velocity, revenue timing, or credit sacrificed. Double signal: user-first + does-the-right-thing. Quantify what it cost and what the user gained.

Q9. “A team member was struggling personally and it affected their work.” Strong: privacy-respecting support, workload rebalance, formal support mechanisms, and a clear separation of compassion from standards over time. Pitfalls: oversharing their situation; unlimited leniency with no path back; pure hardness.

Q10 (process). “How do you build customer empathy in an engineering team?” Your home turf as an FDE manager: engineers join customer calls, rotating on-site pairing, verbatim user feedback in sprint reviews, OKRs tied to customer KPIs, demo days with the customer in the room. Tie to Walmart: your team sat with the associates and facilities teams who used what they built.

Theme 4: Conflict

Q11. “Two of your strongest performers are in conflict on the same project.” (Near-certain — the recruiter named it.) → Story 7, or CFAS if asked as a hypothetical: - Clarify: Is it technical disagreement or interpersonal? How long? Is it affecting the team yet? - Framework: Diagnose separately, decide objectively, restructure so it doesn’t recur. - Walk it: 1:1 with each first — the stated technical dispute is usually scope, recognition, or ownership underneath. If technical: make the criteria objective (eval set, benchmark, written design review) — “neither of you loses to the other person; one option loses to the data.” Timebox a bake-off if genuinely uncertain. Decide explicitly, document it, and publicly back the decision regardless of whose idea won. If interpersonal: name the behavior privately, reset expectations — brilliant work doesn’t buy exemption from professionalism. Then the systemic fix: clarify decision rights and ownership boundaries (role charters) so the same collision doesn’t recur. - Result to claim (real story): both retained, both growing, and the org learned disagree-and-commit from watching it. - Pitfalls: splitting the baby; escalating upward; letting the louder one win; not noticing one quietly disengaged.

Q12. “Tell me about disagreeing with your own leadership.” Strong: data-backed dissent, delivered privately and directly, then genuine disagree-and-commit — with the outcome either way. L7: the disagreement was about strategy or org direction.

Q13. “Aligning stakeholders with competing interests (sales promised, engineering says no).” Framework: find the shared goal (the customer’s success is both teams’ goal), make trade-offs explicit in options, own the final call, and never let the customer see the seam. Your Walmart PM/program-manager/engineering triangle gives you a real story.

Theme 5: Performance Management & Developing People

Q14. “Tell me about managing an underperformer.” → Story 8. Must have a real ending. Rated evasive: “I coached them and they improved” without specifics.

Q15. “Someone wants a promotion but isn’t ready.” → Story 9. The layer most candidates miss: how you delivered the no so motivation survived. Never let them hear it first in calibration.

Q16. “How do you motivate a team through a long hard stretch / a distributed team?” Framework: motivation is a per-person diagnosis (mastery/autonomy/purpose differ) → visible progress mechanics (demos, small wins) → connect grunt work to customer impact → protect the team from thrash (your buffer style — but see Story 11’s learning) → watch burnout signals proactively. Remote: deliberate rituals, async-first documentation, equalized visibility.

Q17. “How do you maintain the hiring bar under pressure to grow fast?” → Story 6. Structured interviews, calibrated rubrics, willingness to leave seats empty, developing interviewers. Mention the hire you didn’t make. For THIS role add the FDE hiring profile: product-minded generalists who can code AND present — “I interview with client simulations, not just LeetCode.”

Q18. “Tell me about developing another leader.” The single clearest L7-vs-L6 signal — have two of these. Deliberate delegation of visible scope, letting them fail safely, sponsorship not just mentorship (you spent political capital), and where they are now.

Theme 6: Customer Escalations & Bad News (highest-probability theme for this role)

Q19. “A customer had a bad experience with your team / your team failed a customer.” (Recruiter named this one.) → Story 1 (Infosys rescue) if you saved it for this round, or another real case. The five-beat structure: 1. Own it immediately and personally — no defensiveness, and never blame your engineers in front of the customer. 2. Stabilize — senior presence, honest status, short-interval comms cadence. 3. Fix — tiger-team the immediate issue. 4. Blameless postmortem internally → systemic fix. 5. Rebuild trust with evidence over time — quantify: renewed, expanded, became a reference. Critical Google nuance: defend your team internally while owning the outcome externally — “cares about team” and “user first” are scored simultaneously. Pitfall: a story where the customer was “actually wrong.”

Q20. “Deliver bad news to a customer or executive.” → Story 10. Early disclosure, options not just problems, mitigation already underway, deliberate communication sequencing (be ready to defend who you told first and why), relationship preserved.

Q21 (hypothetical). “A strategic customer escalates to your VP saying your team is failing them. First 48 hours?” CFAS: Clarify — severity, contract stakes, history, who’s the exec sponsor, is my team aware? Framework — three parallel threads: stabilize the customer (I call the sponsor within hours: listen, own, commit to a diagnosis deadline — not a defense), get ground truth (talk to my engineers without prosecuting them, read the artifacts myself), manage internally (brief my VP with facts and a plan before they’re asked again). Then: diagnosis shared honestly at 48h with a remediation plan, exit criteria for the escalation, a comms cadence, and afterward the postmortem — including whether I missed signals. What I deliberately do NOT do: promise fixes before diagnosis, or let the account team negotiate technical commitments on my team’s behalf.

Theme 7: Integrity, Comfort Zone, Scope

Q22. “Tell me about doing the right thing at real cost.” For this role, a GenAI-honesty story is on-brand: refusing to ship an uneval’d feature, being honest about hallucination risk during a sales cycle, telling a customer the cheaper approach was the right one. Must have genuine stakes. Pitfall: costless virtue.

Q23. “Tell me about going far outside your comfort zone.” → Story 12 (GenAI reinvention) or Story 3. Voluntary discomfort, scaffolding you built to learn fast, honest early stumbles, durable capability gained.

Q24. “Tell me about influencing across teams that didn’t report to you.” Purest Leadership-attribute question. Map stakeholders and incentives, build coalitions, persuade with data/prototypes, escalate last and gracefully. Use the BigQuery migration or architecture-group work — blast radius beyond your team.

Tone Calibration for the Hour

• Confident ownership of decisions + explicit credit to the team + explicit learnings. Too humble = insufficient signal = rejection; too polished = Googleyness flag.
• Don’t name the attributes (“this shows ambiguity tolerance”) — just tell the story; they’re trained to map it.
• Leave depth in reserve: 2–4 probing follow-ups per story is normal and good. Have secondary metrics, what nearly failed, and what you’d do differently ready.
• Expect at least one negative-culture hypothetical (“your team’s morale is broken — fix it”) — diagnose per person, don’t pizza-party it.

Your AI Market Point of View

The recruiter was explicit: a well-informed, honest POV on who’s strong and weak, where Google can be beaten, open-source economics, edge deployment, and competitive dynamics — with specificity, not awareness. “If you can’t name where Google genuinely lags, we’ll question your credibility with customers.”

The One-Line Thesis (memorize)

“Models are converging and tokens are collapsing toward free; the durable advantages are silicon economics, data gravity, and the ability to get AI into production inside messy enterprises. Google is structurally strongest on the first two — and is hiring this role to fix the third. The honest gap is enterprise developer mindshare, and it’s won deployment by deployment, not by benchmarks.”

The Competitive Map (honest version)

The market in one paragraph: frontier quality gap is the smallest it’s ever been — Gemini, GPT, and Claude trade benchmark wins — so competition moved to price, context, distribution, silicon, and agent platforms. Enterprise LLM API spend is roughly Anthropic ~40% / OpenAI ~27% / Google ~21% (Menlo-style estimates; methodologies vary — say so). Google is the fastest riser (7%→21%) but still #3 in enterprise mindshare. Chinese open-weight labs (DeepSeek, Qwen, GLM, Kimi) anchor the price floor.

Where Google is genuinely strong

• Silicon economics — the deepest moat. TPU v7 Ironwood (GA April 2026) is inference-first; estimated all-in TCO ~44% below an Nvidia GB200 server. The killer proof point: Anthropic — a competitor — committed to up to 1M TPUs (~$42B+). When your rival’s model lab chooses your silicon, that’s the market’s verdict.
• Momentum: Google Cloud Q1 2026 — $20.03B revenue, +63% YoY (faster than Azure/AWS that quarter), backlog ~$462B (be honest: a large chunk is the Anthropic deal).
• Price-performance: Gemini 3.x Pro at $2/$12 is ~7x cheaper than Claude Opus ($5/$25); Flash-Lite competes with DeepSeek pricing.
• Long context that works: 1M tokens, and on 128K long-context reasoning (MRCR) Gemini scores ~77% vs ~47% (Opus) and ~41% (GPT) — utilization, not just window size. Native multimodality (video/audio/drawings) — genuinely differentiated for manufacturing.
• Integrated stack + data gravity: BigQuery → Vertex → Gemini is the cleanest data-to-inference path; ~75% of GCP customers use its AI products.
• Agent standards: A2A protocol under the Linux Foundation, 150+ orgs, adopted by Microsoft and AWS — a rare case of Google setting the industry standard. Gemini Enterprise Agent Platform consolidation; Agent Marketplace; $750M partner fund.
• Open-model hedge: Gemma 4 (Apache 2.0, edge variants running on Jetson-class hardware) — a cloud-frontier-to-factory-floor story OpenAI doesn’t have.

Where Google can honestly be beaten (SAY THESE)

1. Enterprise developer mindshare — #3. Anthropic owns ~40% of enterprise API spend and ~54% of enterprise coding (the stickiest workload); developers default to Claude or GPT and evaluate Gemini second. Google wins RFPs; it doesn’t yet win hearts.
2. Microsoft’s procurement lock. In an M365/Teams/Entra shop — most Indian BFSI — Azure OpenAI wins before the bake-off starts, on inertia not technology.
3. Consumer anchor. ChatGPT’s ~800M weekly users make “we already use ChatGPT” the default starting point in every boardroom.
4. Trust deficit on continuity. Enterprises remember killed products; the Vertex→Gemini Enterprise renaming, though strategically right, feeds the “Google renames everything every 18 months” objection. Counter it, don’t deny it.
5. Pricing cliffs. Thinking tokens billed as output; Pro input price doubles past 200k tokens — real CFO surprises in production.
6. Open-source frontier ceded to China. Llama stalled; the open-weight frontier is DeepSeek/Qwen/GLM/Kimi. Gemma is good, not frontier.

Rivals in one breath each

• OpenAI/Azure: strongest brand and consumer scale; deepest ISV surface (Copilot everywhere). But lost the enterprise API lead to Anthropic, the OpenAI–Microsoft relationship is now openly competitive (OpenAI launched its own FDE arm), and its capex-to-revenue math is the most strained.
• Anthropic/Bedrock: #1 enterprise API spend, dominant in coding and trust-sensitive verticals, ~70% of Fortune 100 touched. But no consumer distribution, premium pricing, no own silicon — it runs on Google TPUs (use that), and Claude is available in Vertex Model Garden, so “you can run Claude on GCP” defuses the model-choice objection entirely.
• AWS Bedrock: multi-model neutrality and India incumbency; but no first-party frontier model, an add-on cost stack, and it adopted Google’s A2A standard.

Likely Market Questions & Your Positions

“Where can Google be beaten? Be honest.” Give gaps 1–3 above, specifically and without flinching, then pivot: “Where we’re structurally hard to beat: silicon economics — the Anthropic TPU deal is the market’s verdict — long-context utilization, native multimodality, and BigQuery data gravity. My job as an FDE leader is converting structural advantage into deployed production wins fast enough that mindshare follows the metal.”

“A CIO says: ‘We’ll just self-host DeepSeek — it’s free.’” “I’d walk the math, not argue. Self-hosting is a fixed GPU cost regardless of usage; break-even vs cheap APIs is ~100–500M+ tokens/month sustained, and true costs run 3–5x the spreadsheet — engineering time, utilization risk, quarterly model churn. For a conglomerate the right answer is usually hybrid: Flash-class API for 80–90% of traffic, frontier for hard tasks, self-hosted small models at the edge where data can’t leave the plant — all of which GCP supports, including running their chosen open model on GKE. And one governance flag: for a group with US/EU exposure, Chinese-origin weights are a board-level provenance question.”

“Why is everyone hiring FDEs? Isn’t this just consulting?” “MIT NANDA found ~95% of GenAI pilots deliver no measurable P&L impact — and the failure is last-mile integration and data readiness, not model quality. Palantir proved embedded engineering fixes it; now OpenAI has a multi-billion-dollar deployment company, Anthropic a ~$1.5B services JV, Salesforce committed 1,000 FDEs, and Google is hiring hundreds. The difference from consulting is the feedback loop: a consultancy bills the hours; a great FDE org harvests every engagement into reusable product assets — agent templates, connectors, domain eval sets — so each deployment makes the next one cheaper and feeds the roadmap. That harvest loop is exactly what I’d enforce as a manager: every engagement ships something reusable back, or we did it wrong.”

“Is the inference cost collapse real?” “Real and brutal: GPT-4-class inference fell ~1,000x in three years (~$20–30 → ~$0.40/1M); Epoch measures ~50x/year declines at fixed capability. The paradox: token prices fell while enterprise AI spend rose ~320%, because agentic workflows fire 10–20 calls per task. Two implications: unit economics favor whoever owns silicon — Google’s TPU edge; and as tokens commoditize, value migrates up-stack to agent platforms, data, and deployment — exactly the FDE layer.”

“Are Indian conglomerates actually adopting, or is it press releases?” “Both — the job is telling them apart. Real: Deloitte finds Indian enterprises lead global peers on at-scale AI (~40% significant usage vs ~28% global). Tata Steel deployed 300+ agents with us in 9 months. Reliance is building a sovereign AI backbone at Jamnagar with GB300-class compute. Mahindra’s group CEO moved publicly from ‘experimentation’ to ‘integration at scale.’ The gap: infrastructure confidence is high, but production use cases still stall at the POC-to-production chasm — which is precisely this team’s mandate.”

India Manufacturing/Conglomerate Cheat Sheet

Groups (know cold):

Use cases with ROI numbers: predictive maintenance (30–50% unplanned-downtime reduction, ~10:1 ROI, needs 12+ months of labeled failure data — qualify data first) · visual quality inspection (99.8% accuracy at 0.1mm vs humans missing 15–30%; needs 5–10k labeled images; Gemini multimodality differentiates) · shop-floor copilots (SOPs, torque specs — the entry use case) · supply chain (220–250% ROI benchmarks) · document intelligence (invoices, HSN/GST, quality certs — fastest time-to-value in India).

Regulatory crib: DPDP Act — negative-list cross-border model, no notified list gazetted → de facto keep-data-in-India; full compliance by May 2027. Plus RBI payment-data localization, SEBI/IRDAI sectoral rules, MeitY sovereign-cloud for government. Sharp point to make: residency ≠ sovereignty — a hyperscaler’s Indian region is still subject to the US CLOUD Act; the answer is sovereign controls, customer-managed keys, and on-prem Gemma/Google Distributed Cloud where it truly matters. Google’s $15B Visakhapatnam hub vs Amazon $48B-by-2030 and Microsoft $17.5B. GCP India share ~10–12%, #3 but fastest-growing on AI/data workloads — “we win by picking manufacturing and data-heavy beachheads, not fighting everywhere.”

Key Numbers Card

• Enterprise LLM API spend: Anthropic ~40 / OpenAI ~27 / Google ~21 (was 50/12/7 in 2023)
• Enterprise GenAI spend: $37B (2025), from $11.5B (2024)
• Coding: Claude ~54% share; Claude Code ~$2.5B run rate; OpenAI ~$20B+ ARR, 800M WAU; Anthropic ~$14B ARR
• Google Cloud Q1’26: $20.03B, +63% YoY; backlog ~$462B (~$42B = Anthropic TPU deal — volunteer this)
• Ironwood TPU: ~44% lower TCO vs GB200; Anthropic: up to 1M TPUs
• Inference collapse: ~1,000x in 3 years; ~50x/year at fixed capability; agentic workloads multiply tokens 10–20x/task
• MIT NANDA: 95% of pilots, zero measurable ROI (caveat: narrow 6-month-ROI definition — showing you know the caveat is bonus credibility)
• Self-host break-even: ~100–500M tokens/month; hidden costs 3–5x; H100 at 10% utilization ≈ 10x cost/token vs 80%
• Cloud share: global AWS 30 / Azure 25 / GCP 13; India: AWS #1, GCP ~10–12%
• India: Google $15B Vizag AI hub; Deloitte 40% vs 28% at-scale adoption; manufacturing agentic AI expected to ~quadruple (6%→24%) in 2026

Back-of-Envelope Toolkit

Both the recruiter and the prep doc promise live math: token costs, GPU throughput, latency budgets, team capacity. Practice each template out loud until it takes under 90 seconds.

Template 1 — Cost per Query / Monthly LLM Spend

Formula: (input tokens × input price + output tokens × output price) × queries.

Example: RAG assistant, 4k context in + 300 out on Gemini 2.5 Flash ($0.30/$2.50 per 1M): 4,000×0.30/1M = $0.0012 · 300×2.50/1M = $0.00075 → ~$0.002/query → 25k queries/day → $50/day ≈ $1.5k/month. Then name the levers: context caching (−90% on static prefix), batch (−50%), routing to Flash-Lite for the easy 60%.

Template 2 — Agentic Workload Cost

Example: 100k conversations/day × 8 LLM calls × 2k tokens ≈ 1.6B tokens/day. All-Flash ≈ ~$500–1,000/day blended. Routing (Flash-Lite for routing/classification, Flash for specialists, Pro on escalation) cuts 60–80%. Anchor: “agentic multiplies tokens 10–20x per task — cost engineering is designed in, not bolted on.”

Template 3 — GPU Count for Self-Hosted Serving

Anchors: H100 + vLLM, 70B-class FP8, high concurrency ≈ 2,200–3,300 tok/s per GPU. A100 ≈ 1,150 tok/s. 8B model on H100 ≈ 10k+ tok/s. Batch-1 roofline: weights ÷ memory bandwidth — 140GB ÷ 2TB/s ≈ 14 tok/s (“why batching exists”).

Example: 1,000 concurrent users × 10 tok/s effective each = 10k tok/s → 10,000 ÷ 2,500 ≈ 4× H100 = one HGX node, plus one for headroom/failover.

Template 4 — KV Cache / Memory

Per-token KV ≈ 2 × layers × kv_heads × head_dim × 2 bytes ≈ ~330KB/token for 70B-class → 4k-context request ≈ 1.3GB → KV, not weights, caps concurrency. This is the PagedAttention motivation.

Template 5 — Vector Storage

768-dim float32 = ~3KB/vector. 1M vectors ≈ 3GB raw, ~4GB with HNSW (+20–40%). 15M chunks ≈ ~60GB. Doc→chunk: ~2–5 chunks of 512 tokens per document. Embedding cost: tokens × $0.15/1M (batch half) — for 10GB text ≈ 2.5B tokens ≈ $375 one-time. Trivially cheap — say so.

Template 6 — Latency Budget (p95 = 3s conversational)

auth/ACL 50ms → query embed 50ms → ANN 50–100ms → rerank 150ms → LLM TTFT ~500ms + generation (300 tokens ≈ 1.5s streamed). Retrieval is ~10% of the budget; the LLM dominates → stream, and fight context bloat before touching the vector DB.

Template 7 — Self-Host Break-Even

Fixed GPU cost ÷ per-token API price = break-even tokens. An H100 node at ~$2/hr/GPU × 8 ≈ $12k/month vs Flash-class API at ~$0.30–1/1M blended → break-even ≈ 100–500M+ tokens/month sustained, before the 3–5x hidden costs (engineering hours, utilization risk, model churn). “An H100 at 10% utilization costs ~10x per token what it does at 80%.”

Template 8 — Team Capacity (FDE staffing)

Pod = 2–3 engineers per active engagement. Engineer effective delivery ≈ 60–70% (customer meetings, travel, internal). Span of control 6–8 per lead. Example: 5 concurrent accounts × 2.5 engineers ÷ 0.65 utilization ≈ 19–20 engineers ≈ 3 pods with 3 leads + platform/enablement function of 2–3 converting engagement artifacts into reusable assets. Rotation budget: no engineer solo-embedded beyond a quarter.

Pricing Card (per 1M tokens, Vertex AI)

Batch −50% · context caching ≈ −90% on cached input · thinking tokens bill as output · 1M context on Pro/Flash.

Director Round & Customer Presentation

Scheduled only after you clear RRK + System Design. May include a presentation prompt: “present to a customer” — the recruiter will share the prompt in advance if required.

Presentation Structure That Wins (15–20 min customer-facing)

1. Their problem in their words (2 min) — restate the business problem with their KPIs; zero Google slides yet. This alone differentiates you.
2. What we’d build (5 min) — one architecture slide, drawn simply; the demo/thin-slice first, platform second. Concrete: “in week 4 your maintenance engineer types a fault code and gets the SOP section with the page image.”
3. How we’d prove it works (3 min) — eval plan, success metrics agreed with them, adoption target. This is the credibility slide most presenters skip.
4. Cost, timeline, risks (3 min) — real numbers with ranges; name the top three risks yourself (data readiness, integration auth, adoption) with mitigations. Naming risks first is the trust move.
5. Why Google (2 min) — honest version: TPU economics, multimodality for their factories, BigQuery gravity, sovereignty options — and one honest limitation with how you’d manage it.
6. The ask (1 min) — named sponsor, data access, one KPI owner, kickoff date.

Delivery rules: never read slides · speak to the most senior business person, not the most technical · plan for the demo to fail (recorded backup) · rehearse the 5-minute version — execs cut time.

Two-Week Prep Plan (July 14 → July 27)

Week 1 — Build Depth (July 14–20)

Mon–Tue (14–15): Story bank. Write all 12 stories in STAR-L. Fill in real numbers (team sizes, ₹/$ impact, timelines, uptime). Record yourself doing each in 2 minutes. Fix the ones that run long.

Wed (16): RRK technical. Drill Categories A–B (architecture + inference). Do Templates 1–7 of the numbers toolkit out loud until each takes <90s. Read the vLLM/KV-cache/QLoRA answers until you can reproduce them cold.

Thu (17): System design run #1. Full 45-minute mock of Worked Design 1 (knowledge assistant) — alone, out loud, on a whiteboard/paper, timed per phase. Note where you stall.

Fri (18): Market POV. Memorize the one-line thesis, the three honest gaps, the Anthropic-TPU proof point, the Tata Steel numbers, MIT 95%. Practice the “where can Google be beaten” answer until it sounds natural, not rehearsed.

Sat (19): System design run #2. Worked Design 2 (multi-agent). Focus on the write-action reliability material — idempotency, sagas, approval gates — that’s the L7 separator. Skim ADK/Agent Engine/Vertex AI Search docs so the vocabulary is fresh.

Sun (20): GnL run #1. All Theme 4–6 questions (conflict, performance, escalation) out loud in CFAS/STAR-L. These are the recruiter-confirmed scenarios.

Week 2 — Pressure-Test (July 21–27)

Mon (21): Mock RRK — have a friend (or an AI voice session) fire 5 questions from Round 1 doc, 60 minutes, graded against the strong/weak rubric.

Tue (22): Mock system design — a prompt you have NOT worked (pick #5 or #7 from the list). The skill is the process, not the memorized design.

Wed (23): Mock GnL — 6 questions, enforce the 2-minute stop. Practice pausing 5 seconds to structure before answering.

Thu (24): Gaps day. Re-drill whatever the mocks exposed. Re-read the official prep doc and this guide’s Start Here rules.

Fri (25): Light day. Numbers card + pricing card review. One out-loud pass of the thesis, the ten rules, and your positioning spine.

Sat (26): Rest + logistics. Interviews are 6:30 AM — shift your wake time this week. Test camera/mic/lighting; water; paper and pen for math; the numbers card OFF your desk (do not read from notes — interviewers notice).

Sun (27): Interview day. 20-minute warm-up: say your positioning spine and one story out loud so the first real answer isn’t your first spoken words of the day.

Day-Of Reminders

• Pause before answering. “Let me take 20 seconds to structure this” is a positive signal.
• Answer in 2 minutes, stop, invite the follow-up.
• Every scenario: clarify → stakeholders → data/constraints → approach with trade-offs → failure modes → the L7 mechanism.
• Say numbers unprompted. Own decisions. Credit the team in Results, use “I” in Actions.
• One honest Google weakness per market conversation — candor is the differentiator they told you they want.